[Bug c/110682] [12/13/14 Regression] ICE: internal compiler error: in gimplify_expr after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110682 --- Comment #5 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648270.html
[Bug tree-optimization/114433] ICE: verify_ssa failed: definition in block 9 does not dominate use in block 8 with _BitInt() bitfield shift at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433 --- Comment #2 from Zdenek Sojka --- Created attachment 57786 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57786=edit probably related, not fully reduced testcase
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #12 from Jonathan Wakely --- Here's a patch to make it UNSUPPORTED on any target that doesn't define the feature's feature test macro https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648266.html
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #7 from Andrew Pinski --- Still a dup. *** This bug has been marked as a duplicate of bug 92597 ***
[Bug target/92597] std::fma gives nan using -march=sandybridge+ with asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597 --- Comment #20 from Andrew Pinski --- *** Bug 114437 has been marked as a duplicate of this bug. ***
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437 --- Comment #6 from Andrew Pinski --- You can juse use "+mr" without the comma. There is no way to use alterantives in inline-asm.
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437 xog4n...@a-n.cc changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #5 from xog4n...@a-n.cc --- I would prefer to use something else, but I'm not aware of any less hacky way to ensure that the compiler does not interfere with a benchmark. If there's any explicitly supported way to achieve that in GCC, I'm all ears, but I don't assume so given that each and every C++ benchmarking library I know uses inline asm.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/114438] New: Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 Bug ID: 114438 Summary: Missed constraint F2023:c7108 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Created attachment 57785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57785=edit Fortran 2023:C7108 violation Gfortran does not diagnosis F2023:C7108. C7108 (R756) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (15.5.5.2). The attached program compiles and execute where the generic function is resolved to a function.
[Bug rtl-optimization/71246] inline-asm documentation for + and constraints that take memory needs improvements; alteratives too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71246 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-22 Status|UNCONFIRMED |NEW Summary|"+g" assembly constraint|inline-asm documentation |causes error: inconsistent |for + and constraints that |operand constraints in an |take memory needs |'asm' |improvements; alteratives ||too Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- .
[Bug libstdc++/114394] std::bind uses std::result_of which is deprecated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394 --- Comment #4 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/114401] libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > There's another bug in the node move assignment operator, so I'll fix that > too. Turns out there wasn't, just the one you reported originally. It's fixed on trunk, but I'll backport it to the release branches.
[Bug rtl-optimization/71246] "+g" assembly constraint causes error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71246 Andrew Pinski changed: What|Removed |Added CC||leppkes at stce dot rwth-aachen.de --- Comment #3 from Andrew Pinski --- *** Bug 92597 has been marked as a duplicate of this bug. ***
[Bug target/92597] std::fma gives nan using -march=sandybridge+ with asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #19 from Andrew Pinski --- Documentation needs to be clearer here really. Since inline-asm is partially exposing GCC's internals and it needs be better at documenting what + does for constraints takes memory. *** This bug has been marked as a duplicate of bug 71246 ***
[Bug target/92597] std::fma gives nan using -march=sandybridge+ with asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597 Andrew Pinski changed: What|Removed |Added CC||xog4n...@a-n.cc --- Comment #18 from Andrew Pinski --- *** Bug 114437 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/71246] "+g" assembly constraint causes error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71246 Andrew Pinski changed: What|Removed |Added CC||frederic.recoules@univ-gren ||oble-alpes.fr --- Comment #2 from Andrew Pinski --- *** Bug 94180 has been marked as a duplicate of this bug. ***
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew Pinski ---
(In reply to xog4nar4 from comment #3)
> Just to confirm, is this an incorrect constraint for the intended goal of
> convincing the compiler that the value is used and modified, without
> actually doing either and preserving the value, or am I just using it wrong
> in this particular example? I'm somewhat surprised since this inline asm
> snippet is used in multiple well-known micro-benchmarking libraries.
>
>
> Is the following version correct?
> ```
> asm volatile("" : "=m,r"(arg) : "0,0"(arg) : "memory");
> ```
The correct way of implementing this inline-asm is don't. Oh and the above does
not work either because a constraint of `"=m":"0"` is also not going to work.
Inline-asm is really NOT designed for this purpose at all and abusing it this
way is just going to run into these issues.
*** This bug has been marked as a duplicate of bug 92597 ***
[Bug rtl-optimization/94180] inconsistent operand constraints: "+X"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94180 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 71246 ***
[Bug libstdc++/114401] libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c2e28df90a1640cebadef6c6c8ab5ea964071bb1 commit r14-9636-gc2e28df90a1640cebadef6c6c8ab5ea964071bb1 Author: Jonathan Wakely Date: Thu Mar 21 13:25:15 2024 + libstdc++: Destroy allocators in re-inserted container nodes [PR114401] The allocator objects in container node handles were not being destroyed after the node was re-inserted into a container. They are stored in a union and so need to be explicitly destroyed when the node becomes empty. The containers were zeroing the node handle's pointer, which makes it empty, causing the handle's destructor to think there's nothign to clean up. Add a new member function to the node handle which destroys the allocator and zeros the pointer. Change the containers to call that instead of just changing the pointer manually. We can also remove the _M_empty member of the union which is not necessary. libstdc++-v3/ChangeLog: PR libstdc++/114401 * include/bits/hashtable.h (_Hashtable::_M_reinsert_node): Call release() on node handle instead of just zeroing its pointer. (_Hashtable::_M_reinsert_node_multi): Likewise. (_Hashtable::_M_merge_unique): Likewise. (_Hashtable::_M_merge_multi): Likewise. * include/bits/node_handle.h (_Node_handle_common::release()): New member function. (_Node_handle_common::_Optional_alloc::_M_empty): Remove unnecessary union member. (_Node_handle_common): Declare _Hashtable as a friend. * include/bits/stl_tree.h (_Rb_tree::_M_reinsert_node_unique): Call release() on node handle instead of just zeroing its pointer. (_Rb_tree::_M_reinsert_node_equal): Likewise. (_Rb_tree::_M_reinsert_node_hint_unique): Likewise. (_Rb_tree::_M_reinsert_node_hint_equal): Likewise. * testsuite/23_containers/multiset/modifiers/114401.cc: New test. * testsuite/23_containers/set/modifiers/114401.cc: New test. * testsuite/23_containers/unordered_multiset/modifiers/114401.cc: New test. * testsuite/23_containers/unordered_set/modifiers/114401.cc: New test.
[Bug rtl-optimization/94180] inconsistent operand constraints: "+X"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94180 --- Comment #3 from Andrew Pinski --- Dup.
[Bug libstdc++/113841] Can't swap two std::hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841 --- Comment #13 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:142cc4c223d695e515ed2504501b91d8a7ac6eb8 commit r14-9635-g142cc4c223d695e515ed2504501b91d8a7ac6eb8 Author: Jonathan Wakely Date: Fri Feb 9 17:06:20 2024 + libstdc++: Constrain std::vector default constructor [PR113841] This is needed to avoid errors outside the immediate context when evaluating is_default_constructible_v> when A is not default constructible. To avoid diagnostic regressions for 23_containers/vector/48101_neg.cc we need to make the std::allocator partial specializations default constructible, which they probably should have been anyway. libstdc++-v3/ChangeLog: PR libstdc++/113841 * include/bits/allocator.h (allocator): Add default constructor to partial specializations for cv-qualified types. * include/bits/stl_vector.h (_Vector_impl::_Vector_impl()): Constrain so that it's only present if the allocator is default constructible. * include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()): Likewise. * testsuite/23_containers/vector/cons/113841.cc: New test.
[Bug rtl-optimization/94180] inconsistent operand constraints: "+X"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94180 Andrew Pinski changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #2 from Andrew Pinski --- *** Bug 113280 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/113280] Strange error for empty inline assembly with +X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #13 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 94180 ***
[Bug libstdc++/114394] std::bind uses std::result_of which is deprecated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:31ef58b18da930b09ea0dfc1d6533c5ef97d8446 commit r14-9632-g31ef58b18da930b09ea0dfc1d6533c5ef97d8446 Author: Jonathan Wakely Date: Tue Mar 19 14:02:06 2024 + libstdc++: Replace std::result_of with __invoke_result_t [PR114394] Replace std::result_of with std::invoke_result, as specified in the standard since C++17, to avoid deprecated warnings for std::result_of. We don't have __invoke_result_t in C++11 mode, so add it as an alias template for __invoke_result<>::type (which is what std::result_of uses as its base class, so there's no change in functionality). This fixes warnings given by Clang 18. libstdc++-v3/ChangeLog: PR libstdc++/114394 * include/std/functional (bind): Use __invoke_result_t instead of result_of::type. * include/std/type_traits (__invoke_result_t): New alias template. * testsuite/20_util/bind/ref_neg.cc: Adjust prune pattern.
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #6 from Eric Gallager --- (In reply to Sam James from comment #5) > FWIW, after doing more of this work, I've decided I don't really care that > much about this one. > > I still think FP mismatches are often worse, but there's enough junk pointer > type mismatches that I'm not sure we should provide this (it's not like one > case is OK and the other is way less scary or something). I mean, I might still use just one but not the other in a case where I've got a huge project, and need to narrow down the warnings so that I can just focus on a manageable subset, rather than being overwhelmed by having to try to look at all of them at once.
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437
--- Comment #3 from xog4n...@a-n.cc ---
Just to confirm, is this an incorrect constraint for the intended goal of
convincing the compiler that the value is used and modified, without actually
doing either and preserving the value, or am I just using it wrong in this
particular example? I'm somewhat surprised since this inline asm snippet is
used in multiple well-known micro-benchmarking libraries.
Is the following version correct?
```
asm volatile("" : "=m,r"(arg) : "0,0"(arg) : "memory");
```
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
These constraints don't do what think it does.
You can see the behavior by doing:
asm volatile("#%0 %1" : "+m,r"(arg) : : "memory");
You get:
#arg(%rip) .LC0(%rip)
Which is correct as `1` is stored in `.LC0(%rip)`.
[Bug middle-end/114437] Inline asm with "+m, r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437 --- Comment #1 from Andrew Pinski --- "+m" does not do what you think it does ...
[Bug c/114437] New: Inline asm with "+m,r" operand ignores input value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114437
Bug ID: 114437
Summary: Inline asm with "+m,r" operand ignores input value
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xog4n...@a-n.cc
Target Milestone: ---
In the following snippet, GCC seems to assume that `arg` is not read by the asm
statement and optimizes out previous stores when compiling on -O3:
```
extern int external_fn(int);
extern int arg;
int fn() {
arg = 123;
asm volatile("" : "+m,r"(arg) : : "memory");
return external_fn(arg);
}
```
Resulting asm (123 is not stored, leaving `arg` uninitialized):
```
:
0: f3 0f 1e fa endbr64
4: 8b 3d 00 00 00 00 movedi,DWORD PTR [rip+0x0]# a
a: e9 00 00 00 00 jmpf
```
The asm snippet comes from the `DoNotOptimize` function in Google Benchmark,
where it is intended to prevent the compiler from optimizing away parts of a
micro-benchmark:
https://github.com/google/benchmark/blob/main/include/benchmark/benchmark.h#L518
Godbolt reproduction: https://godbolt.org/z/3W97dM9eW
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99852 --- Comment #7 from anlauf at gcc dot gnu.org --- Found pr99852, which reported the missed overflows.
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||14.0 --- Comment #6 from anlauf at gcc dot gnu.org --- The ICEs are gone at r14-9631, likely by the fixes r14-8902 and r14-9340. Testcases z1 and z2 are now properly rejected. The overflow for testcase z3 is not detected. I think there is a related PR on this.
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 --- Comment #31 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c083a453dbe51853e26e02edd8b9346fb8618292 commit r14-9631-gc083a453dbe51853e26e02edd8b9346fb8618292 Author: Harald Anlauf Date: Fri Mar 22 18:17:15 2024 +0100 Fortran: no size check passing NULL() without MOLD argument [PR55978] gcc/fortran/ChangeLog: PR fortran/55978 * interface.cc (gfc_compare_actual_formal): Skip size check for NULL() actual without MOLD argument. gcc/testsuite/ChangeLog: PR fortran/55978 * gfortran.dg/null_actual_5.f90: New test.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #11 from dave.anglin at bell dot net --- On 2024-03-22 3:00 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 > > --- Comment #10 from Jonathan Wakely --- > This two depend on _GLIBCXX_USE_NL_LANGINFO_L which is set by: > >AC_TRY_COMPILE([ >#include >#if __has_include() ># include >#endif >#include >],[ > locale_t loc = newlocale(LC_ALL_MASK, "", (locale_t)0); > const char* enc = nl_langinfo_l(CODESET, loc); > freelocale(loc); >], [ac_nl_langinfo_l=yes], [ac_nl_langinfo_l=no]) newlocale/freelocale aren't supported on hpux, so test needs to be skipped or xfailed. https://www.gnu.org/software/gnulib/manual/html_node/newlocale.html
[Bug preprocessor/114436] #pragma GCC system_header vs. _Pragma("GCC system_header")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 Lewis Hyatt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-22 Status|UNCONFIRMED |NEW CC||lhyatt at gcc dot gnu.org --- Comment #2 from Lewis Hyatt --- This should fix it correctly, will test it sometime. diff --git a/libcpp/directives.cc b/libcpp/directives.cc index 479f8c716e8..36cc762e704 100644 --- a/libcpp/directives.cc +++ b/libcpp/directives.cc @@ -1986,7 +1986,9 @@ destringize_and_run (cpp_reader *pfile, const cpp_string *in, /* Finish inlining run_directive. */ pfile->buffer->file = NULL; + const auto new_sysp = pfile->buffer->sysp; _cpp_pop_buffer (pfile); + pfile->buffer->sysp = new_sysp; /* Reset the old macro state before ... */ XDELETE (pfile->context);
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #12 from Jakub Jelinek ---
The following testcase at least reproduces the unsigned multiplication issue,
but doesn't reproduce the signed multiplication nor division by -1.
int
main ()
{
unsigned a = (1U + __INT_MAX__) / 2U;
unsigned b = 1U;
unsigned c = (a * 2U > b * 2U ? a * 2U : b * 2U) * 2U;
if (c != 0U)
__builtin_abort ();
int d = (-__INT_MAX__ - 1) / 2;
int e = 10;
int f = (d * 2 > e * 2 ? d * 2 : e * 2) * 6;
if (f != 120)
__builtin_abort ();
int g = (-__INT_MAX__ - 1) / 2;
int h = 0;
int i = (g * 2 > h * 2 ? g * 2 : h * 2) / -1;
if (i != 0)
__builtin_abort ();
}
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #10 from Jonathan Wakely --- This two depend on _GLIBCXX_USE_NL_LANGINFO_L which is set by: AC_TRY_COMPILE([ #include #if __has_include() # include #endif #include ],[ locale_t loc = newlocale(LC_ALL_MASK, "", (locale_t)0); const char* enc = nl_langinfo_l(CODESET, loc); freelocale(loc); ], [ac_nl_langinfo_l=yes], [ac_nl_langinfo_l=no])
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #11 from Jakub Jelinek ---
Perhaps
--- fold-const.cc.jj8 2024-03-11 22:37:29.0 +0100
+++ fold-const.cc 2024-03-22 19:31:44.189686120 +0100
@@ -7104,6 +7104,27 @@ extract_muldiv_1 (tree t, tree c, enum t
if (TYPE_UNSIGNED (ctype) != TYPE_UNSIGNED (type))
break;
+ /* Punt for multiplication altogether.
+MAX (1U + INT_MAX, 1U) * 2U is not equivalent to
+MAX ((1U + INT_MAX) * 2U, 1U * 2U), the former is
+0U, the latter is 2U.
+MAX (INT_MIN / 2, 0) * -2 is not equivalent to
+MIN (INT_MIN / 2 * -2, 0 * -2), the former is
+well defined 0, the latter invokes UB.
+MAX (INT_MIN / 2, 5) * 5 is not equivalent to
+MAX (INT_MIN / 2 * 5, 5 * 5), the former is
+well defined 25, the latter invokes UB. */
+ if (code == MULT_EXPR)
+ break;
+ /* For division/modulo, punt on c being -1 for MAX, as
+MAX (INT_MIN, 0) / -1 is not equivalent to
+MIN (INT_MIN / -1, 0 / -1), the former is well defined
+0, the latter invokes UB (or for -fwrapv is INT_MIN).
+MIN (INT_MIN, 0) / -1 already invokes UB, so the
+transformation won't make it worse. */
+ else if (tcode == MAX_EXPR && integer_minus_onep (c))
+ break;
+
/* MIN (a, b) / 5 -> MIN (a / 5, b / 5) */
sub_strict_overflow_p = false;
if ((t1 = extract_muldiv (op0, c, code, wide_type,
?
Though
int
main ()
{
unsigned a = 1U + __INT_MAX__;
unsigned b = 1U;
unsigned c = (a > b ? a : b) * 2U;
if (c != 0U)
__builtin_abort ();
int d = (-__INT_MAX__ - 1) / 2;
int e = 5;
int f = (d > e ? d : e) * 5;
if (f != 25)
__builtin_abort ();
int g = -__INT_MAX__ - 1;
int h = 0;
int i = (g > h ? g : h) / -1;
if (i != 0)
__builtin_abort ();
}
doesn't seem to be miscompiled, we just don't do that transformation at all
even without the patch. Need to tweak such that the min/max arguments are both
something on which extract_muldiv returns non-NULL.
[Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from David Malcolm --- Thanks; I have it reproducing in DejaGnu now (and the ICE fix). Am looking at fixing the false postive.
[Bug preprocessor/114436] #pragma GCC system_header vs. _Pragma("GCC system_header")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114423 --- Comment #1 from Andrew Pinski --- Maybe this is related to how _Pragma is treated in general.
[Bug c++/114436] New: #pragma GCC system_header vs. _Pragma("GCC system_header")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436
Bug ID: 114436
Summary: #pragma GCC system_header vs. _Pragma("GCC
system_header")
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: finke at cognitec dot com
Target Milestone: ---
Created attachment 57784
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57784=edit
code snippet
When using the _Pragma operator instead of the #pragma directive for "GCC
system_header", a different behavior can be observed:
Warnings in included header files are not being ignored as it is the case with
the #pragma directive.
The attached code snippet does emit an error when compiled with
"g++ -Werror=unused-parameter pragma.cc"
The expectation would be, that it compiles without error (clang is compiling it
without error).
gcc versions tested: 4.8.5 & 13.2.1
Output from compiler:
In file included from pragma.h:10:0,
from pragma.cc:1:
third_party.h:4:13: error: unused parameter 'force_unused_warning'
[-Werror=unused-parameter]
inline void foo( int force_unused_warning) {
^
cc1plus: some warnings being treated as errors
[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #19 from Richard Earnshaw ---
This is another problem with (I suspect) incorrect aliasing information. If I
compile with -fno-strict-aliasing, I get
88: f4432a1fvst1.8 {d18-d19}, [r3 :64] // {>E} SP+96/16
8c: f4420a1fvst1.8 {d16-d17}, [r2 :64] // {>A} SP+32/16
90: e893000fldm r3, {r0, r1, r2, r3}// {G} SP+128/16
98: eddd0b20vldrd16, [sp, #128] ; 0x80 // {B} SP+48/16
a4: e28dc040add ip, sp, #64 ; 0x40
a8: e885000fstm r5, {r0, r1, r2, r3}// {>F} SP+112/16
ac: f2d80570vshl.s16q8, q8, #8
b0: f3f503e0vneg.s16q8, q8
b4: edcd0b20vstrd16, [sp, #128] ; 0x80 // {>G.l} SP+128/8
b8: edcd1b22vstrd17, [sp, #136] ; 0x88 // {>G.h} SP+136/8
bc: e894000fldm r4, {r0, r1, r2, r3}// {C} SP+64/16
c4: e28dc050add ip, sp, #80 ; 0x50
c8: e88c000fstm ip, {r0, r1, r2, r3}// {>D} SP+80/16
cc: e885000fstm r5, {r0, r1, r2, r3}// {>F} SP+112/16
I've annotated each memory access with its stack address and labeled each
16-byte slot from A to G.
With -fstrict-aliasing this becomes:
88: f4420a1fvst1.8 {d16-d17}, [r2 :64] // {>A} SP+32/16
8c: eddd0b20vldrd16, [sp, #128] ; 0x80 // {E} SP+96/16
98: e893000fldm r3, {r0, r1, r2, r3}// {B} SP+48/16
a0: e28dc040add ip, sp, #64 ; 0x40
a4: f2d80570vshl.s16q8, q8, #8
a8: e884000fstm r4, {r0, r1, r2, r3}// {>G} SP+128/16
!
ac: e885000fstm r5, {r0, r1, r2, r3}// {>F} SP+112/16
b0: f3f503e0vneg.s16q8, q8
b4: edcd0b20vstrd16, [sp, #128] ; 0x80 // {>G.l} SP+128/8
b8: edcd1b22vstrd17, [sp, #136] ; 0x88 // {>G.h} SP+136/8
bc: e894000fldm r4, {r0, r1, r2, r3}// {C} SP+64/16
c4: e28dc050add ip, sp, #80 ; 0x50
c8: e88c000fstm ip, {r0, r1, r2, r3}// {>D} SP+80/16
cc: e885000fstm r5, {r0, r1, r2, r3}// {>F} SP+112/16
And we see that the initial store to G has been moved after the reads from it.
I'm still digging, but it may be pertinent that the reads have been split into
two separate instructions; perhaps when the split was done the alias sets
weren't copied correctly.
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 --- Comment #10 from Jakub Jelinek --- It isn't just those 2 values though. MAX (INT_MIN / 2, 0) * -2 etc. would be a problem too. So maybe play safe and only do it for MULT_EXPR when TYPE_OVERFLOW_UNDEFINED and c is non-negative? Maybe non-power of two -c could be ok too.
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 --- Comment #9 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #8) > (In reply to Richard Biener from comment #5) > > but even when overflow is undefined we don't know whether we introduce > > additional overflow then. Consider MAX (INT_MIN, 0) * -1 where we compute > > 0 * -1 (fine) but after the transform we'd do MIN (INT_MIN * -1, 0) > > which isn't valid. > > > > And when overflow wraps consider MAX (UINT_MAX, 1) * 2 which > > will compute UINT_MAX * 2 == 0 while MAX (UINT_MAX * 2, 1 * 2) will compute > > 2. > > > > Unless I'm missing something. > > You're right. So perhaps punt on this optimization for code == MULT_EXPR > altogether. Although, even for MULT_EXPR when TYPE_OVERFLOW_UNDEFINED, if the only problematic cases are when one of the multiplication operand is -1 and the other is signed minimum, because we know one of those operands (c), we could just punt if integer_minus_onep (c) or if c is TYPE_MIN_VALUE.
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 --- Comment #8 from Jakub Jelinek --- (In reply to Richard Biener from comment #5) > but even when overflow is undefined we don't know whether we introduce > additional overflow then. Consider MAX (INT_MIN, 0) * -1 where we compute > 0 * -1 (fine) but after the transform we'd do MIN (INT_MIN * -1, 0) > which isn't valid. > > And when overflow wraps consider MAX (UINT_MAX, 1) * 2 which > will compute UINT_MAX * 2 == 0 while MAX (UINT_MAX * 2, 1 * 2) will compute > 2. > > Unless I'm missing something. You're right. So perhaps punt on this optimization for code == MULT_EXPR altogether. For the division/modulo, the problematic case is signed division by -1 (unless we can prove that neither operand is signed type minimum), but c is constant here, so we could as well just punt for code == MULT_EXPR || integer_minus_onep (c)?
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> @@ -6970,8 +6972,11 @@ extract_muldiv_1 (tree t, tree c, enum tree_code
> code, tree wide_type,
>
>/* MIN (a, b) / 5 -> MIN (a / 5, b / 5) */
>sub_strict_overflow_p = false;
> - if ((t1 = extract_muldiv (op0, c, code, wide_type,
> - _strict_overflow_p)) != 0
> + if ((wide_type
> + ? TYPE_OVERFLOW_UNDEFINED (wide_type)
> + : TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0)))
> + && (t1 = extract_muldiv (op0, c, code, wide_type,
> + _strict_overflow_p)) != 0
> && (t2 = extract_muldiv (op1, c, code, wide_type,
>_strict_overflow_p)) != 0)
> {
Isn't it fine as is for unsigned divisions and modulos?
I'd think the only problem is TYPE_OVERFLOW_WRAPS code == MULT_EXPR or
!TYPE_UNSIGNED && TYPE_OVERFLOW_WRAPS division/modulo (say -fwrapv MIN (a, b) /
-1
-> MAX (a / -1, b / -1) transformation wouldn't be correct for a INT_MIN b 0,
because the first one is INT_MIN / -1 aka. INT_MIN, while the latter is 0
or perhaps TYPE_OVERFLOW_SANITIZED should be punted on as well.
[Bug tree-optimization/114435] New: Bad code generated when SSA and PCOM are enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114435 Bug ID: 114435 Summary: Bad code generated when SSA and PCOM are enabled. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jchrist at linux dot ibm.com Target Milestone: --- Created attachment 57783 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57783=edit Reproducer While investigating a preformance difference between clang and gcc on imagemagick I discovered that attached test case gets badly vectorized due to pcom pass. If I disable pcom and set the vector cost model to unlimited, SLP produces exactly what I would expect. With pcom, however, the code becomes considerably bigger and, depending on the target, even mixes scalar and vectorized operations while the whole body of the loop should be vectorizable via SLP. Difference is observed between the output of ``` gcc -O3 -fvect-cost-model=unlimited fma.c -c ``` and ``` gcc -O3 -fvect-cost-model=unlimited fma.c -c -fdisable-tree-pcom ``` I am wondering if the pcom pass should be after SLP vectorization?
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #15 from Jakub Jelinek --- I don't think a 9+ years old bug should be a P1. It would be nice to get it fixed, but I'm not sure it is feasible for GCC 14 and very unlikely backportable if we e.g. have to split the *nonnegative* predicates to 2 sets.
[Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 --- Comment #4 from Jakub Jelinek --- Or the option option would be try if it also ICEs without your patch with -fsanitize=undefined -fsanitize-trap=undefined -O1 -fanalyzer -flto , then you could put it into gcc.dg/analyzer/ and just use fsanitize_undefined effective target there.
[Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to David Malcolm from comment #2) > However I'm having trouble writing a regression test for this, with the > combination of ubsan and lto: I get: > > output is /usr/bin/ld: cannot find -lubsan > collect2: error: ld returned 1 exit status The test would need to go into gcc.dg/ubsan/ directory (or g++.dg/ubsan/ for C++), that is where the *.exp files arrange for -lubsan to be found. The test would of course then need to use analyzer effective target in it and add whatever dg-options are needed.
[Bug tree-optimization/114433] ICE: verify_ssa failed: definition in block 9 does not dominate use in block 8 with _BitInt() bitfield shift at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-03-22 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 57782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57782=edit gcc14-pr114433.patch Untested fix.
[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #24 from Jonathan Wakely --- I have the workaround now, so not urgent for me
[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #8 from Jakub Jelinek ---
2024-03-22 Jakub Jelinek
PR c++/114426
* cp-gimplify.cc (cp_fold): Don't call maybe_const_value on
CALL_EXPRs to cdtors.
* g++.dg/cpp2a/pr114426.C: New test.
--- gcc/cp/cp-gimplify.cc.jj2024-02-23 18:55:05.377594277 +0100
+++ gcc/cp/cp-gimplify.cc 2024-03-22 16:46:49.381442914 +0100
@@ -3395,7 +3395,14 @@ cp_fold (tree x, fold_flags_t flags)
Do constexpr expansion of expressions where the call itself is not
constant, but the call followed by an INDIRECT_REF is. */
if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
- && !flag_no_inline)
+ && !flag_no_inline
+ /* Don't invoke it on cdtors. On
+ !targetm.cxx.cdtor_returns_this () it won't do anything as it
+ has void type, so don't do it on
+ targetm.cxx.cdtor_returns_this () targets either for
+ consistency. */
+ && !DECL_CONSTRUCTOR_P (callee)
+ && !DECL_DESTRUCTOR_P (callee))
{
mce_value manifestly_const_eval = mce_unknown;
if (flags & ff_mce_false)
--- gcc/testsuite/g++.dg/cpp2a/pr114426.C.jj2024-03-22 16:49:55.650882841
+0100
+++ gcc/testsuite/g++.dg/cpp2a/pr114426.C 2024-03-22 16:48:51.829759997
+0100
@@ -0,0 +1,6 @@
+// PR c++/114426
+// { dg-do compile }
+
+struct A { virtual ~A (); };
+struct B : virtual A { virtual void foo () = 0; };
+struct C : B { C () {} };
fixes the ICE, but dunno whether something different shouldn't be done instead.
[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #7 from Jakub Jelinek ---
It is indeed the assert added in that patch.
When cp_fold_function is called on the _ZN12ConfiguratorD0Ev body which
contains
Configurator::~Configurator(this); call
Now, maybe_constant_value is called on this in:
/* Invoke maybe_constant_value for functions declared
constexpr and not called with AGGR_INIT_EXPRs.
TODO:
Do constexpr expansion of expressions where the call itself is not
constant, but the call followed by an INDIRECT_REF is. */
if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
&& !flag_no_inline)
{
mce_value manifestly_const_eval = mce_unknown;
if (flags & ff_mce_false)
/* Allow folding __builtin_is_constant_evaluated to false during
constexpr evaluation of this call. */
manifestly_const_eval = mce_false;
r = maybe_constant_value (x, /*decl=*/NULL_TREE,
manifestly_const_eval);
}
also on targets other than arm, but except on arm the maybe_constant_value ->
cxx_eval_outermost_constant_expr call returns very quickly, because the call
has VOID_TYPE_P and constexpr_dtor is false and the dtor isn't
DECL_IMMEDIATE_FUNCTION_P,
so it
/* Calls to immediate functions returning void need to be
evaluated. */
tree fndecl = cp_get_callee_fndecl_nofold (t);
if (fndecl == NULL_TREE || !DECL_IMMEDIATE_FUNCTION_P (fndecl))
return t;
The difference on arm is that the CALL_EXPR doesn't have VOID_TYPE_P type, but
pointer to the class, so it evaluates it and triggers the assertion.
Now, if all we want to do is get the same behavior on arm as on other targets,
perhaps
we could avoid doing that maybe_constant_value in cp_fold if DECL_DESTRUCTOR_P
(callee) or perhaps even DECL_CONSTRUCTOR_P (callee).
[Bug target/114419] [GCC < 14] amdgcn offload compiler fails to build with amdgcn tools based on LLVM 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114419 Tobias Burnus changed: What|Removed |Added CC||ams at gcc dot gnu.org, ||burnus at gcc dot gnu.org Summary|amdgcn offload compiler |[GCC < 14] amdgcn offload |fails to build with amdgcn |compiler fails to build |tools based on LLVM 18 |with amdgcn tools based on ||LLVM 18 --- Comment #2 from Tobias Burnus --- This has been fixed in GCC 14 - and the documentation has been updated accordingly. See the AMD GCN entry in the GCC 14 and the link to the install document there: https://gcc.gnu.org/gcc-14/changes.html * * * I think there are two problems with LLVM 18 - both fixed with GCC 14/mainline. Namely: (A) Support for 'Fuji' devices was stopped, i.e. those use AMDHSA Code Object Version 3 → Solution: Configure with --with-arch=gfx900 --with-multilib-list=gfx900,gfx906,gfx908,gfx90a i.e. leave out 'fiji' and switch to gfx900 for the default Cf. r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f (B) The default version used if no version has been specified changed to Code Object 5 in LLVM's linker – but with '-g' also mkoffload produces an object file - but with version 4. => With debugging enabled, there will be an error with LLVM 18, solved by the commit: r14-8449-g4b5650acb3107239867830dc1214b31bdbe3cacd - namely: Since LLVM commit 082f87c9d418 (Pull Req. #79038; will become LLVM 18) "[AMDGPU] Change default AMDHSA Code Object version to 5" the default - when no --amdhsa-code-object-version= is used - was bumped.
[Bug d/114434] gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Rainer Orth changed: What|Removed |Added Target|amd64-pc-solaris2.11, |i386-pc-solaris2.11, |sparcv9-sun-solaris2.11 |sparc-sun-solaris2.11, ||i386-apple-darwin1[15], ||i686-pc-linux-gnu --- Comment #1 from Rainer Orth --- I just noticed that this only happens for a 32-bit-default compiler, and is also seen on Darwin/i386 and Linux/i686.
[Bug d/114434] gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug d/114434] New: gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Bug ID: 114434 Summary: gdc.test/runnable/test23514.d FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: amd64-pc-solaris2.11, sparcv9-sun-solaris2.11 The gdc.test/runnable/test23514.d test FAILs on Solaris (64-bit only) since its introduction: FAIL: gdc.test/runnable/test23514.d execution test FAIL: gdc.test/runnable/test23514.d -shared-libphobos execution test core.exception.AssertError@runnable/test23514.d(12): Assertion failure /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/deh.d:51 _d_createTrace [0x4dbeeb] /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:484 _d_throw [0x4c54b9] /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:556 onAssertError [0x4a536c] ??:? _Dmain [0x4a0ee6] The weird thing is that performing the comparison in gdb works.
[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-03-22 Summary|[14 regression] ICE when|[14 regression] ICE when |building log4cxx on arm |building log4cxx on arm |(cxx_eval_call_expression, |(cxx_eval_call_expression, |at cp/constexpr.cc:3242)|at cp/constexpr.cc:3242) ||since r14-6507 CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Started with r14-6507-ge0659b5417b7f8a090ad2ed4dea830f11ef9c877
[Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408
--- Comment #2 from David Malcolm ---
Created attachment 57781
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57781=edit
WIP patch for the the ICE
The attached patch seems to fix the ICE. AIUI I'm lazily creating dominance
info as it's needed; calculate_dominance_info has this early exit:
if (dom_computed[dir_index] == DOM_OK)
{
checking_verify_dominators (dir);
return;
}
and free_dominance_info has this early exit:
if (!dom_info_available_p (fn, dir))
return;
So iterating through all funs with gimple bodies at the end of analyzer calling
free_dominance_info on them ought to clean things up - and seems to fix the
ICE.
However I'm having trouble writing a regression test for this, with the
combination of ubsan and lto: I get:
output is /usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status
Ideas on fixing welcome.
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 112975, which changed state. Bug 112975 Summary: [14 Regression] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's drivers/xen/privcmd.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112975 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug analyzer/112975] [14 Regression] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's drivers/xen/privcmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112975 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/112974] [14 Regression] -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112974 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 112974, which changed state. Bug 112974 Summary: [14 Regression] -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112974 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug analyzer/112974] [14 Regression] -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112974 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:c6cf5789135236c5639075c8f235e7dd461b6ff6 commit r14-9625-gc6cf5789135236c5639075c8f235e7dd461b6ff6 Author: David Malcolm Date: Fri Mar 22 10:57:25 2024 -0400 analyzer: look through casts in taint sanitization [PR112974,PR112975] PR analyzer/112974 and PR analyzer/112975 record false positives from the analyzer's taint detection where sanitization of the form if (VALUE CMP VALUE-OF-WIDER-TYPE) happens, but wasn't being "noticed" by the taint checker, due to the test being: (WIDER_TYPE)VALUE CMP VALUE-OF-WIDER-TYPE at the gimple level, and thus taint_state_machine recording sanitization of (WIDER_TYPE)VALUE, but not of VALUE. Fix by stripping casts in taint_state_machine::on_condition so that the state machine records sanitization of the underlying value. gcc/analyzer/ChangeLog: PR analyzer/112974 PR analyzer/112975 * sm-taint.cc (taint_state_machine::on_condition): Strip away casts before considering LHS and RHS, to increase the chance of detecting places where sanitization of a value may have happened. gcc/testsuite/ChangeLog: PR analyzer/112974 PR analyzer/112975 * gcc.dg/plugin/plugin.exp (plugin_test_list): Add taint-pr112974.c and taint-pr112975.c to analyzer_kernel_plugin.c. * gcc.dg/plugin/taint-pr112974.c: New test. * gcc.dg/plugin/taint-pr112975.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/112975] [14 Regression] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's drivers/xen/privcmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112975 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:c6cf5789135236c5639075c8f235e7dd461b6ff6 commit r14-9625-gc6cf5789135236c5639075c8f235e7dd461b6ff6 Author: David Malcolm Date: Fri Mar 22 10:57:25 2024 -0400 analyzer: look through casts in taint sanitization [PR112974,PR112975] PR analyzer/112974 and PR analyzer/112975 record false positives from the analyzer's taint detection where sanitization of the form if (VALUE CMP VALUE-OF-WIDER-TYPE) happens, but wasn't being "noticed" by the taint checker, due to the test being: (WIDER_TYPE)VALUE CMP VALUE-OF-WIDER-TYPE at the gimple level, and thus taint_state_machine recording sanitization of (WIDER_TYPE)VALUE, but not of VALUE. Fix by stripping casts in taint_state_machine::on_condition so that the state machine records sanitization of the underlying value. gcc/analyzer/ChangeLog: PR analyzer/112974 PR analyzer/112975 * sm-taint.cc (taint_state_machine::on_condition): Strip away casts before considering LHS and RHS, to increase the chance of detecting places where sanitization of a value may have happened. gcc/testsuite/ChangeLog: PR analyzer/112974 PR analyzer/112975 * gcc.dg/plugin/plugin.exp (plugin_test_list): Add taint-pr112974.c and taint-pr112975.c to analyzer_kernel_plugin.c. * gcc.dg/plugin/taint-pr112974.c: New test. * gcc.dg/plugin/taint-pr112975.c: New test. Signed-off-by: David Malcolm
[Bug c/114423] Incorrectly placed caret in the message about expanded _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114423
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #2 from Lewis Hyatt ---
libcpp is unfortunately not equipped to get valid locations when it lexes from
a _Pragma string. (It thinks it is lexing from a file as normal.) The locations
are wrong even without macros involved. The current situation is that we
produce invalid locations (that happen to usually be close to reasonable,
without macros, although they will be off by a few columns usually) for all the
tokens, then after lexing the tokens, we replace all of their locations with
the (valid) location of the _Pragma operator. This is good enough to make
_Pragma("GCC diagnostic") work and do the right thing (after many bug fixes
over the years), which has been the primary focus. But it means that any
diagnostics generated by libcpp during lexing itself have bad locations.
I submitted a rather large patch series a couple years ago that fixed it
comprehensively. The bulk of it is that the line_map class needs to be able to
handle locations for data that exist in memory and not in any file. Then all
code that uses line_map locations and all diagnostics code needs to be aware of
that concept and support it. The thread was left off here, for reference:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628290.html with the last
full patchset I sent being at
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626885.html. It worked
fine then, however a lot of interfaces have been changed since that time, and
so it would need to be rebased extensively now.
FWIW, with the above-linked patch series, on this example we output:
==
In buffer generated from t.cpp:1:
:1:11: error: message
1 | GCC error "message"
| ^
t.cpp:1:1: note: in <_Pragma directive>
1 | _Pragma("GCC error \"message\"")
| ^~~
In buffer generated from t.cpp:6:
:1:11: error: message
1 | GCC error "message"
| ^
t.cpp:4:1: note: in <_Pragma directive>
4 | _Pragma("GCC error \"message\"")
| ^~~
t.cpp:6:1: note: in expansion of macro ‘err’
6 | err
| ^~~
==
I am not sure why I stopped getting responses to that patch series. I was
disinclined to ping it further because I worried that it was perhaps deemed too
large and invasive, to fix what ends up being a rather minor problem in
practice? I think it would be doable to handle it with a more incremental
approach... we could at least achieve that diagnostics generated during lexing
get assigned to the valid location of the _Pragma operator instead of an
invalid one.
[Bug c++/59465] [11/12/13 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465 Marek Polacek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] g++ |g++ allows |allows |direct-initialization of an |direct-initialization of an |array of class type from|array of class type from |another array in a |another array in a |mem-initializer |mem-initializer Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Fixed in GCC 14. I don't think I'll backport it.
[Bug c++/59465] [11/12/13/14 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d1d8fd2884b44598d80de1038b086eec41519d4b
commit r14-9622-gd1d8fd2884b44598d80de1038b086eec41519d4b
Author: Marek Polacek
Date: Thu Feb 22 18:49:08 2024 -0500
c++: direct-init of an array of class type [PR59465]
...from another array in a mem-initializer should not be accepted.
We already reject
struct string {} a[1];
string x[1](a);
but
struct pair {
string s[1];
pair() : s(a) {}
};
is wrongly accepted.
It started to be accepted with r0-110915-ga034826198b771:
which was supposed to be a cleanup, not a deliberate change to start
accepting the code. The build_vec_init_expr code was added in r165976:
.
It appears that we do the magic copy array when we have a defaulted
constructor and we generate code for its mem-initializer which
initializes an array. I also see that we go that path for compound
literals. So when initializing an array member, we can limit building
up a VEC_INIT_EXPR to those special cases.
PR c++/59465
gcc/cp/ChangeLog:
* init.cc (can_init_array_with_p): New.
(perform_member_init): Check it.
gcc/testsuite/ChangeLog:
* g++.dg/init/array62.C: New test.
* g++.dg/init/array63.C: New test.
* g++.dg/init/array64.C: New test.
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #9 from John David Anglin --- These two fails are different and not addressed by patch: FAIL: std/text_encoding/cons.cc -std=gnu++26 (test for excess errors) UNRESOLVED: std/text_encoding/cons.cc -std=gnu++26 compilation failed to produce executable FAIL: std/text_encoding/requirements.cc -std=gnu++26 (test for excess errors) FAIL: std/text_encoding/cons.cc -std=gnu++26 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/std/text_encoding/cons.cc:12: erro r: 'text_encoding' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/std/text_encoding/cons.cc:13: erro r: 'e0' was not declared in this scope; did you mean 'y0'? [...]
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #17 from Sam James --- Created attachment 57780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57780=edit EarlyCSE.cpp.cpp.182t.cunroll-bad
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #16 from Sam James --- -fdisable-tree-cunroll seems to help.
[Bug target/114432] [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #6 from Jakub Jelinek ---
Though, guess it would help if evrp avoided undesirable propagation here:
It is changing:
:
# DEBUG BEGIN_STMT
_8 = .ADD_OVERFLOW (d_7(D), 0);
_1 = IMAGPART_EXPR <_8>;
_2 = (_Bool) _1;
# DEBUG o => (int) _2
# DEBUG BEGIN_STMT
a.0_3 = a;
_4 = (_BitInt(2000)) a.0_3;
c.1_5 = c;
m_11 = _4 * c.1_5;
# DEBUG m => m_11
# DEBUG BEGIN_STMT
u_12 = (unsigned int) m_11;
# DEBUG u => u_12
# DEBUG BEGIN_STMT
- o.2_6 = (unsigned int) _2;
+ o.2_6 = (unsigned int) _1;
_13 = o.2_6 + u_12;
return _13;
}
which is surely possible because IMAGPART_EXPR of .{ADD,SUB,MUL}_OVERFLOW has
[0, 1]
range, but for such large/huge _BitInt IMAGPART_EXPR it extends the lifetime of
an expensive large variable rather than just being a boolean.
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #5 from Sam James --- FWIW, after doing more of this work, I've decided I don't really care that much about this one. I still think FP mismatches are often worse, but there's enough junk pointer type mismatches that I'm not sure we should provide this (it's not like one case is OK and the other is way less scary or something).
[Bug tree-optimization/95185] [11/12/13/14 Regression] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug c++/101463] [11/12/13/14 Regression] Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #20 from GCC Commits --- The master branch has been updated by Thomas Neumann : https://gcc.gnu.org/g:a364148530c28645ce87adbc58a66c9f32a325ab commit r14-9620-ga364148530c28645ce87adbc58a66c9f32a325ab Author: Thomas Neumann Date: Mon Mar 11 14:35:20 2024 +0100 handle unwind tables that are embedded within unwinding code [PR111731] Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 The unwinding mechanism registers both the code range and the unwind table itself within a b-tree lookup structure. That data structure assumes that is consists of non-overlappping intervals. This becomes a problem if the unwinding table is embedded within the code itself, as now the intervals do overlap. To fix this problem we now keep the unwind tables in a separate b-tree, which prevents the overlap. libgcc/ChangeLog: PR libgcc/111731 * unwind-dw2-fde.c: Split unwind ranges if they contain the unwind table.
[Bug target/102264] [11/12/13/14 Regression] extra spilling when using inline-asm and all registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #12 from Jeffrey A. Law --- Per c#7.
[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #23 from Patrick Palka --- (In reply to Jonathan Wakely from comment #22) > Here we go, this still fails on trunk, just by making the data member > private: That's because for a non-dependent conversion to a class type we only check it before constraints if it's an aggregate class (otherwise it might have a constructor template, which means the conversion might instantiate things making it unsafe to check before constraints). Maybe we should consider refining the heuristic further. I believe the code is strictly speaking invalid though.
[Bug middle-end/104088] [12/13/14 Regression] '-O2' (or higher) GCN offloading (only) 'libgomp.oacc-c-c++-common/vprop.c' excess errors: 'warning: writing 1 byte into a region of size 0 [-Wstringop-ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104088 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug c++/104995] [11/12/13/14 Regression] access checking for function pointer template parameters takes place at call site inside a templated (generic) lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104995 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug target/105275] [12/13/14 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug c++/105760] [11/12/13/14 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug debug/106955] [13/14 Regression] '-fcompare-debug' failure w/ -std=c++20 -O1 -ftree-parallelize-loops=2 -fno-ipa-sra --param ggc-min-expand=55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-22 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 57779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57779=edit gcc14-pr114425.patch Untested fix.
[Bug c++/107058] [11/12/13/14 Regression] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.cc:6038 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107058 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 108278, which changed state. Bug 108278 Summary: [13/14 Regression] runtime error with -O1 -Wall https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug middle-end/108278] [13/14 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #20 from Jeffrey A. Law --- Per c#16.
[Bug analyzer/108708] [13/14 Regression] __analyzer_dump_named_constant fails with derived values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108708 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug target/113357] [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from Jeffrey A. Law --- So given my bootstraps (qemu) are working the most likely scenarios are either a difference in the emulators or a difference in the configure setup. The first thing I would suggest would be to put the stage2 compiler under a debugger and find out why it faulted. That might help with understanding the problem. ie, are we segfaulting because we dereferenced a NULL pointer, or perhaps faulting because we did an unaligned access, or whatever. The next thing I would suggest would be extracting the .i file and confirming you can feed that to the stage2 cc1 and see the fault. Assuming you can, then you ought to be able to do an object bisection. ie, replace .o files for the failing stage with those from a previous stage, relink, retest. It'll take a while. But this usually results in finding a single trigger file. Once that's narrowed down we can figure out the next steps.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #15 from Richard Biener --- The valgrind output might be because we vectorize the loads a[i], a[i+8], ... as full vector loads at a[i], a[i+8] but the last we access as scalar. So the uninit load might be harmless.
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Jakub Jelinek --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >> FWIW, the iconv conversion tables in /usr/lib/iconv can be regenerated >> from the OpenSolaris sources, modified not to do that '?' conversion. >> Worked for a quick check for the UTF-8 -> ASCII example, but the '?' is >> more prevalent and would need to be eradicated upstream. > > If it is always '?' used instead of unknown character, we could also have some > hack on the libcpp side for it. It took me a bit to get back to you here since I had to check with both Solaris engineering and dig up our old Solaris 9 sources (which, unlike, OpenSolaris, have no relevant parts missing due to copyright issues). Both what I found in the iconv conversion tables and what's documented in unicode_iconv(7) confirms the consistent use of '?'. The manpage has If the source character code value is not within a range defined by the source codeset standard, it is considered as an illegal character. If the source character code value is within the range(s) defined by the standard, it will be considered as non-identical, even if the source character code value maps to an undefined or a reserved location within the valid range. The non-identical character will map to either ? (0x3f in ASCII-compatible codesets) if the target codeset is a non-Unicode codeset or to Unicode replacement character (U+FFFD) if the target codeset is an Unicode codeset. It will of course be in the respective charset's encoding (0x3f for ASCII, 0x6f for EBCDIC), but that's all I could find. This is not a complete guarantee (I may well have missed something), but seems plausible enough... > Like (but limited to Solaris hosts) in convert_using_iconv when converting > from > SOURCE_CHARSET to some other character set don't try to convert the whole > UTF-8 > string at once, but split it into chunks at u'?' characters, so > foo???bar?baz?qux > would be iconv converted as > foo > ??? > bar > ? > baz > ? > qux > chunks. And when converting the non-? chunks, it would after the conversion > check for the '?' character (in the destination character set - that is > something that perhaps could be queried during initialization after > iconv_open) > and treat it as an error if it appeared there. Or always convert also back to > UTF-8 and check if it has more '?' characters than the source. Unless we want to take the easy way out and just require GNU libiconv on Solaris, that seems like a plausible way of handling the issue.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #14 from Richard Biener ---
There are a few vectorizations in the dumps but only one early-exit where
we vectorize
[local count: 102053600]:
first$I_39 = MEM[(struct value_op_iterator *)];
last$I_40 = MEM[(struct value_op_iterator *)];
seed_15 = llvm::hashing::detail::get_execution_seed ();
if (first$I_39 != last$I_40)
goto ; [94.50%]
[local count: 96440652]:
[local count: 179229733]:
# buffer_ptr_22 = PHI <_20(24), (22)>
# first$I_24 = PHI <_29(24), first$I_39(22)>
# ivtmp_226 = PHI
_20 = buffer_ptr_22 + 8;
ivtmp_216 = ivtmp_226 - 1;
if (ivtmp_216 == 0)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 87607493]:
_30 = MEM[(const struct Use *)first$I_24].Val;
_35 = (unsigned long) _30;
MEM [(char * {ref-all})buffer_ptr_22] = _35;
_29 = first$I_24 + 32;
if (_29 != last$I_40)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 82789081]:
goto ; [100.00%]
[local count: 96440652]:
# buffer_ptr_248 = PHI <_20(4), buffer_ptr_22(3)>
# first$I_175 = PHI
if (last$I_40 == first$I_175)
...
as far as I can see that's a non-peeled case and from what I see it looks
OK how we process that.
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug analyzer/110285] [13/14 Regression] -Wanalyzer-infinite-recursion false positive involving floating-point values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug c++/110401] [11/12/13/14 Regression] Unhelpful "goto is not a constant expression" in ill-formed pre c++20 constexpr function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug libgomp/110842] [14 Regression] Openmp loops with KIND=16 DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110842 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug fortran/110987] [13/14 Regression] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
