[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[dkm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

--- Comment #12 from Marc Poulhiès  ---
I can confirm both our riscv32/64 builds are back to normal, thanks!

[Bug testsuite/115365] New test case gcc.dg/pr100927.c from r15-1022-gb05288d1f1e4b6 fails

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115365

--- Comment #7 from Hongtao Liu  ---
+/* { dg-final { scan-rtl-dump-times {(?n)^(?!.*REG_EQUIV)(?=.*\(fix:SI)} 3
"final" } }  */

Does this fix the testcase on solaris2?

[Bug c/114493] [11/12/13 Regression] internal compiler error: in fld_incomplete_type_of with may_alias

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493

--- Comment #14 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:7813d94393f60ac641265cb3fc3a446f9f3aea7e

commit r13-8838-g7813d94393f60ac641265cb3fc3a446f9f3aea7e
Author: Jakub Jelinek 
Date:   Thu Jun 6 22:12:11 2024 +0200

c: Fix up pointer types to may_alias structures [PR114493]

The following testcase ICEs in ipa-free-lang, because the
fld_incomplete_type_of
  gcc_assert (TYPE_CANONICAL (t2) != t2
  && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE
(t)));
assertion doesn't hold.
This is because t is a struct S * type which was created while struct S
was still incomplete and without the may_alias attribute (and
TYPE_CANONICAL
of a pointer type is a type created with can_alias_all = false argument),
while later on on the struct definition may_alias attribute was used.
fld_incomplete_type_of then creates an incomplete distinct copy of the
structure (but with the original attributes) but pointers created for it
are because of the "may_alias" attribute TYPE_REF_CAN_ALIAS_ALL, including
their TYPE_CANONICAL, because while that is created with !can_alias_all
argument, we later set it because of the "may_alias" attribute on the
to_type.

This doesn't ICE with C++ since PR70512 fix because the C++ FE sets
TYPE_REF_CAN_ALIAS_ALL on all pointer types to the class type (and its
variants) when the may_alias is added.

The following patch does that in the C FE as well.

2024-06-06  Jakub Jelinek  

PR c/114493
* c-decl.cc (c_fixup_may_alias): New function.
(finish_struct): Call it if "may_alias" attribute is
specified.

* gcc.dg/pr114493-1.c: New test.
* gcc.dg/pr114493-2.c: New test.

(cherry picked from commit d5a3c6d43acb8b2211d9fb59d59482d74c010f01)

[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:f9db8b0571348adfcc98204ea7be787058af85cd

commit r13-8836-gf9db8b0571348adfcc98204ea7be787058af85cd
Author: Jakub Jelinek 
Date:   Tue Jun 4 12:28:01 2024 +0200

builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow [PR108789]

The following testcase is miscompiled, because we use save_expr
on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first
two operands are not INTEGER_CSTs (in that case we just fold it right away)
but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually
create a SAVE_EXPR at all and so we lower it to
*arg2 = REALPART_EXPR (.ADD_OVERFLOW (arg0, arg1)), \
IMAGPART_EXPR (.ADD_OVERFLOW (arg0, arg1))
which evaluates the ifn twice and just hope it will be CSEd back.
As *arg2 aliases *arg0, that is not the case.
The builtins are really never const/pure as they store into what
the third arguments points to, so after handling the
INTEGER_CST+INTEGER_CST
case, I think we should just always use SAVE_EXPR.  Just building SAVE_EXPR
by hand and setting TREE_SIDE_EFFECTS on it doesn't work, because
c_fully_fold optimizes it away again, so the following patch marks the
ifn calls as TREE_SIDE_EFFECTS (but doesn't do it for the
__builtin_{add,sub,mul}_overflow_p case which were designed for use
especially in constant expressions and don't really evaluate the
realpart side, so we don't really need a SAVE_EXPR in that case).

2024-06-04  Jakub Jelinek  

PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr.

* gcc.c-torture/execute/pr108789.c: New test.

(cherry picked from commit b8e28381cb5c0cddfe5201faf799d8b27f5d7d6c)

[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337

--- Comment #14 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:865d60ab4edbdb10d13000af81f9168fd3816a86

commit r13-8837-g865d60ab4edbdb10d13000af81f9168fd3816a86
Author: Jakub Jelinek 
Date:   Tue Jun 4 15:49:41 2024 +0200

fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]

The function currently incorrectly assumes all the __builtin_clz* and .CLZ
calls have non-negative result.  That is the case of the former which is UB
on zero and has [0, prec-1] return value otherwise, and is the case of the
single argument .CLZ as well (again, UB on zero), but for two argument
.CLZ is the case only if the second argument is also nonnegative (or if we
know the argument can't be zero, but let's do that just in the ranger
IMHO).

The following patch does that.

2024-06-04  Jakub Jelinek  

PR tree-optimization/115337
* fold-const.cc (tree_call_nonnegative_warnv_p) :
If fn is CFN_CLZ, use CLZ_DEFINED_VALUE_AT.

(cherry picked from commit b82a816000791e7a286c7836b3a473ec0e2a577b)

[Bug target/115324] [12/13 Regression] PCH of rs6000 builtins broken

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:50b5019fde97c20a377e004c9d73df62e4898773

commit r13-8834-g50b5019fde97c20a377e004c9d73df62e4898773
Author: Jakub Jelinek 
Date:   Mon Jun 3 23:11:06 2024 +0200

rs6000: Fix up PCH in --enable-host-pie builds [PR115324]

PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or &rs6000_instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
  {
&rs6000_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
  },
  {
&rs6000_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
  },
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them
back
in full.  While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.

So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.

Size-wise in .data sections it is (in bytes):

 vanillapatched
rs6000_builtin_info  130832 110704
rs6000_instance_info  81568  40784
rs6000_overload_info   7392   7392
rs6000_builtin_info_fntype0  10064
rs6000_instance_info_fntype   0  20392
sum  219792 189336

where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.

Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.

When I applied
 void
 rs6000_init_generated_builtins ()
 {
+  bifdata *rs6000_builtin_info_p;
+  tree *rs6000_builtin_info_fntype_p;
+  ovlddata *rs6000_instance_info_p;
+  tree *rs6000_instance_info_fntype_p;
+  ovldrecord *rs6000_overload_info_p;
+  __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+  __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+  __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+  __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+  __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+  #define rs6000_builtin_info rs6000_builtin_info_p
+  #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+  #define rs6000_instance_info rs6000_instance_info_p
+  #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+  #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments.  If you want such a change,
could that be done incrementally?

2024-06-03  Jakub Jelinek  

PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members.  Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *.  Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_info_fntype and rs6000_in

[Bug rtl-optimization/114902] [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902

--- Comment #17 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:8deaab6f79768700e1bf05fe6af83b185f678b7f

commit r13-8833-g8deaab6f79768700e1bf05fe6af83b185f678b7f
Author: Jakub Jelinek 
Date:   Wed May 15 18:37:17 2024 +0200

combine: Fix up simplify_compare_const [PR115092]

The following testcases are miscompiled (with tons of GIMPLE
optimization disabled) because combine sees GE comparison of
1-bit sign_extract (i.e. something with [-1, 0] value range)
with (const_int -1) (which is always true) and optimizes it into
NE comparison of 1-bit zero_extract ([0, 1] value range) against
(const_int 0).
The reason is that simplify_compare_const first (correctly)
simplifies the comparison to
GE (ashift:SI something (const_int 31)) (const_int -2147483648)
and then an optimization for when the second operand is power of 2
triggers.  That optimization is fine for power of 2s which aren't
the signed minimum of the mode, or if it is NE, EQ, GEU or LTU
against the signed minimum of the mode, but for GE or LT optimizing
it into NE (or EQ) against const0_rtx is wrong, those cases
are always true or always false (but the function doesn't have
a standardized way to tell callers the comparison is now unconditional).

The following patch just disables the optimization in that case.

2024-05-15  Jakub Jelinek  

PR rtl-optimization/114902
PR rtl-optimization/115092
* combine.cc (simplify_compare_const): Don't optimize
GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or
EQ op0 const0_rtx.

* gcc.dg/pr114902.c: New test.
* gcc.dg/pr115092.c: New test.

(cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)

[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092

--- Comment #14 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:8deaab6f79768700e1bf05fe6af83b185f678b7f

commit r13-8833-g8deaab6f79768700e1bf05fe6af83b185f678b7f
Author: Jakub Jelinek 
Date:   Wed May 15 18:37:17 2024 +0200

combine: Fix up simplify_compare_const [PR115092]

The following testcases are miscompiled (with tons of GIMPLE
optimization disabled) because combine sees GE comparison of
1-bit sign_extract (i.e. something with [-1, 0] value range)
with (const_int -1) (which is always true) and optimizes it into
NE comparison of 1-bit zero_extract ([0, 1] value range) against
(const_int 0).
The reason is that simplify_compare_const first (correctly)
simplifies the comparison to
GE (ashift:SI something (const_int 31)) (const_int -2147483648)
and then an optimization for when the second operand is power of 2
triggers.  That optimization is fine for power of 2s which aren't
the signed minimum of the mode, or if it is NE, EQ, GEU or LTU
against the signed minimum of the mode, but for GE or LT optimizing
it into NE (or EQ) against const0_rtx is wrong, those cases
are always true or always false (but the function doesn't have
a standardized way to tell callers the comparison is now unconditional).

The following patch just disables the optimization in that case.

2024-05-15  Jakub Jelinek  

PR rtl-optimization/114902
PR rtl-optimization/115092
* combine.cc (simplify_compare_const): Don't optimize
GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or
EQ op0 const0_rtx.

* gcc.dg/pr114902.c: New test.
* gcc.dg/pr115092.c: New test.

(cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)

[Bug libstdc++/115420] Default constructor of unordered_map deleted

[krebbel at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420

Andreas Krebbel  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug libstdc++/115420] Default constructor of unordered_map deleted

[krebbel at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|INVALID |FIXED

--- Comment #2 from Andreas Krebbel  ---
Oh right, didn't make the connection from the error message to the header file
rearrangements. Thanks for the pointer!

[Bug target/115418] Extra movapd emitted for MAX implementation

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115418

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #3 from Hongtao Liu  ---
(In reply to Andrew Pinski from comment #2)
> Note the issue is ix86_expand_sse_fp_minmax only handles LT/UNGE but it
> should handle GT/UNLT with both parts swapped (comparison and true/false).
> 
GT/UNLT is "canonicalized" to GT/UNGT in ix86_prepare_sse_fp_compare_args
 4410case GE:
 4411case GT:
 4412case UNLE:
 4413case UNLT:
 4414  /* These are not supported directly before AVX, and furthermore
 4415 ix86_expand_sse_fp_minmax only optimizes LT/UNGE.  Swap the
 4416 comparison operands to transform into something that is
 4417 supported.  */
 4418  std::swap (*pop0, *pop1);
 4419  code = swap_condition (code);

[Bug testsuite/115365] New test case gcc.dg/pr100927.c from r15-1022-gb05288d1f1e4b6 fails

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115365

Hongtao Liu  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu,  |powerpc64le-linux-gnu,
   |sparc-sun-solaris2.11   |sparc-sun-solaris2.11,
   ||arm-eabi, cortex-m0

--- Comment #6 from Hongtao Liu  ---
Also failed arm-eabi cortex-m0

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406

--- Comment #6 from Hongtao Liu  ---
For 1 element vector, when backend doesn't support it's vector mode, the scalar
mode is used for the type, which makes expand_vec_cond_expr_p use QImode for
icode check.(vcond_mask_qiqi)

It could also be the case when both data type and cmp_type are
vector_boolean_type.

It looks like vcond_mask_qiqi is dichotomous.
For the former, it should be 
  operands[3] == 1 ? operands[1] : operands[2]

since mask is vector 1 boolean.

For the latter, it should be
 (operand[1] & operand[3]) | (operand[2] & ~operand[3]) 


BTW, when assign -1 to vector(1) , should the upper bit be
cleared? Look like only 1 element boolean vector is cleared, but not vector(2)
.
If the upper bits are not cleared, both 2 cases are equal.

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312

Brecht Sanders  changed:

   What|Removed |Added

 CC||brechtsanders at users dot 
sourcef
   ||orge.net

--- Comment #2 from Brecht Sanders  
---
I have made a native Windows MinGW-w64 build where the lines "gcc_assert
(!the_parser);" were commented out in file gcc/cp/parser.cc and got
confirmation this successfully works around the issue.

See: https://github.com/brechtsanders/winlibs_mingw/issues/199

[Bug tree-optimization/115423] Inlined strcmp optimizes poorly

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115423

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c/115424] 'auto' type inference not working when struct declared in rhs, even when the final type is not anonymous

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115424

--- Comment #1 from Andrew Pinski  ---
Hmm from the commit message (r13-3620-ge3c898e12d0ace):
```
* The standard feature disallows the declaration from declaring
  anything that's not an ordinary identifier (thus, the initializer
  cannot declare a tag or the members of a structure or union), while
  making it undefined behavior for it to declare more than one
  ordinary identifier.  (For the latter, while I keep the existing
  error from __auto_type in the case of more than one declarator, I
  don't restrict other ordinary identifiers from being declared in
  inner scopes such as GNU statement expressions.  I do however
  disallow defining the members of an enumeration inside the
  initializer (if the enum definition has no tag, that doesn't
  actually violate a constraint), to avoid an enum type becoming
  accessible beyond where it would have been without auto.
  (Preventing new types from escaping the initializer - thus, ensuring
  that anything written with auto corresponds to something that could
  have been written without auto, modulo multiple evaluation of VLA
  size expressions when not using auto - is a key motivation for some
  restrictions on what can be declared in the initializer.)

The rule on shadowing and restrictions on other declarations in the
initializer are actually general rules for what C2x calls
underspecified declarations, a description that covers constexpr as
well as auto (in particular, this disallows a constexpr initializer
from referencing the variable being initialized).  Thus, some of the
code added for those restrictions will also be of use in implementing
C2x constexpr.

```

So this might be expected.

[Bug c++/115425] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425

--- Comment #1 from Andrew Pinski  ---
> 15 regressions

It might not be because this is a checking enabled ICE.

[Bug tree-optimization/115426] ICE: in execute_todo, at passes.cc:2138

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115426

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Reduced testcase that ICEs on all targets:
```
 _Complex float fcs() {
  _Complex float r;
  __asm__(""  : "=X" (__imag__ r)  );
  return r;
 } 
```

Looks like this has been ICEing for a while with checking enabled.

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406

--- Comment #5 from Hongtao Liu  ---
>   _2 = VEC_COND_EXPR <_1, { -1 }, { 0 }>;

Hmm, it should check vcond_mask_qiv1qi instead of vcond_mask_qiqi, I guess
since the backend doesn't supports v1qi, TYPE_MODE of V is QImode, then it
wrongly checked vcond_mask_qiqi.

[Bug c/115426] New: ICE in execute_todo, at passes.cc:2138

[iamanonymous.cs at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115426

Bug ID: 115426
   Summary: ICE in execute_todo, at passes.cc:2138
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error when compiling the provided code with
the specified options. 
The issue occurs during the GIMPLE pass (walloca), causing an internal compiler
error in the execute_todo function at passes.cc:2138.
***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program:
# cat fam-asm.c

 #include 
 #include  

 _Complex float fcs(_Complex float x) {
  float ixy;
  float diff, sum;
  _Complex float r;
  __asm__("fmul %s[ixy], %s[xr], %s[yr]\n"
  "\tfsub %s[diff], %s[xr], %s[yr]\n"
  "\tfadd %s[sum],  %s[xr], %s[yr]\n"
  "\tfmul %s[rr],  %s[diff], %s[sum]\n"
  "\tfadd %s[ri],  %s[ixy], %s[ixy]\n"
  : [ixy] "=&w" (ixy), [diff] "=&w" (diff), [sum] "=w" (sum), [rr] "=w"
(__real__ r), [ri] "=w" (__imag__ r)
  : [xr] "w" (__real__ x), [yr] "w"( __imag__ x)
  : );
  return r;
 }

 int main(int argc, char *argv[])
 {
  _Complex float i = 0.0f + I * 1.0f;
  _Complex float i2 = fcs(i);
  printf("%f+i%f\n", __real__ i2, __imag__ i2);
 }


***
Command Lines:
# gcc fam-asm.c -Wall -Wextra  -o fam-asm.out
fam-asm.c: In function ‘main’:
fam-asm.c:19:15: warning: unused parameter ‘argc’ [-Wunused-parameter]
   19 |  int main(int argc, char *argv[])
  |   ^~~~
fam-asm.c:19:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
   19 |  int main(int argc, char *argv[])
  | ~~^~
during GIMPLE pass: walloca
fam-asm.c: In function ‘fcs’:
fam-asm.c:24:2: internal compiler error: in execute_todo, at passes.cc:2138
   24 |  }
  |  ^
0x839f1b execute_todo
/root/gdbtest/gcc/obj/../gcc/gcc/passes.cc:2138
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

***

Also ICE on trunk, compiler explorer:https://godbolt.org/z/soaoeW5z7

***

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406

--- Comment #4 from Hongtao Liu  ---

> 
> and for _2 = VIEW_CONVERT_EXPR(_1); we explicitly
> clear the upper bits due to PR113576, and then we get 1 hit the abort.
It's not VIEW_CONVERT_EXPR clear the uppper bits, but _1 = { -1 };

[Bug c++/115425] New: ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425

Bug ID: 115425
   Summary: ICE: tree check: expected type_pack_expansion or
expr_pack_expansion, have error_mark in
tsubst_pack_expansion, at cp/pt.cc:13778
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This seems like 15 regressions and may related to the constexpr static local
variable.

https://godbolt.org/z/sf4f3Woqa

#include 

template
void foo(std::index_sequence);

template
struct S;

template
auto test() {
  using Seq = std::make_index_sequence>;
  constexpr static auto x = foo();
  return [](std::index_sequence) {
(typename S::type{}, ...);
  }(std::make_index_sequence<0>{});
}

int main() {
  test>();
}

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406

--- Comment #3 from Hongtao Liu  ---
typedef __attribute__((__vector_size__ (1))) char V;

char
foo (V v)
{
  return ((V) v == v)[0];
}

int
main ()
{
  char x = foo ((V) { });
  if (x != -1)
__builtin_abort ();
}

w/ vcond_mask_qiqi, it's not lowered by veclower, and we get

char foo (V v)
{
  vector(1) signed char D.5142;
  char D.5141;
  vector(1)  _1;
  vector(1) signed char _2;
  char _5;

   :
  _1 = { -1 };
  _2 = VEC_COND_EXPR <_1, { -1 }, { 0 }>;
  D.5142 = _2;
  _5 = VIEW_CONVERT_EXPR(D.5142);

   :
:
  return _5;
}

But it's further simplified to 

char foo (V v)
{
  vector(1) signed char D.3765;
  char D.3764;
  vector(1)  _1;
  vector(1) signed char _2;
  char _5;

   :
  _1 = { -1 };
  _2 = VIEW_CONVERT_EXPR(_1);
  D.3765 = _2;
  _5 = VIEW_CONVERT_EXPR(D.3765);

   :
:
  return _5;

}

by isel

and for _2 = VIEW_CONVERT_EXPR(_1); we explicitly clear
the upper bits due to PR113576, and then we get 1 hit the abort.

It sound to me 
  _1 = { -1 };
  _2 = VEC_COND_EXPR <_1, { -1 }, { 0 }>;
shouldn't be simplified to 
_2 = VIEW_CONVERT_EXPR(_1);

when nunits is less than mode precision since the upper bit will be cleared.

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406

Hongtao Liu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Hongtao Liu  ---
I'll take a look.

[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088 since r15-1047-g7876cde25cbd2f

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115384

Hongtao Liu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Hongtao Liu  ---
Mine.

[Bug c/115424] New: 'auto' type inference not working when struct declared in rhs, even when the final type is not anonymous

[malekwryyy at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115424

Bug ID: 115424
   Summary: 'auto' type inference not working when struct declared
in rhs, even when the final type is not anonymous
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malekwryyy at gmail dot com
  Target Milestone: ---

for example this code:

```
int main()
{
auto x = (struct { int i; }){1}.i;
}
```

Compiling the above with gcc 15.0 give the following error:

```
: In function 'main':
:6:15: error: 'struct ' defined in underspecified object
initializer
6 | auto x = (struct { int i; }){1}.i;
  |   ^~
Compiler returned: 1
```

When I replace it with 'typeof' it compiles fine:


```
int main()
{
typeof((struct { int i; }){1}.i) x = (struct { int i; }){1}.i;
}
```

[Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly

[blubban at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115423

Bug ID: 115423
   Summary: Inlined strcmp optimizes poorly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

bool g(const char* c) {
return __builtin_strcmp(c, ".") == 0 ||
   __builtin_strcmp(c, "..") == 0;
}
bool h(const char* c) {
return (c[0] == '.' && c[1] == '\0') ||
   (c[0] == '.' && c[1] == '.' && c[2] == '\0');
}


Compile with -O2.


Expected result: Same output from both.

Actual: The former results in a mess that, among other inefficiencies, loads
c[0] twice.


Online reproducer: https://godbolt.org/z/E4vEshvcM


(I don't know if this is an RTL or tree optimizer issue, I just guessed. Feel
free to move it if it's wrong.)

[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1

[law at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-10
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jeffrey A. Law  ---
It looks like the test wants to see xxsel, but after that change we get xxlor
and  what looks like a slight difference in register allocation.  I can't
really judge if the new code is better, worse is equivalent.

*** good.s  2024-06-10 16:33:48.717342836 -0600
--- bad.s   2024-06-10 16:34:01.005143026 -0600
*** test:
*** 36,45 
lxvd2x 0,8,9
vcmpequw 1,1,12
vcmpequw 0,0,13
!   xxsel 33,12,33,33
!   xxsel 32,0,32,32
!   stxvd2x 33,9,10
!   stxvd2x 32,8,9
addi 9,9,32
bdnz .L2
blr
--- 36,45 
lxvd2x 0,8,9
vcmpequw 1,1,12
vcmpequw 0,0,13
!   xxlor 12,12,33
!   xxlor 0,0,32
!   stxvd2x 12,9,10
!   stxvd2x 0,8,9
addi 9,9,32
bdnz .L2
blr

Incorrect message "'--jobserver-auth=' is not present in MAKEFLAGS"

[Richard Copley via Gcc-bugs]

There is a missing "else" in 'jobserver_info::jobserver_info' in
"opts-common.cc".

As a result, if MAKEFLAGS is set and contains "--jobserver-auth=" and
the jobserver auth string is not in one of the expected formats, then
the message '"--jobserver-auth=' is not present in MAKEFLAGS" is
printed. The message apparently intended in that case, "cannot access
'--jobserver-auth=' file descriptors", can never be printed.

Native Windows builds of GNU make put the name of a named semaphore in
the auth string, as "--jobserver-auth=gmake_semaphore_22416". (This is
"--jobserver-style=sem" and is the only available style in native
Windows GNU Make, as of Make 4.4.) It would be nice to mention in the
"-flto" documentation that this is not supported.

[Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404

Sergei Trofimovich  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #6 from Sergei Trofimovich  ---
Yeah, fixed by https://gcc.gnu.org/PR115387#c10. Declaring duplicate. Thanks
all!

*** This bug has been marked as a duplicate of bug 115387 ***

[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #11 from Sergei Trofimovich  ---
*** Bug 115404 has been marked as a duplicate of this bug. ***

[Bug target/115362] fixed_size_simd dot product recognition and sign of determinant not working for stdx::reduce

[jondaniel879 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362

--- Comment #19 from Jon Daniel  ---
Created attachment 58401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58401&action=edit
dotsimd clang asssemly output

[Bug target/115362] fixed_size_simd dot product recognition and sign of determinant not working for stdx::reduce

[jondaniel879 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362

Jon Daniel  changed:

   What|Removed |Added

  Attachment #58359|0   |1
is obsolete||
  Attachment #58360|0   |1
is obsolete||

--- Comment #18 from Jon Daniel  ---
Created attachment 58400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58400&action=edit
dotsimd gcc asssemly output

[Bug target/115362] fixed_size_simd dot product recognition and sign of determinant not working for stdx::reduce

[jondaniel879 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362

Jon Daniel  changed:

   What|Removed |Added

  Attachment #58367|0   |1
is obsolete||

--- Comment #17 from Jon Daniel  ---
Created attachment 58399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58399&action=edit
dot product and determinant testcase

g++ -march=native -mfpmath=sse -mavx2 -O3 -std=gnu++26 dotsimd.cpp

[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:d03ff3fd3e2da1352a404e3c53fe61314569345c

commit r15-1167-gd03ff3fd3e2da1352a404e3c53fe61314569345c
Author: Pan Li 
Date:   Mon Jun 10 14:13:38 2024 -0600

[PATCH v1] Widening-Mul: Fix one ICE of gcall insertion for PHI match

When enabled the PHI handing for COND_EXPR,  we need to insert the gcall
to replace the PHI node.  Unfortunately,  I made a mistake that insert
the gcall to before the last stmt of the bb.  See below gimple,  the PHI
is located at no.1 but we insert the gcall (aka no.9) to the end of
the bb.  Then the use of _9 in no.2 will have no def and will trigger
ICE when verify_ssa.

  1. # _9 = PHI <_3(4), 18446744073709551615(3)> // The PHI node to be
deleted.
  2. prephitmp_36 = (char *) _9;
  3. buf.write_base = string_13(D);
  4. buf.write_ptr = string_13(D);
  5. buf.write_end = prephitmp_36;
  6. buf.written = 0;
  7. buf.mode = 3;
  8. _7 = buf.write_end;
  9. _9 = .SAT_ADD (string.0_2, maxlen_15(D));   // Insert gcall to last bb
by mistake

This patch would like to insert the gcall to before the start of the bb
stmt.  To ensure the possible use of PHI_result will have a def exists.
After this patch the above gimple will be:

  0. _9 = .SAT_ADD (string.0_2, maxlen_15(D));   // Insert gcall to start
bb by mistake
  1. # _9 = PHI <_3(4), 18446744073709551615(3)> // The PHI node to be
deleted.
  2. prephitmp_36 = (char *) _9;
  3. buf.write_base = string_13(D);
  4. buf.write_ptr = string_13(D);
  5. buf.write_end = prephitmp_36;
  6. buf.written = 0;
  7. buf.mode = 3;
  8. _7 = buf.write_end;

The below test suites are passed for this patch:
* The rv64gcv fully regression test with newlib.
* The rv64gcv build with glibc.
* The x86 regression test with newlib.
* The x86 bootstrap test with newlib.

PR target/115387

gcc/ChangeLog:

* tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children):
Take
the gsi of start_bb instead of last_bb.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr115387-1.c: New test.
* gcc.target/riscv/pr115387-2.c: New test.

[Bug target/115409] avx512 intrinsics trigger -Wshift-overflow

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115409

Eric Gallager  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||4016.html
 CC||egallager at gcc dot gnu.org
   Keywords||patch

--- Comment #4 from Eric Gallager  ---
(In reply to Collin Funk from comment #3)
> I'll read the page you sent and send a patch to gcc-patches referencing this
> bug report.

Linking the sent patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654016.html

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #13 from Andrew Pinski  ---
(In reply to Liviu Ionescu from comment #12)
> Isn't it possible to fix libstdc++ in order to run static multi-threaded
> apps on older systems too?

Well it depends. glibc changed how libpthread works in 2.34 and above. So
someone with the specific versions that you are testing with need to debug it
to see what is going wrong. It might need `-Wl,--whole-archive -lpthread
-Wl,--no-whole-archive` as mentioned in PR 58909 or some other changes.

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #12 from Liviu Ionescu  ---
However Debian 12 is not that old, what might be wrong with it? The initial
report is based on a Debian 12 run. I did another run on a physical Debian 12
and the issue is reproducible on my machine.

Isn't it possible to fix libstdc++ in order to run static multi-threaded apps
on older systems too?

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #11 from Liviu Ionescu  ---
I did two more runs, one on latest Raspberry Pi OS and one with latest Manjaro,
and they also passed.

So the problem seems indeed related to older systems.

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #10 from Liviu Ionescu  ---
> Are you sure that arch does not patch glibc to make it broken?

That run was using docker://archlinux:latest, I don't know if glibc is broken.

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #9 from Sam James  ---
I can't reproduce the crash with Gentoo's glibc (`ld.so (Gentoo 2.39-r7
(patchset 7)) stable release version 2.39.`) and gcc 14/15 (tip of both
branches). I get 'abcd' both times.

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #8 from Liviu Ionescu  ---
A small correction, the first run should be without -static:

```
$ g++ sleepy-threads-cv.cpp -o sleepy-threads-cv -g -lpthread
$ ./sleepy-threads-cv 4
abcd
$ g++ sleepy-threads-cv.cpp -o static-sleepy-threads-cv -static -g -lpthread
$ ./static-sleepy-threads-cv 4
Segmentation fault
```

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #7 from Andrew Pinski  ---
Are you sure that arch does not patch glibc to make it broken?

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #6 from Andrew Pinski  ---
apinski@xeond:~/src/upstream-gcc-match$ /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.35-0ubuntu3.8) stable release version 2.35.
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 11.4.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
.
apinski@xeond:~/src/upstream-gcc-match$ ~/upstream-gcc-match/bin/g++ -static -g
-lpthread t.cc
apinski@xeond:~/src/upstream-gcc-match$ ./a.out
Usage: sleepy-thread N
apinski@xeond:~/src/upstream-gcc-match$ ./a.out  4
abcd

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #5 from Liviu Ionescu  ---
Here is a run on Arch, with 2.39:

```
Tests summary for gcc 13.3.0-1 on linux-x64 (Arch rolling)

394 test(s) passed, 4 failed:

- fail: static-sleepy-threads-cv-64
- fail: static-gc-sleepy-threads-cv-64
- fail: static-lto-sleepy-threads-cv-64
- fail: static-gc-lto-sleepy-threads-cv-64

Verdict: tests reluctantly accepted

[uname -a]
Linux f27625f70135 6.5.0-1021-azure #22~22.04.1-Ubuntu SMP Tue Apr 30 16:08:18
UTC 2024 x86_64 GNU/Linux

[lsb_release -a]
LSB Version:n/a
Distributor ID: Arch
Description:Arch Linux
Release:rolling
Codename:   n/a

[ldd --version]
ldd (GNU libc) 2.39
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
```

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> This works fine with glibc 2.34 and above.

I should say with glibc 2.34 and above and GCC 13+.
Other combinations are know to fail since you need to link in the whole
libpthread as there are weak symbols used to detect if the program was single
threaded or not.

[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f

[syq at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

--- Comment #6 from YunQiang Su  ---
(In reply to Marcus Calhoun-Lopez from comment #5)
> (In reply to YunQiang Su from comment #3)
> > Since it doesn't exist, why use --includedir with it?
> 
> /opt/local/include/gcc is where the header files will be installed after the
> build, so there is no reason for it to exist before the build.
> 

Normally, we build gcc for 1st stage with/without --includedir, 
and then build libc with 1st stage gcc, and install the libc into the
destination.
Then we build gcc stage2 with --includedir.


Ohh, in fact that I am worrying that both you and I have a mistake: the
--includedir may be used for host instead of target.

Should we introduce a new build-time option?

Background: I add this patch due to Debian's cross toolchain install headers
into /usr//include
instead of /usr//sys-include

[Bug libstdc++/115422] Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115422

Liviu Ionescu  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Liviu Ionescu  ---
Sorry for the noise, bugzilla asked to resubmit the attachment and entered the
duplicate.

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-10
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Andrew Pinski  ---
This works fine with glibc 2.34 and above.

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #2 from Andrew Pinski  ---
What version of glibc do you have?

[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

--- Comment #1 from Andrew Pinski  ---
*** Bug 115422 has been marked as a duplicate of this bug. ***

[Bug libstdc++/115422] Multi-threaded condition_variable app throws when linking as -static on Linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115422

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
.

*** This bug has been marked as a duplicate of bug 115421 ***

[Bug libstdc++/115422] New: Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115422

Bug ID: 115422
   Summary: Multi-threaded condition_variable app throws when
linking as -static on Linux
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ilg at livius dot net
  Target Milestone: ---

I have a test that checks C++ threads which synchronise via a
condition_variable.

The test runs fine on Linux/macOS/Windows, in various scenarios, except when I
build it as `-static` on Linux.

```
$ g++ sleepy-threads-cv.cpp -o sleepy-threads-cv -static -g -lpthread
$ ./static-sleepy-threads-cv 4
abcd
$ g++ sleepy-threads-cv.cpp -o static-sleepy-threads-cv -static -g -lpthread
$ ./static-sleepy-threads-cv 4
Segmentation fault
```

On some systems the result is an exception:

```
terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
```

I encountered the issue while building the xPack GCC 14 binaries, but later
confirmed it on GCC 13 and older. 

The source code is attached.inside 

The problem seems to be the global condition variable and/or mutex; if I move
them inside the `spawnThreads()` function and pass pointers to them to all
threads, the test is functional even with `-static`.

Is there anything wrong with my test, or is this a small bug in libstdc++?

[Bug libstdc++/115421] New: Multi-threaded condition_variable app throws when linking as -static on Linux

[ilg at livius dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421

Bug ID: 115421
   Summary: Multi-threaded condition_variable app throws when
linking as -static on Linux
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ilg at livius dot net
  Target Milestone: ---

Created attachment 58398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58398&action=edit
The test source code

I have a test that checks C++ threads which synchronise via a
condition_variable.

The test runs fine on Linux/macOS/Windows, in various scenarios, except when I
build it as `-static` on Linux.

```
$ g++ sleepy-threads-cv.cpp -o sleepy-threads-cv -static -g -lpthread
$ ./static-sleepy-threads-cv 4
abcd
$ g++ sleepy-threads-cv.cpp -o static-sleepy-threads-cv -static -g -lpthread
$ ./static-sleepy-threads-cv 4
Segmentation fault
```

On some systems the result is an exception:

```
terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
```

I encountered the issue while building the xPack GCC 14 binaries, but later
confirmed it on GCC 13 and older. 

The source code is attached.inside 

The problem seems to be the global condition variable and/or mutex; if I move
them inside the `spawnThreads()` function and pass pointers to them to all
threads, the test is functional even with `-static`.

Is there anything wrong with my test, or is this a small bug in libstdc++?

[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f

[marcuscalhounlopez at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

--- Comment #5 from Marcus Calhoun-Lopez  
---
(In reply to YunQiang Su from comment #3)
> Since it doesn't exist, why use --includedir with it?

/opt/local/include/gcc is where the header files will be installed after the
build, so there is no reason for it to exist before the build.

> Anyway, so, maybe we should detect the existence of this dir.
> Can you have a try of this patch?
> 
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -560,10 +560,11 @@ LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
>  # Default native SYSTEM_HEADER_DIR, to be overridden by targets.
>  NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@
>  # Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
> -ifeq (@includedir@,$(prefix)/include)
> -  CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
> -else
> -  CROSS_SYSTEM_HEADER_DIR = @includedir@
> +CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
> +ifneq (@includedir@,$(prefix)/include)
> +  ifneq (,$(wildcard @includedir@))
> +CROSS_SYSTEM_HEADER_DIR = @includedir@
> +  endif
>  endif

Yes, this seems to work.
Thank you very much.

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678

--- Comment #11 from John David Anglin  ---
(In reply to John David Anglin from comment #10)
> On hppa-linux, we have:
> 
> dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
> wait_for(0s): 363ns for 81820 calls, avg 48.8874ns per call
> wait_until(system_clock minimum): 15999855ns for 81820 calls, avg 195.549ns
> per call
> wait_until(steady_clock minimum): 1817ns for 81820 calls, avg 244.437ns
> per call
> wait_until(system_clock epoch): 327345016058ns for 81820 calls, avg
> 4.00079e+06ns per call
> wait_until(steady_clock epoch: 327417023513ns for 81820 calls, avg
> 4.00167e+06ns per call
> wait_for when ready: 0ns for 81820 calls, avg 0ns per call
> /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/future/members/poll.
> cc:129: int main(): Assertion 'wait_for_0 < (ready * 30)' failed.
> Aborted (core dumped)

HZ is 250.

[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f

[marcuscalhounlopez at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

--- Comment #4 from Marcus Calhoun-Lopez  
---
(In reply to YunQiang Su from comment #2)
> Can you give me the configure command, so that I can have a test.

The pertinent part of the configure command is
`configure --prefix=/opt/local --includedir=/opt/local/include/gcc
--libdir=/opt/local/lib/libgcc`

[Bug libstdc++/115420] Default constructor of unordered_map deleted

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
You need to do:
#include 


This is documented already at https://gcc.gnu.org/gcc-13/porting_to.html too.

[Bug c++/115412] ICE: canonical types differ for identical types ‘stdis_sametypename fooTtype, U’ and ‘stdis_sameT, U’

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115412

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-10
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
I haven't found a dup, so confirmed.

[Bug c++/83529] ICE in canonical types differ for identical types

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83529

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #10 from Marek Polacek  ---
Comment 7 now ICEs in a different spot.  This started with r13-4761:

commit 982629bea416df976686467f235e09cb1a5531cc
Author: Patrick Palka 
Date:   Sat Dec 17 11:24:44 2022 -0500

c++: constantness of non-dependent NTTP argument [PR107437]


$ xg++ -c 83529-2.C 
83529-2.C:5:26: error: call to non-‘constexpr’ function ‘int Foo(void*)’
5 | template  TPL Baz ();
  |  ^~~
83529-2.C:1:5: note: ‘int Foo(void*)’ declared here
1 | int Foo (void *);
  | ^~~
83529-2.C:5:26: error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive]
5 | template  TPL Baz ();
  |  ^~~
  |  |
  |  int
83529-2.C:1:10: note:   initializing argument 1 of ‘int Foo(void*)’
1 | int Foo (void *);
  |  ^~
83529-2.C:5:26: error: call to non-‘constexpr’ function ‘int Foo(void*)’
5 | template  TPL Baz ();
  |  ^~~
83529-2.C:1:5: note: ‘int Foo(void*)’ declared here
1 | int Foo (void *);
  | ^~~
83529-2.C:5:26: note: in template argument for type ‘int’
5 | template  TPL Baz ();
  |  ^~~
83529-2.C:9:26: error: call to non-‘constexpr’ function ‘int Foo(float)’
9 | template  TPL Baz ();
  |  ^~~
83529-2.C:7:5: note: ‘int Foo(float)’ declared here
7 | int Foo (float);
  | ^~~
83529-2.C:9:26: internal compiler error: unexpected expression ‘I’ of kind
template_parm_index
9 | template  TPL Baz ();
  |  ^~~
0xe42ac2 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8597
0xe446a1 cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8852
0xe458d7 maybe_constant_value(tree_node*, tree_node*, mce_value)
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:9161
0xe8ec41 cp_fully_fold
/home/mpolacek/src/gcc/gcc/cp/cp-gimplify.cc:2852
0xe8edb0 cp_fully_fold(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/cp-gimplify.cc:2871
0xe9e344 cp_convert_and_check(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/cvt.cc:668
0xdc6bff convert_like_internal
/home/mpolacek/src/gcc/gcc/cp/call.cc:9022
0xdc6ec8 convert_like
/home/mpolacek/src/gcc/gcc/cp/call.cc:9081
0xdc6f83 convert_like_with_context
/home/mpolacek/src/gcc/gcc/cp/call.cc:9105
0xdca2f0 operator()
/home/mpolacek/src/gcc/gcc/cp/call.cc:10232
0xdcc20b build_over_call
/home/mpolacek/src/gcc/gcc/cp/call.cc:10289
0xdb79d2 build_new_function_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc/gcc/cp/call.cc:5123
0x11a5c16 finish_call_expr(tree_node*, vec**,
bool, bool, int)
/home/mpolacek/src/gcc/gcc/cp/semantics.cc:3136
0x114a6ad tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21104
0x10fcd17 instantiate_non_dependent_expr_internal(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:6468
0x11008a5 convert_nontype_argument
/home/mpolacek/src/gcc/gcc/cp/pt.cc:7481
0x1105dfa convert_template_argument
/home/mpolacek/src/gcc/gcc/cp/pt.cc:8833
0x1107d9a coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:9324
0x110aad8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10155
0x11aa0f0 finish_template_type(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/semantics.cc:4015

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678

--- Comment #10 from John David Anglin  ---
On hppa-linux, we have:

dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
wait_for(0s): 363ns for 81820 calls, avg 48.8874ns per call
wait_until(system_clock minimum): 15999855ns for 81820 calls, avg 195.549ns per
call
wait_until(steady_clock minimum): 1817ns for 81820 calls, avg 244.437ns per
call
wait_until(system_clock epoch): 327345016058ns for 81820 calls, avg
4.00079e+06ns per call
wait_until(steady_clock epoch: 327417023513ns for 81820 calls, avg
4.00167e+06ns per call
wait_for when ready: 0ns for 81820 calls, avg 0ns per call
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/future/members/poll.cc:129:
int main(): Assertion 'wait_for_0 < (ready * 30)' failed.
Aborted (core dumped)

[Bug target/115418] Extra movapd emitted for MAX implementation

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115418

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14 regression] Extra   |Extra movapd emitted for
   |movapd emitted for MAX  |MAX implementation
   |implementation  |

--- Comment #2 from Andrew Pinski  ---
Note the issue is ix86_expand_sse_fp_minmax only handles LT/UNGE but it should
handle GT/UNLT with both parts swapped (comparison and true/false).

Note this was just by accident that GCC 14 does not work.

[Bug c++/115420] New: Default constructor of unordered_map deleted

[krebbel at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420

Bug ID: 115420
   Summary: Default constructor of unordered_map deleted
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

t.cc:

#include 
#include 

class Foo {
  std::unordered_map bar;
  Foo() : bar() {}
};

g++ -std=c++11 -c t.cc

fails with:

t.cc: In constructor ‘Foo::Foo()’:  
t.cc:6:11: error: use of deleted function ‘std::unordered_map<_Key, _Tp, _Hash,
_Pred, _Alloc>::unordered_map() [with _Key = std::__cxx11::basic_string;
_Tp = long unsigned int; _Hash = std::hash >;
_Pred = std::equal_to >; _Alloc =
std::allocator, long unsigned
int> >]’
6 |   Foo() : bar() {}
  |   ^
In file included from
/home2/andreas/bisect/gcc-02dab998665-install/include/c++/13.0.0/unordered_map:41,
 from t.cc:1:
/home2/andreas/bisect/gcc-02dab998665-install/include/c++/13.0.0/bits/unordered_map.h:146:7:
note: ‘std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::unordered_map()
[with _Key = std::__cxx11::basic_string; _Tp = long unsigned int; _Hash =
std::hash >; _Pred =
std::equal_to >; _Alloc =
std::allocator, long unsigned
int> >]’ is implicitly deleted because the default definition would be
ill-formed:
  146 |   unordered_map() = default;
  |   ^

starting with:

commit 227351345d0caa596eff8325144f15b15f704c08
Author: Jonathan Wakely 
Date:   Thu Jan 12 13:03:01 2023 +

libstdc++: Do not include  in concurrency headers

The , , and  headers use
std::errc constants, but don't use std::system_error itself. They only
use the __throw_system_error(int) function, which is defined in
.

By including the header for the errc constants instead of the whole of
 we avoid depending on the whole std::string definition.

libstdc++-v3/ChangeLog:

* include/bits/std_mutex.h: Remove  include.
* include/std/condition_variable: Add 
include.
* include/std/mutex: Likewise.
* include/std/shared_mutex: Likewise.

The testcase works fine with gcc 12 and clang. 

There are similar BZs on that topic but these do not seem to fit exactly, as I
understand it (e.g. 107022)

[Bug target/115419] [avr] IEEE double round-to-nearest should go to even

[gjl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115419

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P4

[Bug target/115419] New: [avr] IEEE double round-to-nearest should go to even

[gjl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115419

Bug ID: 115419
   Summary: [avr] IEEE double round-to-nearest should go to even
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

When the internal floating-point representation is rounded to IEEE double in
f7_get_double(), then tie breaks should round to an even LSB (Banker's
rounding).

[Bug c++/91590] ICE in : canonical types differ for identical types std::enable_if::ViewConcept< >()> and std::enable_if::ViewConcept< >()

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r5-5976-gb9fa057537445e:

commit b9fa057537445e7ecfb2bbbfcf7ecacdc4e3ad05
Author: Jason Merrill 
Date:   Sun Dec 21 00:00:43 2014 -0500

re PR c++/64359 (alias_template_specialization_p & template_args_equal show
up high in profile)

[Bug target/115418] [14 regression] Extra movapd emitted for MAX implementation

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115418

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Target||x86_64-linux-gnu
   Last reconfirmed||2024-06-10

--- Comment #1 from Andrew Pinski  ---
The difference between GCC 14 and 15 is:

GCC 14:
  _1 = a_4(D) < _5;
  _7 = _1 ? _5 : a_4(D);

GCC 15:
  _8 = _4 > a_5(D);
  _7 = _8 ? _4 : a_5(D);


GCC 15's IR gets recognized for UNSPEC_IEEE_MAX while GCC 14's is not.

If anything the target should recognize both cases ... Since both are
canonical.

[Bug target/115418] New: [14 regression] Extra movapd emitted for MAX implementation

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115418

Bug ID: 115418
   Summary: [14 regression] Extra movapd emitted for MAX
implementation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
#define MAX(a, b) ((a) < (b) ? (b) : (a))
#define MAX3(a, b, c) MAX((a), MAX((b), (c)))

double f(double a, double b, double c)
{
return MAX3(a,b,c);
}
```

```
$ gcc-14 /tmp/foo200.c -S -o - -O2
.file   "foo200.c"
.text
.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
movapd  %xmm2, %xmm3
maxsd   %xmm1, %xmm3
maxsd   %xmm0, %xmm3
movapd  %xmm3, %xmm0
ret
.cfi_endproc
.LFE0:
.size   f, .-f
.ident  "GCC: (Gentoo Hardened 14.1.1_p20240608 p2) 14.1.1 20240608"
.section.note.GNU-stack,"",@progbits
```

I only see the extra movapd with 14.

[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f

[syq at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

--- Comment #3 from YunQiang Su  ---
Since it doesn't exist, why use --includedir with it?
Anyway, so, maybe we should detect the existence of this dir.
Can you have a try of this patch?

--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -560,10 +560,11 @@ LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
 # Default native SYSTEM_HEADER_DIR, to be overridden by targets.
 NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@
 # Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
-ifeq (@includedir@,$(prefix)/include)
-  CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
-else
-  CROSS_SYSTEM_HEADER_DIR = @includedir@
+CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
+ifneq (@includedir@,$(prefix)/include)
+  ifneq (,$(wildcard @includedir@))
+CROSS_SYSTEM_HEADER_DIR = @includedir@
+  endif
 endif

[Bug c++/115412] ICE: canonical types differ for identical types ‘stdis_sametypename fooTtype, U’ and ‘stdis_sameT, U’

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115412

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This goes all the way back to r0-113135-g28704289327e42

commit 28704289327e4295928663b5bab7953718f71bc1
Author: Dodji Seketeli 
AuthorDate: Mon Nov 7 22:28:50 2011 +0100
Commit: Dodji Seketeli 
CommitDate: Mon Nov 7 22:28:50 2011 +0100

PR c++/45114 - Support C++11 alias-declaration

Most likely a dup.

[Bug c++/115417] Destructor is noexcept even though the class has a throwing destructor subobject in an anonymous union

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115417

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 115222.

*** This bug has been marked as a duplicate of bug 115222 ***

[Bug c++/115417] Destructor is noexcept even though the class has a throwing destructor subobject in an anonymous union

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115417

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|DUPLICATE   |---
 Status|RESOLVED|NEW
   Last reconfirmed||2024-06-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115222

--- Comment #3 from Andrew Pinski  ---
Actually let's reopen this for a second since of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222#c4 .

[Bug c++/115417] Destructor is noexcept even though the class has a throwing destructor subobject in an anonymous union

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115417

--- Comment #2 from Andrew Pinski  ---
Note it is not just anonymous unions, it is all unions.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

Andrew Pinski  changed:

   What|Removed |Added

 CC||janschultke at googlemail dot 
com

--- Comment #6 from Andrew Pinski  ---
*** Bug 115417 has been marked as a duplicate of this bug. ***

[Bug c++/115417] New: Destructor is noexcept even though the class has a throwing destructor subobject in an anonymous union

[janschultke at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115417

Bug ID: 115417
   Summary: Destructor is noexcept even though the class has a
throwing destructor subobject in an anonymous union
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

Consider the following code:

#include 

struct D {
~D() noexcept(false);
};

struct B {
union {
char c;
D d;
};

~B() {}
};

static_assert(std::is_nothrow_destructible_v);


This assertion passes only for GCC, but not for other compilers
(https://godbolt.org/z/e5jEKzjfs).

I believe GCC is wrong because 'd' is a potentially constructed subobject of B
(https://eel.is/c++draft/except.spec#8) and therefore, a destructor without a
noexcept-specifier should be potentially throwing.

This bug could be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109768, but I don't think it is a
duplicate.

[Bug middle-end/115411] ICE : in expand_call, at calls.cc:3668

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115411

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-10

[Bug middle-end/115411] ICE : in expand_call, at calls.cc:3668

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115411

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84964,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100536
 Target||x86_64

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f

[syq at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

--- Comment #2 from YunQiang Su  ---
Can you give me the configure command, so that I can have a test.

[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=905118,
   ||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=925204,
   ||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=926059
   Last reconfirmed||2024-06-10
 Ever confirmed|0   |1

[Bug bootstrap/115416] Setting --includedir to a nonexistent directory causes a build error

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org,
   ||syq at gcc dot gnu.org

--- Comment #1 from Sam James  ---
I think we've hit this too in Gentoo but I hadn't reported it yet as I hadn't
investigated, so I just worked around it.

[Bug testsuite/115415] New test case gcc.dg/torture/pr115388.c in r15-1163-g818e760528d436 hangs

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115415

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |15.0
   Keywords||testsuite-fail
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Andrew Pinski  ---
Fixed.

[Bug middle-end/115388] [15 Regression] wrong code at -O3 on x86_64-linux-gnu since r15-571-g1e0ae1f52741f7

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:c3d1153bc0a2b820e3c373ecf19a5a127703f854

commit r15-1165-gc3d1153bc0a2b820e3c373ecf19a5a127703f854
Author: Andrew Pinski 
Date:   Mon Jun 10 08:23:00 2024 -0700

Fix pr115388.c: plain char could be unsigned by default [PR115415]

This is a simple fix to the testcase as plain `char` could be
unsigned by default on some targets (e.g. aarch64 and powerpc).

Committed as obvious after quick test of the testcase on both aarch64 and
x86_64.

gcc/testsuite/ChangeLog:

PR testsuite/115415
PR tree-optimization/115388
* gcc.dg/torture/pr115388.c: Use `signed char` directly instead
of plain `char`.

Signed-off-by: Andrew Pinski 

[Bug testsuite/115415] New test case gcc.dg/torture/pr115388.c in r15-1163-g818e760528d436 hangs

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115415

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:c3d1153bc0a2b820e3c373ecf19a5a127703f854

commit r15-1165-gc3d1153bc0a2b820e3c373ecf19a5a127703f854
Author: Andrew Pinski 
Date:   Mon Jun 10 08:23:00 2024 -0700

Fix pr115388.c: plain char could be unsigned by default [PR115415]

This is a simple fix to the testcase as plain `char` could be
unsigned by default on some targets (e.g. aarch64 and powerpc).

Committed as obvious after quick test of the testcase on both aarch64 and
x86_64.

gcc/testsuite/ChangeLog:

PR testsuite/115415
PR tree-optimization/115388
* gcc.dg/torture/pr115388.c: Use `signed char` directly instead
of plain `char`.

Signed-off-by: Andrew Pinski 

[Bug bootstrap/115416] New: Setting --includedir to a nonexistent directory causes a build error

[marcuscalhounlopez at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416

Bug ID: 115416
   Summary: Setting --includedir to a nonexistent directory causes
a build error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcuscalhounlopez at gmail dot com
  Target Milestone: ---

A change made earlier this year[1] is causing troubles on the MacPorts build of
GCC.
MacPorts sets `--includedir=` to a directory that does not exist until after
the build is complete.
Since  `@includedir@` is not `$(prefix)/include` and `$(prefix)/include` does
not exist during the build, the Makefile exits[2].

[1] https://gcc.gnu.org/g:59e4c98173a79fcaa2c33253261409f38856c384
[2]
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/Makefile.in;h=6001c9e3b559a90291b4d571c2410db6da4ede94;hb=59e4c98173a79fcaa2c33253261409f38856c384#l3273

[Bug c++/107575] [12/13/14/15 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in duplicate_decls, at cp/decl.cc:2605 since r12-8115-g791a968630b3846

[simartin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107575

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|14.2|15.0

[Bug c++/109958] [11/12/13/14/15 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration

[simartin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|14.2|15.0

[Bug c++/103338] [11/12/13/14/15 Regression] ICE: in tsubst_pack_expansion with invalid template friend and packed expression

[simartin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103338

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|14.2|15.0

[Bug c++/111106] [11/12/13/14/15 Regression] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901

[simartin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|14.2|15.0

[Bug c++/105229] [11/12/13/14/15 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111

[simartin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105229

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|11.5|15.0

[Bug c++/105760] [11/12/13/14/15 Regression] ICE: in build_function_type, at tree.cc:7365

[simartin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|14.2|15.0

[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1

[pageexec at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070

PaX Team  changed:

   What|Removed |Added

 CC||pageexec at gmail dot com

--- Comment #8 from PaX Team  ---
can you please backport this to gcc 12 as well given that the original commit
causing the breakage was also backported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039#c6?

[Bug testsuite/115415] New test case gcc.dg/torture/pr115388.c in r15-1163-g818e760528d436 hangs

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115415

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |testsuite
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-06-10

--- Comment #1 from Andrew Pinski  ---
Mine. It is a testcase issue. A simple s/char/signed char/ should fix it.

[Bug middle-end/115388] [15 Regression] wrong code at -O3 on x86_64-linux-gnu since r15-571-g1e0ae1f52741f7

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388

--- Comment #8 from Andrew Pinski  ---
(In reply to Wilco from comment #7)
> (In reply to Richard Biener from comment #6)
> > Fixed.  Unfortunately this didn't fix PR115256 if I checked correctly.  Keep
> > searching!
> 
> The testcase hangs on AArch64, so this commit didn't fix it...

I suspect the issue is char being unsigned on a few targets. I will fix it in a
few hours.

[Bug middle-end/115388] [15 Regression] wrong code at -O3 on x86_64-linux-gnu since r15-571-g1e0ae1f52741f7

[wilco at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #7 from Wilco  ---
(In reply to Richard Biener from comment #6)
> Fixed.  Unfortunately this didn't fix PR115256 if I checked correctly.  Keep
> searching!

The testcase hangs on AArch64, so this commit didn't fix it...

[Bug other/115415] New: New test case gcc.dg/torture/pr115388.c in r15-1163-g818e760528d436 hangs

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115415

Bug ID: 115415
   Summary: New test case gcc.dg/torture/pr115388.c in
r15-1163-g818e760528d436 hangs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:818e760528d436ea8f6c28ef620e2bb82d456ea1, r15-1163-g818e760528d436 

It times out eventually but this hangs on all our powerpc64 systems.  I let it
run on one with no timeout and it was still going after 90 minutes.


commit 818e760528d436ea8f6c28ef620e2bb82d456ea1 (HEAD, origin/master,
origin/HEAD)
Author: Richard Biener 
Date:   Mon Jun 10 11:29:43 2024 +0200

tree-optimization/115388 - wrong DSE in irreductible regions

* gcc.dg/torture/pr115388.c: New testcase.

[Bug c++/115378] [14/15 Regression] ICE with lambda function as a default template argument with variadic templates in some cases

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115378

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 14.2

[Bug c++/115378] [14/15 Regression] ICE with lambda function as a default template argument with variadic templates in some cases

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115378

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:ff8105b4910f7dbee326cb36b01c16ac9bf10c4b

commit r14-10301-gff8105b4910f7dbee326cb36b01c16ac9bf10c4b
Author: Patrick Palka 
Date:   Fri Jun 7 12:12:30 2024 -0400

c++: lambda in pack expansion [PR115378]

Here find_parameter_packs_r is incorrectly treating the 'auto' return
type of a lambda as a parameter pack due to Concepts-TS specific logic
added in r6-4517, leading to confusion later when expanding the pattern.

Since we intend on removing Concepts TS support soon anyway, this patch
fixes this by restricting the problematic logic with flag_concepts_ts.
Doing so revealed that add_capture was relying on this logic to set
TEMPLATE_TYPE_PARAMETER_PACK for the 'auto' type of an pack expansion
init-capture, which we now need to do explicitly.

PR c++/115378

gcc/cp/ChangeLog:

* lambda.cc (lambda_capture_field_type): Set
TEMPLATE_TYPE_PARAMETER_PACK on the auto type of an init-capture
pack expansion.
* pt.cc (find_parameter_packs_r) :
Restrict TEMPLATE_TYPE_PARAMETER_PACK promotion with
flag_concepts_ts.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto-103497.C: Adjust expected diagnostic.
* g++.dg/template/pr95672.C: Likewise.
* g++.dg/cpp2a/lambda-targ5.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 5c761395402a730535983a5e49ef1775561ebc61)

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406

Sam James  changed:

   What|Removed |Added

Summary|[15 Regression] wrong code  |[15 Regression] wrong code
   |with vector compare at -O0  |with vector compare at -O0
   |with -mavx512f  |with -mavx512f since
   ||r15-920-gb6c6d5abf0d31c
   Last reconfirmed||2024-06-10
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||liuhongt at gcc dot gnu.org

--- Comment #1 from Sam James  ---
r15-920-gb6c6d5abf0d31c

Re: gcc dynamic_bitset bug

[Jonathan Wakely via Gcc-bugs]

Hi,

This mailing list is for automated mails from our bug database, not
for reporting bugs. Please see https://gcc.gnu.org/bugs/ for how to
report bugs, although it looks like this was already reported as Bug
115399.

Thanks for finding the bug though.

[Bug libstdc++/115399] std::tr2::dynamic_bitset shift behaves differently from std::bitset

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115399

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED