[Bug libstdc++/83662] std::aligned_alloc() not available

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

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

--- Comment #12 from Jonathan Wakely  ---
See Bug 69680

[Bug libstdc++/83662] std::aligned_alloc() not available

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

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

--- Comment #13 from Jonathan Wakely  ---
Snow Leopard is *ancient*, it didn't support aligned_alloc. According to Bug
92143 you need macOS 10.15 i.e. Catalina.

[Bug c/111058] New: __builtin_nans (and its friends) compiles to an external call to __builtin_nans for unsupported tag

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

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

Bug ID: 111058
   Summary: __builtin_nans (and its friends) compiles to an
external call to __builtin_nans for unsupported tag
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

double test(void)
{
return __builtin_nans("xxx");
}

compiles to:

test:
.LFB0:
.cfi_startproc
leaq.LC0(%rip), %rdi
jmp __builtin_nans@PLT
.cfi_endproc

We should refer to "nans" instead of "__builtin_nans" in the generated code. 
Though nans does not exist in libm for now, it may be added into a future libm
version or the user can provide their own nans implementation.

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-08-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fnan
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n965.htm

.

[Bug libstdc++/83662] std::aligned_alloc() not available

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

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

--- Comment #14 from Jonathan Wakely  ---
This bug report is only about declaring it in namespace std if it's already
available in the global namespace in stdlib.h

If your OS doesn't provide it in stdlib.h then that's not a gcc bug, and
libstdc++ can't add 'using ::aligned_alloc;' to cstdlib.

[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
We somehow compute res_nelts to 12, coming via

  /* (1) If SEL is a suitable mask as determined by
 valid_mask_for_fold_vec_perm_cst_p, then:
 res_npatterns = max of npatterns between ARG0, ARG1, and SEL
 res_nelts_per_pattern = max of nelts_per_pattern between
 ARG0, ARG1 and SEL.
 (2) If SEL is not a suitable mask, and TYPE is VLS then:
 res_npatterns = nelts in result vector.
 res_nelts_per_pattern = 1.
 This exception is made so that VLS ARG0, ARG1 and SEL work as before.  */
  if (valid_mask_for_fold_vec_perm_cst_p (arg0, arg1, sel, reason))
{

I suppose doing

  else if (TYPE_VECTOR_SUBPARTS (type).is_constant (&res_nelts))

first would fix this, but then the above looks wrong?

I'm going to test & push the "obvious" to fix x86_64, but I suppose you should
double-check your logic that goes wrong for non-VLA vectors.

[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Haochen Jiang :

https://gcc.gnu.org/g:68f7cb6cf9e8b9f2254855507f3b479552adda5f

commit r14-3318-g68f7cb6cf9e8b9f2254855507f3b479552adda5f
Author: Haochen Jiang 
Date:   Fri Aug 18 11:05:16 2023 +0800

i386: Add AVX2 pragma wrapper for AVX512DQVL intrins

PR target/111051

gcc/ChangeLog:

* config/i386/avx512vldqintrin.h: Push AVX2 when AVX2 is
disabled.

gcc/testsuite/ChangeLog:

PR target/111051
* gcc.target/i386/pr111051-1.c: New test.

[Bug c/111059] New: ICE: in gimplify_expr, at gimplify.cc:17253

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

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

Bug ID: 111059
   Summary: ICE: in gimplify_expr, at gimplify.cc:17253
   Product: gcc
   Version: 14.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: ---

Created attachment 55752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55752&action=edit
The program.c mentioned in description.

***
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 version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/new_gcc/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/new_gcc/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/new_gcc
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230719 (experimental) (GCC)

git version:85da0b40538fb0d17d89de1e7905984668e3dfef
***
Program:
The program was attached as program.c
***
Command Lines:
$ gcc program.c -o program
program.c: In function ‘test’:
program.c:188:176: warning: left shift count is negative
[-Wshift-count-negative]
  188 | arr_33 [i_0] [i_1] [i_2] = ((/*
implicit */_Bool) /* implicit */_Bool) (short)1139)) ? ~(((/* implicit
*/int) (unsigned short)9080 << (((/* implicit */int) (signed char)-23 :
(-1376368525)));
  |
   
   ^~
program.c:188:176: internal compiler error: in gimplify_expr, at
gimplify.cc:17253
0x7773da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:17253
0xc84dba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:17223
0xc97dc7 gimplify_modify_expr
../../gcc/gcc/gimplify.cc:6173
0xc84fa6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16441
0xc87a16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7246
0xc86380 gimplify_statement_list
../../gcc/gcc/gimplify.cc:2019
0xc86380 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16886
0xc87a16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7246
0xc96ad9 gimplify_cond_expr
../../gcc/gcc/gimplify.cc:4562
0xc8575c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16398
0xc87a16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7246
0xc86380 gimplify_statement_list
../../gcc/gcc/gimplify.cc:2019
0xc86380 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16886
0xc87a16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7246
0xc86380 gimplify_statement_list
../../gcc/gcc/gimplify.cc:2019
0xc86380 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16886
0xc87a16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7246
0xc88146 gimplify_bind_expr
../../gcc/gcc/gimplify.cc:1430
0xc8525e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16642
0xc87a16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7246
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.

[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__

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

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

--- Comment #5 from Sergei Trofimovich  ---
The change fixed highway-1.0.6 build for me. Thank you!

[Bug c/111059] ICE: in gimplify_expr, at gimplify.cc:17253

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

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

--- Comment #1 from Andrew Pinski  ---
(gdb) p debug_tree(*expr_p)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x776215e8 precision:32 min  max

pointer_to_this >
readonly
arg:1 
readonly constant
arg:0 
arg:1 
t.c:183:176 start: t.c:183:176 finish: t.c:183:177>
t.c:183:176 start: t.c:183:176 finish: t.c:183:177>

[Bug c/111059] [11/12/13/14 Regression] ICE: in gimplify_expr, at gimplify.cc:17253

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-08-18
  Known to work||10.5.0
Summary|ICE: in gimplify_expr, at   |[11/12/13/14 Regression]
   |gimplify.cc:17253   |ICE: in gimplify_expr, at
   ||gimplify.cc:17253
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Target Milestone|--- |11.5

--- Comment #2 from Andrew Pinski  ---
Confirmed. Reduced testcase:
```
void f() {
  (_Bool) (1 << -1);
}
```

[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reduced code is

i_1;
*func_14_ptr_4;
short func_14_s_8;
func_14() {
  int i_2;
  int *ptr_6 = &i_1;
  *ptr_6 = 8;
  for (; *ptr_6 <= 9; *ptr_6 += 1)
i_2 = *ptr_6;
  func_14_s_8 = 1;
  for (; func_14_s_8 <= 9;) {
func_14_s_8 += i_2;
*func_14_ptr_4 %= i_1;
  }
}

[Bug c/111059] [11/12/13/14 Regression] ICE: in gimplify_expr, at gimplify.cc:17253

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96929

--- Comment #3 from Andrew Pinski  ---
I have a feeling this was caused by r11-5271-g4866b2f5db117f9e89f8 and the
similar handling of negative shifts need to be added to the C front-end as the
C++ front-end too.

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

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

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

--- Comment #2 from Andrew Pinski  ---
Newer version of that paper:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1011.htm

[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-3319-gf5f47cc1ce75b00427756939a2dab94d3d125f6a
Author: Richard Biener 
Date:   Fri Aug 18 09:41:56 2023 +0200

tree-optimization/111048 - avoid flawed logic in fold_vec_perm

The following avoids running into somehow flawed logic in fold_vec_perm
for non-VLA vectors.

PR tree-optimization/111048
* fold-const.cc (fold_vec_perm_cst): Check for non-VLA
vectors first.

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

[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above

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

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

--- Comment #5 from Richard Biener  ---
Worked around on x86_64-linux, I think the code that's now not reached is still
buggy somehow - deferring to Pratamesh for this.

[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
I have a bisection running. Current range is g:23ad5ed7432bea7c ..
g:85a4e4f93ff251f2,
some 8 commits.

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

[chenxiaolong at loongson dot cn via Gcc-bugs]

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

chenxiaolong  changed:

   What|Removed |Added

 CC||chenxiaolong at loongson dot cn

--- Comment #3 from chenxiaolong  ---
//test.c
#include

int main(void)
{
_Float128 ret=__builtin_nansf128("NAN");
printf("ret=%Lf\n",ret);

return 0;   
}   
Compile command: gcc test.c -s -o -
result:

x86_64:
...
movl$.LC0, %edi
call__builtin_nansf128
... 
LoongArch:

   la.local $r4,.LC0
bl  %plt(__builtin_nansf128)

[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
$ git bisect bad ef28aadad6e5cff3
ef28aadad6e5cff3d7494f3c97d435a6579a2e2d is the first bad commit
commit ef28aadad6e5cff3d7494f3c97d435a6579a2e2d
Author: Jan Hubicka 
Date:   Thu Jul 20 15:41:39 2023 +0200

loop-ch improvements, part 3

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

[chenxiaolong at loongson dot cn via Gcc-bugs]

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

--- Comment #4 from chenxiaolong  ---
(In reply to chenxiaolong from comment #3)
> //test.c
> #include
> 
> int main(void)
> {
>   _Float128 ret=__builtin_nansf128("NAN");
>   printf("ret=%Lf\n",ret);
>   
>   return 0;   
> } 
> Compile command: gcc test.c -s -o -
> result:
> 
> x86_64:
> ...
>   movl$.LC0, %edi
>   call__builtin_nansf128
> ... 
> LoongArch:
>  
>la.local   $r4,.LC0
>   bl  %plt(__builtin_nansf128)

Compile command: gcc test.c -S -o -

[Bug ipa/78790] Disable IPA-VRP for noclone functions.

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from Martin Jambor  ---
(In reply to Andrew Pinski from comment #2)
> noipa was added in GCC 8, which fixes the testsuite writing issue so maybe
> this can be closed as won't fix ...

Indeed, noipa is the thing to use in such cases (and there is also -fno-ipa-vrp
for fine-grained control).

[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above

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

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

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
Sorry for the breakage, I will take a look.

Thanks,
Prathamesh

[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above

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

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
= ((q1 & 0) == 0) ? VECTOR_CST_NPATTERNS (arg0)
  : VECTOR_CST_NPATTERNS (arg1);

should be q1 & 1 :)

[Bug target/111060] New: [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

Bug ID: 111060
   Summary: [14 Regression] i686-linux bootstrap failure:
i686-unknown-linux-gnu/libstdc++-v3/include/limits:198
6:1: error: SSE register return with SSE2 disabled
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed bootstrap failure on r14-3320-g7f8d730a563983 today:

$ ~/dev/git/gcc/configure --build=i686-unknown-linux-gnu
--host=i686-unknown-linux-gnu --target=i686-unknown-linux-gnu && make
...
/tmp/gb/./gcc/xgcc -shared-libgcc -B/tmp/gb/./gcc -nostdinc++
-L/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/i686-unknown-linux-gnu/bin/
-B/usr/local/i686-unknown-linux-gnu/lib/ -isystem
/usr/local/i686-unknown-linux-gnu/include -isystem
/usr/local/i686-unknown-linux-gnu/sys-include   -fno-checking -x c++-header
-nostdinc++ -g -O2 -D_GNU_SOURCE 
-I/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include/i686-unknown-linux-gnu
-I/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/home/slyfox/dev/git/gcc/libstdc++-v3/include/precompiled/stdc++.h \
-o i686-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/slyfox/dev/git/gcc/libstdc++-v3/include/precompiled/stdc++.h:55:
/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include/limits: In static member
function 'static constexpr _Float16 std::numeric_limits<_Float16>::min()':
/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE
register return with SSE2 disabled

[Bug target/111023] missing extendv4siv4hi (and friends)

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-08-18
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
The idea of implementing some sign/zero extensions using PUNPCKL?? is quite
interesting. We can implement extensions for all <= 64byte vector modes that
extend to wider vector mode also for SSE2.

I have a patch.

[Bug target/111023] missing extendv4siv4hi (and friends)

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
Created attachment 55753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55753&action=edit
Proposed patch

Patch that implements zero/sign extend of <= 64byte vector modes to a wider
vector mode also for SSE2.

[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:8353b9c5f5af0e65cb04fcbb7325d6a566006cd4

commit r14-3322-g8353b9c5f5af0e65cb04fcbb7325d6a566006cd4
Author: Kewen Lin 
Date:   Fri Aug 18 05:03:40 2023 -0500

Makefile.in: Make TM_P_H depend on $(TREE_H) [PR111021]

As PR111021 shows, the below ${port}-protos.h include tree.h
for code_helper and tree_code:

  arm/arm-protos.h:#include "tree.h"
  cris/cris-protos.h:#include "tree.h" (H-P removed this in r14-3218)
  microblaze/microblaze-protos.h:#include "tree.h"
  rl78/rl78-protos.h:#include "tree.h"
  stormy16/stormy16-protos.h:#include "tree.h"

, when compiling build/gencondmd.cc, the include hierarchy
makes it depend on tm_p.h -> ${port}-protos.h -> tree.h,
which further includes (depends on) some files that are
generated during the building, such as: all-tree.def,
tree-check.h and so on.  The previous commit r14-3215
should already force build/gencondmd.cc to depend on
${TREE_H}, so the reported build failure should be gone.

But for a long term maintenance, especially one day some
build/xxx.cc requires tm_p.h but not recog.h, the ${TREE_H}
dependence could be missed and a build failure will show
up.  So this patch is to make TM_P_H depend on $(TREE_H),
any new build/xxx.cc depending on tm_p.h will be able to
consider ${TREE_H}.

It's tested with cross-builds for the affected ports with
steps:
 1) dropped the fix r14-3215;
 2) reproduced the build failure with serial build;
 3) applied this patch, serial built and verified all passed;
 4) added back r14-3215, serial built and verified all passed;

PR bootstrap/111021

gcc/ChangeLog:

* Makefile.in (TM_P_H): Add $(TREE_H) as dependence.

[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others since r14-3092

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

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

Kewen Lin  changed:

   What|Removed |Added

Summary|[14 Regression] Serial  |[14 Regression] Serial
   |build broken for CRIS, ARM, |build broken for CRIS, ARM,
   |and others  |and others since r14-3092
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #19 from Kewen Lin  ---
Should be fixed on trunk, thanks to all for the comments and helps!

[Bug target/111061] New: ICE: in emit_move_insn, at expr.cc:4219 with -O -mavx10.1-512 and __builtin_convertvector()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111061
   Summary: ICE: in emit_move_insn, at expr.cc:4219 with -O
-mavx10.1-512 and __builtin_convertvector()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 55754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55754&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx10.1-512 testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:7:10: internal compiler error: in emit_move_insn, at expr.cc:4219
7 |   return __builtin_convertvector(u, V);
  |  ^
0x747479 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4219
0xf2ae99 expand_value_return
/repo/gcc-trunk/gcc/cfgexpand.cc:3739
0xf3606c expand_return
/repo/gcc-trunk/gcc/cfgexpand.cc:3811
0xf3606c expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3918
0xf3606c expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4044
0xf3b066 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6096
0xf3cd67 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6831
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3320-20230818093638-g7f8d730a563-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-3320-20230818093638-g7f8d730a563-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230818 (experimental) (GCC)

[Bug target/111062] New: ICE: in final_scan_insn_1, at final.cc:2808 could not split insn {*andndi_1} with -O -mavx10.1-256 -mavx512bw -mno-avx512f

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111062
   Summary: ICE: in final_scan_insn_1, at final.cc:2808 could not
split insn {*andndi_1} with -O -mavx10.1-256
-mavx512bw -mno-avx512f
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 55755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55755&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx10.1-256 -mavx512bw -mno-avx512f testcase.c
cc1: warning:
'-mno-avx512{f,vl,bw,dq,cd,bf16,fp16,vbmi,vbmi2,vnni,ifma,bitalg,vpopcntdq}'
are ignored with '-mavx10.1' and above
testcase.c: In function 'foo':
testcase.c:7:1: warning: AVX512F vector return without AVX512F enabled changes
the ABI [-Wpsabi]
7 | {
  | ^
testcase.c:10:1: error: could not split insn
   10 | }
  | ^
(insn 24 111 25 2 (parallel [
(set (reg:DI 69 k1 [156])
(and:DI (not:DI (reg:DI 70 k2 [226]))
(reg:DI 68 k0 [157])))
(clobber (reg:CC 17 flags))
]) "testcase.c":9:12 624 {*andndi_1}
 (expr_list:REG_DEAD (reg:DI 70 k2 [226])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
during RTL pass: final
testcase.c:10:1: internal compiler error: in final_scan_insn_1, at
final.cc:2808
0x7e6460 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x74d1ee final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2808
0x108b06b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2887
0x108b2a4 final_1
/repo/gcc-trunk/gcc/final.cc:1979
0x108bef8 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4240
0x108bef8 execute
/repo/gcc-trunk/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


-mno-avx512f needs to be passed, even though the compiler indicates it's
ignored


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3320-20230818093638-g7f8d730a563-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-3320-20230818093638-g7f8d730a563-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230818 (experimental) (GCC)

[Bug sanitizer/111063] New: [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

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

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

Bug ID: 111063
   Summary: [UBSAN] Implement "-inf is outside the range of
representable values of type 'unsigned long'" to be on
par with Clang
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Jonathan Wakely wrote in bug 110860 comment 10:

GCC's ubsan doesn't seem to diagnose this rule:

"A prvalue of a floating-point type can be converted to a prvalue of an integer
type. The conversion truncates; that is, the fractional part is discarded. The
behavior is undefined if the truncated value cannot be represented in the
destination type."

There's no ubsan diagnostic for:

unsigned long i = -HUGE_VAL;

So it doesn't complain about adding log10(0) to a size_t.



That diagnostic exists in Clang as reported by
Paul Dreik in bug 110860 comment 8:


When 0 is passed, log10 returns -inf, which can not be converted to an integer.

I had a bit of problem to reproduce this with gcc, but it worked with clang.
The following program:

#include 
#include 
#include 

int main(int argc, char* argv[]) {
[[maybe_unused]] auto x = std::format("{:.292f}", 0.f);
}

causes the following output when compiled with clang-16 using
-fsanitize=undefined -fno-sanitize-recover=all -g -O0:

/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/format:1496:15:
runtime error: -inf is outside the range of representable values of type
'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/format:1496:15
in 

Link to reproducer (expected to go stale quick, had to use clang trunk to get a
sufficiently new libstdc++): https://godbolt.org/z/8aGf7YGWs

[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #5 from Rainer Orth  ---
Bisection completed, culprit patch identified.

[Bug target/111023] missing extendv4siv4hi (and friends)

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

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

--- Comment #5 from Richard Biener  ---
So for gcc.dg/vect/pr65947-7.c the main difference is that aarch64 succeeds
with

t.c:12:21: note:  * Re-trying analysis with vector mode V4HI
t.c:12:21: note:   === vect_analyze_data_refs ===
t.c:12:21: note:   got vectype for stmt: aval_13 = *_3;
vector(4) short int
t.c:12:21: note:   got vectype for stmt: _7 = *_6;
vector(4) int

while x86_64 fails with both the default (V8HI) and V8QI

t.c:12:21: note:   === vect_analyze_data_refs ===
t.c:12:21: note:   got vectype for stmt: aval_13 = *_3;
vector(8) short int
t.c:12:21: note:   got vectype for stmt: _7 = *_6;
vector(4) int
...
t.c:12:21: note:  * Re-trying analysis with vector mode V8QI
t.c:12:21: note:   === vect_analyze_data_refs ===
t.c:12:21: note:   got vectype for stmt: aval_13 = *_3;
vector(4) short int
t.c:12:21: note:   got vectype for stmt: _7 = *_6;
vector(2) int

that is, aarch64 is special here in that it somehow tries V4HI which ends
up behaving differently than V8QI.  aarch64 also tries V2SI for the
epilogue which yields

t.c:12:21: note:   === vect_analyze_data_refs ===
t.c:12:21: note:   got vectype for stmt: aval_13 = *_3;
vector(4) short int 
t.c:12:21: note:   got vectype for stmt: _7 = *_6;
vector(2) int

aarch64 also fails for V8HI (same default).

The order for aarch64 is V8HI, V4HI ..., x86_64 tries V8HI, V8QI, V4QI.

That V4HI yields V4SI as related mode is a "fluke"(?) of
aarch64_vectorize_related_mode which has

  /* Prefer to use 1 128-bit vector instead of 2 64-bit vectors.  */
  if (TARGET_SIMD
  && (vec_flags & VEC_ADVSIMD)
  && known_eq (nunits, 0U)
  && known_eq (GET_MODE_BITSIZE (vector_mode), 64U)
  && maybe_ge (GET_MODE_BITSIZE (element_mode)
   * GET_MODE_NUNITS (vector_mode), 128U))
{
  machine_mode res = aarch64_simd_container_mode (element_mode, 128);
  if (VECTOR_MODE_P (res))
return res;
}

which essentially "violates" the one-vector-size design of the loop
vectorizer in these kind of special cases.

So indeed x86 isn't going to vectorize this because of the inherent
limitation of the vectorizer which chooses vector types too early.

[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-18

--- Comment #1 from Jonathan Wakely  ---
Ah, looks like the 16-bit types still need to be enabled conditionally.

[Bug target/111064] New: 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)

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

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

Bug ID: 111064
   Summary: 5-10% regression of parest on icelake between
g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15
2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a
(Aug 16)
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

-Ofast -march=native
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=801.457.0
-Ofast -march=native -flto + PGO
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.457.0

It does not seem to show on zen or altra

[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Keywords||ice-on-valid-code,
   ||missed-optimization, ra

--- Comment #6 from Richard Biener  ---
The culprit hardly is responsible - it's the RA failing, this can be fixed for
example by using -fschedule-insns -fsched-pressure.

I think this define-insn-and-split is a bit heavy-weight for i386 and a split
after reload given we allow arbitrary memory operands (in this case the
addressing modes are simple though)

(insn 109 283 243 9 (set (reg:DI 295)
(ior:DI (ashift:DI (zero_extend:DI (mem:SI (plus:SI (mult:SI (reg:SI
329 [orig:229 _118 ] [229])
(const_int 4 [0x4]))
(reg/f:SI 328 [orig:83 a.0_1 ] [83])) [3
MEM[(unsigned int *)_11]+0 S4 A32]))
(const_int 32 [0x20]))
(zero_extend:DI (mem:SI (plus:SI (mult:SI (reg:SI 294 [233])
(const_int 4 [0x4]))
(reg/f:SI 328 [orig:83 a.0_1 ] [83])) [3 MEM[(unsigned
int *)_15]+0 S4 A32] "t.c":15:7 680 {*concatsidi3_3}
 (expr_list:REG_DEAD (reg/f:SI 328 [orig:83 a.0_1 ] [83])
(expr_list:REG_DEAD (reg:SI 329 [orig:229 _118 ] [229])
(expr_list:REG_DEAD (reg:SI 294 [233])
(nil)

this requires 5 GPRs (and it's not even the most complicated form of
addressing).  I'm not sure if LRA is supposed to fix this up, spilling
the two MEMs will still result in 5 registers needed, and with
32bits that's somewhat difficult to have?

So IMHO this is a bug in the machine description.

The LRA dump isn't really enlightening, it seems to succeed for the above
insn:

0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
Cycle danger: overall += LRA_MAX_REJECT
  alt=0,overall=608,losers=1,rld_nregs=1
0 Non pseudo reload: reject++
1 Non pseudo reload: reject++
  alt=1,overall=2,losers=0,rld_nregs=0
 Choosing alt 1 in insn 239:  (0) m  (1) re {*movsi_internal}
  Creating newreg=292 from oldreg=97, assigning class GENERAL_REGS to
address r292
  Creating newreg=293 from oldreg=157, assigning class INDEX_REGS to
address r293
   Change to class INDEX_REGS for r292
  Creating newreg=294 from oldreg=233, assigning class INDEX_REGS to
address r294
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
3 Non-pseudo reload: reject+=2
3 Non input pseudo reload: reject++
  alt=0,overall=18,losers=2,rld_nregs=2
0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
3 Non-pseudo reload: reject+=2
3 Non input pseudo reload: reject++
  alt=1,overall=18,losers=2,rld_nregs=3
0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
  alt=2,overall=18,losers=2,rld_nregs=3
0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
0 Early clobber: reject++
  alt=3,overall=10,losers=1,rld_nregs=2
 Choosing alt 3 in insn 109:  (0) &r  (1) m  (3) m {*concatsidi3_3}
  Creating newreg=295, assigning class GENERAL_REGS to r295
  109:
r295:DI=zero_extend([r229:SI*0x4+r83:SI])<<0x20|zero_extend([r294:SI*0x4+r83:SI])
  REG_DEAD r233:SI
  REG_DEAD r229:SI
Inserting insn reload before:
  240: r292:SI=r97:SI
  241: r293:SI=r157:SI
  242: r294:SI=r233:SI
Inserting insn reload after:
  243: [r292:SI+r293:SI+0x8]=r295:DI

but then the ICE is very much later ...


** Splitting a hard reg after assignment #2: **

Hard reg 0 is preferable by r350 with profit 174



EMERGENCY DUMP:

[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f

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

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

--- Comment #7 from Richard Biener  ---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index f3a3305ac4f..d38b9d764d8 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -11511,7 +11511,7 @@
 })

 (define_insn_and_split "*concat3_3"
-  [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,&r")
+  [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,!&r")
(any_or_plus:
  (ashift:
(zero_extend:

fixes the issue for me, this disparages the &r,m,m alternative since
that makes any reloading difficult(?) and the early-clobber output
makes register pressure even harder to deal with.

[Bug target/111064] 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)

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

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

--- Comment #1 from Jan Hubicka  ---
Maybe
commit 3064d1f5c48cb6ce1b4133570dd08ecca8abb52d
Author: liuhongt 
Date:   Thu Aug 10 11:41:39 2023 +0800

Software mitigation: Disable gather generation in vectorization for GDS
affected Intel Processors.

For more details of GDS (Gather Data Sampling), refer to
   
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/gather-data-sampling.html

After microcode update, there's performance regression. To avoid that,
the patch disables gather generation in autovectorization but uses
gather scalar emulation instead.

[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

--- Comment #2 from Jonathan Wakely  ---
Created attachment 55756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55756&action=edit
Revert pre-C++23 support for 16-bit float types

I'll test this patch as soon as I can get an i686 system set up.

[Bug c++/111019] [12/13/14 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:745ec2135aabfbe2c0fb7780309837d17e8986d4

commit r14-3325-g745ec2135aabfbe2c0fb7780309837d17e8986d4
Author: Richard Biener 
Date:   Thu Aug 17 15:21:33 2023 +0200

tree-optimization/111019 - invariant motion and aliasing

The following fixes a bad choice in representing things to the alias
oracle by LIM which while correct in pieces is inconsistent with itself.
When canonicalizing a ref to a bare deref instead of leaving the base
object and the extracted offset the same and just substituting an
alternate ref the following replaces the base and the offset as well,
avoiding the confusion that otherwise will arise in
aliasing_matching_component_refs_p.

PR tree-optimization/111019
* tree-ssa-loop-im.cc (gather_mem_refs_stmt): When canonicalizing
also scrap base and offset in case the ref is indirect.

* g++.dg/torture/pr111019.C: New testcase.

[Bug c++/111019] [12/13 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13 Regression]
   |Optimizer incorrectly   |Optimizer incorrectly
   |assumes variable is not |assumes variable is not
   |changed while change|changed while change
   |happens through another |happens through another
   |pointer |pointer
  Known to work||14.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.  The change picks to the GCC 12 branch just fine, can you
maybe validate the change on the complete testcase?

[Bug target/111064] 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)

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

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

--- Comment #2 from Richard Biener  ---
might be - parest is the test that improved with emulated gather on Zen.

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
We should absolutely *not* generate calls to a non-existent function 
"nans" based on a long-obsolescent standard proposal.  The modern way to 
generate a signaling NaN with given payload, as specified in C23, is to 
generate a signaling NaN with one of the *_SNAN macros (FLT128_SNAN in 
this case) in , then use the relevant setpayload function 
(setpayloadf128 in this case) to set its payload.

I don't think there is any bug here at all.

[Bug target/111065] New: [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

Bug ID: 111065
   Summary: [RISCV] t-linux-multilib specifies incorrect multilib
reuse patterns
   Product: gcc
   Version: og13 (devel/omp/gcc-13)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tommy_murphy at hotmail dot com
  Target Milestone: ---

The file gcc/config/riscv/t-linux-multilib:

*
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/t-linux-multilib

specifies the RISC-V multilibs to be built when --enable-multilib is passed at
configuration time:

*
https://github.com/riscv-collab/riscv-gnu-toolchain#installation-newliblinux-multilib

It also specifies multilib reuse patterns. These control what (if any) multilib
is (re)used when an arch/abi is specified at compile time (using -march=...
-mabi=...) for which no specific multilib exists. For example:

* rv64imafdc-lp64d-rv64imafd-

This specifies that the multilib for rv64imafdc/lp64d be built at toolchain
build time, and that it also be (re)used for the arch/abi rv64imafd/lp64d when
-march=rv64imafd -mabi=lp64d is passed at compile time.

In this case this reuse mapping will lead to problems if the target platform
(hardware, simulator etc.) strictly supports rv64imafd/lp64d but
libraries/startup code for rv64imafdc/lp64d are linked. This is because the
latter will most likely use RISC-V compressed instructions (via the RISC-V
optional C/Compressed extension) which the rv64imafd/lp64d target will not
support and will trap on. 

Multilib reuse mappings should always be from an arch/abi "superset" to a
"subset" of extensions. For example:

* reusing rv64imafd/lp64d for a rv64imafdc/lp64d target is OK - it just doesn't
take advantage of the C (Compressed) extension
* reusing rv64imafdc/lp64d for a rv64imafd/lp64d target is not OK - the
libraries will most likely use C (Compressed) instructions which the latter
target does not support and will trap on.

According to this comment:

*
https://github.com/gcc-mirror/gcc/blob/35b5762a740d4506d7acac65d0f8375640362492/gcc/config/riscv/t-linux-multilib#L2C1-L3C1

This is the list of multilibs/reuse patterns specified:

* rv32imac-ilp32-rv32ima,rv32imaf,rv32imafd,rv32imafc,rv32imafdc-
* rv32imafdc-ilp32d-rv32imafd- 
* rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-
* rv64imafdc-lp64d-rv64imafd-

all of which seem problematic/erroneous because they specify the reuse of
libraries with compressed instructions for arch/abi's that do not support the C
(Compressed) extension.

However I am loath to submit a patch because I am not sure what the
correct/authoritative list of multilibs and reuse patterns *should be* and what
disturbance may be caused by changing this file.

Maybe one of the seasoned RISC-V GCC contributors might be able to comment?

Thanks.

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

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

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

--- Comment #6 from Xi Ruoyao  ---
(In reply to jos...@codesourcery.com from comment #5)
> We should absolutely *not* generate calls to a non-existent function 
> "nans" based on a long-obsolescent standard proposal.  The modern way to 
> generate a signaling NaN with given payload, as specified in C23, is to 
> generate a signaling NaN with one of the *_SNAN macros (FLT128_SNAN in 
> this case) in , then use the relevant setpayload function 
> (setpayloadf128 in this case) to set its payload.
> 
> I don't think there is any bug here at all.

But generating an external call to __builtin_* just does not make sense at all.

If the payload won't be supported, we should just emit a diagnostic and reject
the code.

[Bug tree-optimization/48783] ~0ULL % (a / (a & -a)) == 0 is not optimized to false on the tree level

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

 CC||jemarch at gcc dot gnu.org

--- Comment #9 from Jose E. Marchesi  ---
Note https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627864.html

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

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

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

--- Comment #2 from Jose E. Marchesi  ---
A patch to fix this was sent
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627864.html

[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above since r14-3243-ga7dba4a1c05a76

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

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

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #7)
> = ((q1 & 0) == 0) ? VECTOR_CST_NPATTERNS (arg0)
>   : VECTOR_CST_NPATTERNS (arg1);
> 
> should be q1 & 1 :)

Oops, sorry for the typo :/
And yes, that fixes the issue.

For more context we have following inputs to VEC_PERM_EXPR:
arg0 (1, 1): { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
arg1: (4, 1): { 255, 63, 15, 3, 255, 63, 15, 3, 255, 63, 15, 3, 255, 63, 15, 3
}
sel (2, 3):  { 0, 16, 1, 17, 2, 18, ... }
arg0 len: 16
sel nelts: 16

In valid_mask_for_fold_vec_perm_cst_p for the pattern: {16, 17, 18, ...}
arg_npatterns is erroneously set to VECTOR_CST_NPATTERNS (arg0) and we have:
step = 1, arg_npatterns = 1
Thus, step becomes a "multiple" of arg_npatterns and we (wrongly) return true
for this case.

So in the loop below in fold_vec_perm_cst, we have res with following encoding:
res (4, 3): { 0, 255, 0, 63, 0, 15, 0, 3, 0, 255, 0, 63, ... }

Since len = 16, it has to compute the remaining elements.
For index 13, it comes as "a3" in pattern: { 255, 15, 255, ... }
So the step gets computed as: 255 - 15 = 240
And IIUC the next element thus becomes: (255 + 240)%256 = 239.

By correctly setting arg_npatterns = VECTOR_CST_NPATTERNS (arg1) for this
case, arg_npatterns becomes 4.
Since step == 1 is not a multiple of arg_npatterns we return false,
and use the fallback:
res_npatterns = 16, res_nelts_per_pattern = 1.
and the loop below correctly encodes the elements.

I will shortly send a patch after validating it.

Thanks,
Prathamesh

[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

--- Comment #3 from Sergei Trofimovich  ---
The patch fixed gcc buid on i686-linux for me. Thank you!

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

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

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

Kito Cheng  changed:

   What|Removed |Added

Version|og13 (devel/omp/gcc-13) |14.0
 CC||kito at gcc dot gnu.org

--- Comment #1 from Kito Cheng  ---
One major issue around multilib for linux is we only encode abi to the path, so
it hard to extend that like baremetal toolchain.

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55725|0   |1
is obsolete||

--- Comment #4 from Jakub Jelinek  ---
Created attachment 55757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55757&action=edit
gcc14-pr110349-wip.patch

Thanks, made some progress with that.
I wonder if the paper isn't incomplete though.
My understanding of the intent is that say
void foo () { auto a = [_ = 1, _ = 2] () {}; }
is valid, similarly
struct S { int _ = 1; int _ = 2; };
(and it seems the clang implementation allows that),
but we still have
https://eel.is/c++draft/expr.prim.lambda.capture#2
"Ignoring appearances in initializers of init-captures, an identifier or this
shall not appear more than once in a lambda-capture."
and
https://eel.is/c++draft/class.mem#general-5
"A member shall not be declared twice in the member-specification, except that"
and nothing mentioning the name-independent exception in either case.
Another thing is we have that
https://eel.is/c++draft/basic.scope.block#2
spot which has been changed by the paper, so
void baz (int _) { int _ = 1; }
void qux () { if (int _ = 2) { int _ = 3; } }
etc. cases are valid which have been invalid before, but the important question
is if ++_; is allowed after 1; and/or 3;
https://eel.is/c++draft/basic.scope.scope#6
has the note:
"An id-expression that names a unique name-independent declaration is usable
until an additional declaration of the same name is introduced in the same
scope ([basic.lookup.general])."
but does that apply here?
https://eel.is/c++draft/basic.scope.block#2 seems to talk about the behavior
in the same scope, but aren't the scopes different here?
Seems clang rejects the baz case with ++_; added after 1; (and the WIP patch
does too), but doesn't reject ++_; added after 3; (while the WIP patch does).

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

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

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

--- Comment #5 from Jakub Jelinek  ---
Also, is the structured binding in
void corge ()
{
  static int a[2];
  static auto [_, _] = a;
}
inhabitating namespace scope (so it is correct to reject it?  clang does, the
WIP patch does as well).

[Bug ipa/110753] [14 Regression] ICE in meet_with_1, at ipa-cp.cc:1057

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:53fcd3bdbc9104a8acdc79134d8d272d7eead0fd

commit r14-3326-g53fcd3bdbc9104a8acdc79134d8d272d7eead0fd
Author: Aldy Hernandez 
Date:   Fri Aug 18 12:41:46 2023 +0200

[irange] Return FALSE if updated bitmask is unchanged [PR110753]

The mask/value pair we track in the irange is a bit fickle in that it
can sometimes contradict the bitmask inherent in the range.  This can
happen when a series of calculations yield a combination such as:

[3, 1000] MASK 0xfffe VALUE 0x0

The mask/value above implies that the lowest bit is a known 0, which
would exclude the 3 in the range.  At one time we tried keeping mask
and ranges 100% consistent, but the performance penalty was too high
(5% in VRP).  Also, it's unclear whether the intersection of two
incompatible known bits should make the whole range undefined, or
just the contradicting bits.  This is all documented in
irange::get_bitmask().  We could revisit both of these assumptions
in the future.

In this testcase IPA ends up with a range where the lower 2 bits are
expected to be 0, but the range is [1,1].

[irange] long int [1, 1] MASK 0xfffc VALUE 0x0

This causes irange::union_bitmask() to think an update occurred, when
no semantic change happened, thus triggering an assert in IPA-cp.  We
could get rid of the assert, but it's cleaner to make
irange::{union,intersect}_bitmask always tell the truth.  Beside, the
ranger's cache also depends on union being truthful.

PR ipa/110753

gcc/ChangeLog:

* value-range.cc (irange::union_bitmask): Return FALSE if updated
bitmask is semantically equivalent to the original mask.
(irange::intersect_bitmask): Same.
(irange::get_bitmask): Add comment.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr110753.c: New test.

[Bug ipa/110753] [14 Regression] ICE in meet_with_1, at ipa-cp.cc:1057

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Aldy Hernandez  ---
(In reply to Aldy Hernandez from comment #3)

> MASK 0xfffc VALUE 0x0 (low 2 bits are known to be 1, everything
> else is unknown).

FWIW, the above implies the low 2 bits are known to be 0, not 1.  Not that it
matters, as I just fixed this PR in trunk :).

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from Tommy Murphy  ---
Thanks @Kito Cheng - but I don't really understand how your comment relates to
the specific issue of the t-linux-multilib reuse "mappings" being incorrect
(and possibly the reverse of what was originally intended?)? Maybe you can
clarify? Thanks again.

[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones

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

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

Peter Bergner  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2020-October |il/gcc-patches/2023-July/62
   |/555760.html|3519.html
 Status|NEW |ASSIGNED

[Bug tree-optimization/111040] __builtin_object_size: inconsistent result for subobject with member arrays.

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
the discussion on this bug is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627631.html

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #3 from palmer at gcc dot gnu.org ---
(In reply to Tommy Murphy from comment #2)
> Thanks @Kito Cheng - but I don't really understand how your comment relates
> to the specific issue of the t-linux-multilib reuse "mappings" being
> incorrect (and possibly the reverse of what was originally intended?)? Maybe
> you can clarify? Thanks again.

The Linux and ELF multilibs are different: for Linux we assumed ISA
compatibility was up to the distro, so multilib just handles the ABI side of
things.  That said, C does bleed into the ABI so we should really fix that --
presumably we'd need some psABI work there, compatibility is going to be a bit
clunky so it's probably best to just add two explicit ABI variants.

[Bug tree-optimization/111040] __builtin_object_size: inconsistent result for subobject with member arrays.

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
a summary of the discussion:

We have two different sources to get the size information for subobjects:
   A. The TYPE information of the subobject in the IR;
   B. The initialization information propagated through data flow.

In the early pass, only A is available.
B might be available in the second pass.

If both A and B are available, we should choose the minimum one between
these two for both OST_MINIMUM and OST_MAXIMUM.

However, in the current early object size phase, we have the following:

enum tree_code code = object_size_type & OST_MINIMUM ? MAX_EXPR : MIN_EXPR;

I.e, we chose the MAX one between A and B for OST_MIN.

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

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

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

--- Comment #6 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #4)
> "A member shall not be declared twice in the member-specification, except
> that"
> and nothing mentioning the name-independent exception in either case.

Agreed, this seems like a missed edit, and we should accept those.

> Seems clang rejects the baz case with ++_; added after 1; (and the WIP patch
> does too), but doesn't reject ++_; added after 3; (while the WIP patch does).

I agree that these should be rejected and the wording needs improvement to
specify that.

(In reply to Jakub Jelinek from comment #5)
> Also, is the structured binding in
> void corge ()
> {
>   static int a[2];
>   static auto [_, _] = a;
> }
> inhabitating namespace scope (so it is correct to reject it?  clang does,
> the WIP patch does as well).

No, it inhabits block/function scope.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

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

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

--- Comment #4 from Kito Cheng  ---
I guess I skip too much detail here, the multilib for linux isn’t really honor
to the reause rule in the multilib config file for a while.

That just control how multilib build, e.g. build ilp32 with which arch, and we
will find matched ABI, but why we did that? The reason is simplify the reuse
rule, RISC-V has huge number of extension now, so enumeration the possible
combination are almost impossible.

But why it can’t use same scheme as baremetal? Okay, that’s because we encode
the abi in the path only, unlike baremetal we have encode both abi and arch, it
kinda of de facto ABI in linux/glibc, also it not make too much sense to having
too much different multilib within a (RISC-V) linux system.

[Bug target/111023] missing extendv4siv4hi (and friends)

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:4123b5609da53c8f8ac01c90aef127ad6375e9df

commit r14-3327-g4123b5609da53c8f8ac01c90aef127ad6375e9df
Author: Uros Bizjak 
Date:   Fri Aug 18 19:06:38 2023 +0200

i386: Use PUNPCKL?? to implement vector extend and zero_extend for
TARGET_SSE2.

Implement vector extend and zero_extend functionality for TARGET_SSE2 using
PUNPCKL?? family of instructions. The code for e.g. zero-extend from V2SI
to
V2DImode improves from:

movd%xmm0, %edx
pshufd  $85, %xmm0, %xmm0
movd%xmm0, %eax
movq%rdx, (%rdi)
movq%rax, 8(%rdi)

to:
pxor%xmm1, %xmm1
punpckldq   %xmm1, %xmm0
movaps  %xmm0, (%rdi)

And the code for sign-extend from V2SI to V2DImode from:

movd%xmm0, %edx
pshufd  $85, %xmm0, %xmm0
movd%xmm0, %eax
movslq  %edx, %rdx
cltq
movq%rdx, (%rdi)
movq%rax, 8(%rdi)

to:
pxor%xmm1, %xmm1
pcmpgtd %xmm0, %xmm1
punpckldq   %xmm1, %xmm0
movaps  %xmm0, (%rdi)

PR target/111023

gcc/ChangeLog:

* config/i386/i386-expand.cc (ix86_split_mmx_punpck):
Also handle V2QImode.
(ix86_expand_sse_extend): New function.
* config/i386/i386-protos.h (ix86_expand_sse_extend): New
prototype.
* config/i386/mmx.md (v4qiv4hi2): Enable for
TARGET_SSE2.  Expand through ix86_expand_sse_extend for
!TARGET_SSE4_1.
(v2hiv2si2): Ditto.
(v2qiv2hi2): Ditto.
* config/i386/sse.md (v8qiv8hi2): Ditto.
(v4hiv4si2): Ditto.
(v2siv2di2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr111023-2.c: New test.
* gcc.target/i386/pr111023-4b.c: New test.
* gcc.target/i386/pr111023-8b.c: New test.
* gcc.target/i386/pr111023.c: New test.

[Bug c++/111066] New: g++.dg/special/initpri3.C fails on darwin

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

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

Bug ID: 111066
   Summary: g++.dg/special/initpri3.C fails on darwin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

A warning there triggers the failure:

FAIL: g++.dg/special/initpri3.C  at line 10 (test for warnings, line 9)
FAIL: g++.dg/special/initpri3.C (test for excess errors)
Excess errors:
/tmp/gcc-darwin-arm64/gcc/testsuite/g++.dg/special/initpri3.C:9:55: warning:
'init_priority' attribute ignored [-Wattributes]

[Bug c++/111066] g++.dg/special/initpri3.C fails on darwin

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Target||x86_64-apple-darwin20
  Build||x86_64-apple-darwin20
 CC||ppalka at gcc dot gnu.org
   Host||x86_64-apple-darwin20
   Last reconfirmed||2023-08-18

--- Comment #1 from Francois-Xavier Coudert  ---
Seen in multiple test runs, like this one:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html

[Bug c++/111067] New: g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

Bug ID: 111067
   Summary: g++.dg/opt/icf{1,2,3}.C tests fail on darwin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

As seen for example on
https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html

FAIL: g++.dg/opt/icf1.C  -std=gnu++14 execution test
FAIL: g++.dg/opt/icf1.C  -std=gnu++17 execution test
FAIL: g++.dg/opt/icf1.C  -std=gnu++20 execution test
FAIL: g++.dg/opt/icf2.C  -std=gnu++14 execution test
FAIL: g++.dg/opt/icf2.C  -std=gnu++17 execution test
FAIL: g++.dg/opt/icf2.C  -std=gnu++20 execution test
FAIL: g++.dg/opt/icf3.C  -std=gnu++14 execution test
FAIL: g++.dg/opt/icf3.C  -std=gnu++17 execution test
FAIL: g++.dg/opt/icf3.C  -std=gnu++20 execution test

The tests fail on Darwin. I'm willing to help but do not know where to begin
debugging this.

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

  Known to fail||14.0
 Target||x86_64-apple-darwin20
 CC||jason at gcc dot gnu.org
   Host||x86_64-apple-darwin20
  Build||x86_64-apple-darwin20
   Last reconfirmed||2023-08-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/110070] Code quality regression with for (int i: {1,2,4,6})

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #4 from Francois-Xavier Coudert  ---
The tests introduced by the commit above all fail on Darwin, both on Intel and
ARM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067

[Bug testsuite/111066] g++.dg/special/initpri3.C fails on darwin

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

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

--- Comment #2 from Andrew Pinski  ---
The wording of the warning is different from what dg-warning directive in the
testcase expects.

diff --git a/gcc/testsuite/g++.dg/special/initpri3.C
b/gcc/testsuite/g++.dg/special/initpri3.C
index 3d745a42a6a..63ed3208228 100644
--- a/gcc/testsuite/g++.dg/special/initpri3.C
+++ b/gcc/testsuite/g++.dg/special/initpri3.C
@@ -7,4 +7,4 @@
 #endif

 struct A { A(); } a __attribute__((init_priority(500)));
-// { dg-warning "attribute directive ignored" "" { target { ! init_priority }
} .-1 }
+// { dg-warning "attribute ignored" "" { target { ! init_priority } } .-1 }


Is the correct fix I think. The directive in the warning only comes from
namespace and using uses.

[Bug testsuite/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |testsuite

--- Comment #1 from Andrew Pinski  ---
I suspect this needs:
/* { dg-add-options bind_pic_locally } */

[Bug target/111068] New: ICE: in extract_insn, at recog.cc:2791 unrecognizable insn with -ffloat-store -mavx10.1-512

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111068
   Summary: ICE: in extract_insn, at recog.cc:2791 unrecognizable
insn with -ffloat-store -mavx10.1-512
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 55758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55758&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -ffloat-store -mavx10.1-512 testcase.c 
testcase.c: In function 'foo':
testcase.c:8:1: error: unrecognizable insn:
8 | }
  | ^
(insn 19 18 20 2 (set (reg:V8HF 90)
(vec_concat:V8HF (mem:V4HF (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -32 [0xffe0])) [1  S8 A64])
(reg:V4HF 93))) "testcase.c":7:5 -1
 (nil))
during RTL pass: vregs
testcase.c:8:1: internal compiler error: in extract_insn, at recog.cc:2791
0x7e6460 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7e64dd _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x7d51cd extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2791
0x10d1c25 instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1610
0x10d1c25 instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1983
0x10d1c25 execute
/repo/gcc-trunk/gcc/function.cc:2030
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3320-20230818093638-g7f8d730a563-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-3320-20230818093638-g7f8d730a563-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230818 (experimental) (GCC)

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #7 from joseph at codesourcery dot com  ---
There shouldn't be such a thing as an unsupported constant payload; both 
__builtin_nan and __builtin_nans should rather be made consistent with 
parsing of payloads by glibc's nan functions (that may in some cases mean 
changing glibc; see https://sourceware.org/bugzilla/show_bug.cgi?id=28322 
- glibc's functions don't handle payloads wider than 64 bits for 
_Float128, but GCC's do).

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55757|0   |1
is obsolete||

--- Comment #7 from Jakub Jelinek  ---
Created attachment 55759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55759&action=edit
gcc14-pr110349-wip.patch

Some further progress, with lambda capture handling fixed so that it doesn't
emit the bogus errors and very basic start of non-static data member support.
In that area not really sure what to do, because presumably we want to fail
_ member lookups if it is ambiguous but there is tons of internal lookups
that will likely have to work somehow.  And there is the binary search on
member_vec vs. linear search on member_vec vs. field search, and anonymous
aggregates etc.

(In reply to Jason Merrill from comment #6)
> No, it inhabits block/function scope.

Ok, so should block/function scope static structured binding act allow
(multiple) placeholders or should the standard wording be changed even for that
case?

If I disable the last hunk in parser.cc in this patch, then #c6 works, but
void freddy ()
{
  static int a[2];
  static auto [_, _] = a;
  static auto [_, _] = a;
}
fails to assemble as there is _ZNDC1_1_EE emitted twice.

[Bug c++/111069] New: Mangling of static structured bindings

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

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

Bug ID: 111069
   Summary: Mangling of static structured bindings
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void
corge ()
{
  static int a[2];
  static auto [i, j] = a;
  static auto [k, l] = a;
  {
static auto [i, j] = a;
static auto [k, l] = a;
  }
  {
static auto [i, j] = a;
static auto [k, l] = a;
  }
}

fails to assemble with -std=c++20, we use
_ZNDC1i1jEE and _ZNDC1k1lEE as names of the local variables multiple times
(+ _ZGVZ5corgevE11_ZNDC1i1jEE and _ZGVZ5corgevE11_ZNDC1k1lEE for guards which
are emitted each just once but prevent the initialization of the second and
third case).
clang++ uses _ZZ5corgevEDC1i1jE, _ZZ5corgevEDC1k1lE_0, _ZZ5corgevEDC1i1jE_1,
_ZZ5corgevEDC1k1lE_2 etc. and corresponding guard vars.
Now, I guess for local vars it is up to us to name those as we want as long as
there is no clash, with
inline void
freddy ()
{
  static int a[2];
  static auto [i, j] = a;
  static auto [k, l] = a;
  {
static auto [i, j] = a;
static auto [k, l] = a;
  }
  {
static auto [i, j] = a;
static auto [k, l] = a;
  }
}
void (*p)() = &freddy;
it is an ABI issue.

[Bug c++/111069] Mangling of static structured bindings

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

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

--- Comment #1 from Jakub Jelinek  ---
Apparently my fault as I've done r10-720-gb7f0df71a9de2354fcb7 which enabled
it,
but am not really sure what is the correct mangling.

[Bug c++/111069] Mangling of static structured bindings

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108257

--- Comment #2 from Andrew Pinski  ---
I suspect this is a dup of bug 108257 .

[Bug c++/111069] Mangling of static structured bindings

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

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

--- Comment #3 from Jakub Jelinek  ---
Yes, though this PR has more info.

grep 1[ik]1[jl] pr111069-2.s | grep :
_ZZ6freddyvEDC1i1jE:
_ZGVZ6freddyvEDC1i1jE:
_ZZ6freddyvEDC1k1lE:
_ZGVZ6freddyvEDC1k1lE:
_ZZ6freddyvEDC1i1jE_0:
_ZGVZ6freddyvEDC1i1jE_0:
_ZZ6freddyvEDC1k1lE_0:
_ZGVZ6freddyvEDC1k1lE_0:
_ZZ6freddyvEDC1i1jE_1:
_ZGVZ6freddyvEDC1i1jE_1:
_ZZ6freddyvEDC1k1lE_1:
_ZGVZ6freddyvEDC1k1lE_1:
shows that for inline functions I think clang++ mangling is right.

[Bug c++/111069] Mangling of static structured bindings

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-08-18

[Bug c/111070] New: ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111070
   Summary: ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

$ ~/gcc/results/bin/gcc -c -w -O1 ./gcc.target/tic6x/abi-align-1.c
during GIMPLE pass: ifcombine
./gcc.target/tic6x/abi-align-1.c: In function ‘main’:
./gcc.target/tic6x/abi-align-1.c:12:5: internal compiler error: tree check:
expected ssa_name, have addr_expr in ifcombine_ifandif, at
tree-ssa-ifcombine.cc:492
   12 | int main ()
  | ^~~~
0x117a512 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk.year/gcc/tree.cc:8899
0xfbfefd ifcombine_ifandif(basic_block_def*, bool, basic_block_def*, bool,
bool)
../../trunk.year/gcc/tree-ssa-ifcombine.cc:0

$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb38/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20230818.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.year/configure
--prefix=/home/dcb38/gcc/results.20230818.asan.ubsan --disable-multilib
--disable-bootstrap --with-build-config=bootstrap-asan
--with-build-config=bootstrap-ubsan --with-pkgversion=68f7cb6cf9e8b9f2
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230818 (experimental) (68f7cb6cf9e8b9f2) 
testsuite $

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining

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

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

--- Comment #17 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Jan Hubicka from comment #4)
> > > Not all testcases can be handled at gimplification time IIRC.  Which
> > > means "testcases welcome" first, so we can look at them individually.
> > 
> > The GCC one I saw was equivalent of:
> > #include 
> > bool
> > m_is_less_than_n (int n, int m)
> > {
> >return (n==m || m_is_less_than_n (n-1,m));
> > }
> 
> First we cannot optimize this into a loop until tailc rather than in either
> tailr1 or tailr2.
> 
> In tailr1, we have:
>   _2 = m_is_less_than_n (_1, m_7(D));
>   if (_2 != 0)
> goto ; [INV]
>   else
> goto ; [INV]
> 
>:
> 
>:
>   # iftmp.0_3 = PHI <1(6), 0(3), 1(2)>
>   _12 = (_Bool) iftmp.0_3;
> 
> 
> While in tailr2, we have:
>   _18 = m_is_less_than_n (_17, m_6(D));
>   _4 = (int) _18;
> 
>[local count: 1073741825]:
>   # iftmp.0_3 = PHI <_4(6), 1(3), 1(2), 1(4), 1(5)>
>   _8 = (_Bool) iftmp.0_3;
> 
> It is not until PRE where we remove the casts (to/from int).

I have a phiopt change which allows us now to optimize this in phiopt2 (and get
the tail call in tailr2).

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from Tommy Murphy  ---
Thanks for the comments Palmer and Kito.

However I'm still a bit confused. Is it the case that the multilib patterns
(for the "base" lib and reuse patterns) are interpreted/used differently in the
context of t-linux-multilib versus t-elf-multilib? And my interpretation was
incorrect for the former even if it is correct for the latter?

If any of this renders this bug report moot then just let me know or close it
off if necessary.

[Bug c++/86646] Special member function 'cannot be defaulted' if type alias is used

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #4 from Arthur O'Dwyer  ---
I just ran into this (it's one of the examples of vendor divergence in
P2953R0).
https://isocpp.org/files/papers/P2953R0.html#corner-cases

  // https://godbolt.org/z/sxv5rvn8o
  template
  struct C {
C& operator=(std::add_lvalue_reference_t) = default;
  };
  C cl;

GCC 13 says:

error: 'C<  >& C< 
>::operator=(std::add_lvalue_reference_t >
>)' cannot be defaulted
5 |   C& operator=(std::add_lvalue_reference_t) = default;
  |^~~

I confirm Andrew's observation that Clang is the odd one out in accepting this
code (GCC, MSVC, EDG all reject). But it also seems pretty obvious that it
should be accepted. Brian Bi concurs: "I couldn't figure out any reason why
this shouldn't be valid."

Or again something like this:

  template
  struct C {
C(std::conditional_t) = default;
C(std::conditional_t);
  };
  static_assert(std::is_trivially_copy_constructible_v>);
  static_assert(std::is_trivially_move_constructible_v>);

GCC+EDG+MSVC reject; Clang accepts; and I think Clang is the conforming one.

A related situation is

  // https://godbolt.org/z/1bhEx1Gr1
  template
  struct C {
template using A = const C&;
C(A...) = default;
  // this is a default ctor or a copy ctor, depending on sizeof...(Ts)
  };
  static_assert(std::is_trivially_constructible_v>);
  static_assert(std::is_trivially_copy_constructible_v>);

GCC rejects; Clang+EDG+MSVC accept; and I think Clang+EDG+MSVC are conforming.

[Bug tree-optimization/111049] spurious stringop-overflow depending on structure pointer arithmetic with certain sized structures

[mark at infocomm dot com via Gcc-bugs]

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

--- Comment #2 from Mark Pizzolato  ---
> Looks like this is fixed for GCC 11.

The latest Raspberry Pi OS is still packaging gcc 10.2.1.

How was this tested with gcc 11?

Was there a specific change that addressed the problem?  If so, can we get a
pointer to that?

Did the testing include running with a wide range of structure sizes?  10.2.1
demonstrates the issue with some structure sizes and not others.  It is not
just sizes above a certain size which reliably demonstrate the problem.

[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:27d0cfcb2b33de07351d9cb26f62d04d7416716c

commit r14-3329-g27d0cfcb2b33de07351d9cb26f62d04d7416716c
Author: Jonathan Wakely 
Date:   Fri Aug 18 13:10:15 2023 +0100

libstdc++: Revert pre-C++23 support for 16-bit float types [PR111060]

In r14-3304-g1a566fddea212a and r14-3305-g6cf214b4fc97f5 I tried to
enable std::format for 16-bit float types before C++23. This causes
errors for targets where the types are defined but can't actually be
used, e.g. i686 without sse2.

Make the std::numeric_limits and std::formatter specializations for
_Float16 and __bfloat16_t depend on the __STDCPP_FLOAT16_T__ and
__STDCPP_BFLOAT16_T__ macros again, so they're only defined for C++23
when the type is fully supported. This is OK because the main point of
my earlier commits was to add better support for _Float32 and _Float64.
It seems fine for the new 16-bit types to only be supported for C++23,
as they were never present before GCC 13 anyway.

libstdc++-v3/ChangeLog:

PR target/111060
* include/std/format (formatter): Only define specializations
for 16-bit floating-point types for C++23.
* include/std/limits (numeric_limits): Likewise.

[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed, thanks for the report.

[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types

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

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

--- Comment #6 from Eric Gallager  ---
Would it be possible to add a fix-it hint to this warning, too, while you're at
it?

[Bug target/111071] New: gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp has new failures since commit e7a36e4715c7

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Bug ID: 111071
   Summary: gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
has new failures since commit e7a36e4715c7
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
CC: yanzhang.wang at intel dot com
  Target Milestone: ---

Created attachment 55760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55760&action=edit
gcc.log from trunk as of commit 4acbb51d7f28

Our CI detected that commit e7a36e4715c7 "[PATCH] RISC-V: Support simplify
(-1-x) for vector." introduced these testsuite failures on aarch64-linux:

=== g++ tests ===

Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ...
FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL  check-function-bodies
subr_m1_s8_m
FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS 
check-function-bodies subr_m1_s8_m
FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL  check-function-bodies
subr_m1_u8_m
FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS 
check-function-bodies subr_m1_u8_m
=== gcc tests ===

Running gcc:gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ...
FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL  check-function-bodies
subr_m1_s8_m
FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS 
check-function-bodies subr_m1_s8_m
FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL  check-function-bodies
subr_m1_u8_m
FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS 
check-function-bodies subr_m1_u8_m

I confirmed that they are still present in trunk as of commit 4acbb51d7f28
"Daily bump." from today.

Tested on Ubuntu 22.04 with:

$ ~/src/gcc/configure \
--disable-bootstrap \
--disable-multilib \
&& make -j 60 \
&& make -C gcc check-gcc
RUNTESTFLAGS=gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp

I'll attach gcc.log from trunk as well as from the parent of commit
e7a36e4715c7, which was the last commit where the test passed.

[Bug target/111071] gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp has new failures since commit e7a36e4715c7

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #1 from Thiago Jung Bauermann  
---
Created attachment 55761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55761&action=edit
gcc.log from commit a32de58c9e63, parent of e7a36e4715c

[Bug testsuite/111071] [14 Regression] gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp has new failures since commit e7a36e4715c7

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||testsuite-fail
Version|unknown |14.0
 Ever confirmed|0   |1
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
Summary|gcc.target/aarch64/sve/acle |[14 Regression]
   |/aarch64-sve-acle-asm.exp   |gcc.target/aarch64/sve/acle
   |has new failures since  |/aarch64-sve-acle-asm.exp
   |commit e7a36e4715c7 |has new failures since
   ||commit e7a36e4715c7
  Component|target  |testsuite
   Last reconfirmed||2023-08-19

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

The code is better:
For subr_m1_s8_m, GCC now produces:

not z0.b, p0/m, z0.b
ret

Rather than what was originally expected:
/*
** subr_m1_s8_m:
**  mov (z[0-9]+\.b), #-1
**  subrz0\.b, p0/m, z0\.b, \1
**  ret
*/

So just a testsuite update is needed here.

[Bug c++/111072] New: Splicing at the end fails

[verodeving at gmail dot com via Gcc-bugs]

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

Bug ID: 111072
   Summary: Splicing at the end fails
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: verodeving at gmail dot com
  Target Milestone: ---

The following code fails under GCC(trunk) and the compiler options -Wall
-Werror -Wextra -pedantic-errors -Wpedantic -O3 -std=c++23(untested under other
compiler options or other GCC versions):

int \
 a;

An example of the failure can be seen at https://godbolt.org/z/WhKK7rYne

This behaviour is incorrect because https://eel.is/c++draft/lex.phases#1.2
mentions the following:

- A source file that is not empty and that does not end in a new-line
character, or that ends in a splice, shall be processed as if an additional
new-line character were appended to the file.

Therefore, the backslash at the end of the file shouldn't error because it
should behave as a new line was appended at the end of the file, according to
the mentioned standard paragraph.

[Bug preprocessor/111072] Splicing at the end fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-08-19
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Note C17 has:
A source file that is not empty shall end in a new-line character, which shall
not be immediately preceded by a backslash character before any such splicing
takes place.

C++11, C++17 and C++20:
A source file that is not empty and that does not end in a new-line character,
or that ends in a new-line character immediately preceded by a backslash
character before any such splicing takes place, shall be processed as if an
additional new-line character were appended to the file.

So this is a difference between C++ and C :).

And GCC just misses that point out.

[Bug middle-end/111017] [12/13/14 Regression][OpenMP] Wrong code with non-rectangular loop nest

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:1dc65003b66e5a97200f454eeddcccfce34416b3

commit r14-3332-g1dc65003b66e5a97200f454eeddcccfce34416b3
Author: Tobias Burnus 
Date:   Sat Aug 19 07:49:06 2023 +0200

omp-expand.cc: Fix wrong code with non-rectangular loop nest [PR111017]

Before commit r12-5295-g47de0b56ee455e, all gimple_build_cond in
expand_omp_for_* were inserted with
  gsi_insert_before (gsi_p, cond_stmt, GSI_SAME_STMT);
except the one dealing with the multiplicative factor that was
  gsi_insert_after (gsi, cond_stmt, GSI_CONTINUE_LINKING);

That commit for PR103208 fixed the issue of some missing regimplify of
operands of GIMPLE_CONDs by moving the condition handling to the new
function
expand_omp_build_cond. While that function has an 'bool after = false'
argument to switch between the two variants.

However, all callers ommited this argument. This commit reinstates the
prior behavior by passing 'true' for the factor != 0 condition, fixing
the included testcase.

PR middle-end/111017
gcc/
* omp-expand.cc (expand_omp_for_init_vars): Pass after=true
to expand_omp_build_cond for 'factor != 0' condition, resulting
in pre-r12-5295-g47de0b56ee455e code for the gimple insert.

libgomp/
* testsuite/libgomp.c-c++-common/non-rect-loop-1.c: New test.

[Bug c++/111073] New: [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk

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

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

Bug ID: 111073
   Summary: [13/14 regression] False-positive -Wstringop-overflow
when building gdb from trunk
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org, tromey at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55762&action=edit
infcall.ii.xz

12.3.1 20230818 is OK, but 13.2.1 20230812 and 14.0.0 20230813 aren't.

I filed this over at gdb first:
https://sourceware.org/bugzilla/show_bug.cgi?id=30780.

```
$ g++-14 -x c++-I. -I. -I./config -DLOCALEDIR="\"/usr/local/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I../bfd -I./../bfd -I./../include
-I./../readline/readline/.. -I./../zlib  -I../libdecnumber -I./../libdecnumber 
-I./../gnulib/import -I../gnulib/import -I./.. -I.. -I./../libbacktrace/
-I../libbacktrace/ -DTUI=1-I/usr/include/python3.12
-I/usr/include/python3.12   -I./.. -pthread-Wall -Wpointer-arith
-Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch
-Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
-Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized
-Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3
-Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor
-Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat
-Wformat-nonliteral -Werror -g -O2 -c -o infcall.o -MT infcall.o -MMD -MP
-MF ./.deps/infcall.Tpo infcall.c
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/hashtable_policy.h:36,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/hashtable.h:35,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/unordered_map.h:33,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/unordered_map:41,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/functional:63,
 from ./../gdbsupport/ptid.h:35,
 from ./../gdbsupport/common-defs.h:206,
 from defs.h:26,
 from infcall.c:20:
In static member function ‘static _Up* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
value*; _Up = value*; bool _IsMove = false]’,
inlined from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = value**; _OI = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:506:30,
inlined from ‘_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
false; _II = value**; _OI = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:533:42,
inlined from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = value**; _OI = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:540:31,
inlined from ‘_OI std::copy(_II, _II, _OI) [with _II = value**; _OI =
value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:633:7,
inlined from ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = value**; _ForwardIterator = value**]’
at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_uninitialized.h:147:27,
inlined from ‘_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = value**;
_ForwardIterator = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_uninitialized.h:185:15,
inlined from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator =
value**; _ForwardIterator = value**; _Tp = value*]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_uninitialized.h:373:37,
inlined from ‘void std::vector<_Tp, _Alloc>::_M_range_insert(iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = value**; _Tp = value*; _Alloc = std::allocator]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/vector.tcc:884:38,
inlined from ‘std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, _InputIterator, _InputIterator) [with
_InputIterator = value**;  = void; _Tp = value*; _Alloc
= std::allocator]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_vector.h:1486:19,
inlined from ‘value* call_function_by_hand_dummy(value*, type*,
gdb::array_view, void (*)(void*, int), void*)’ a

[Bug c++/111073] [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk

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

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

Sam James  changed:

   What|Removed |Added

 Blocks||88443

--- Comment #1 from Sam James  ---
I can reproduce it with:
```
$ g++-14 -c infcall.ii -O2 -Werror=stringop-overflow
[...]
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:437:30:
error: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing
9 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
  437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~
[...]
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug c++/111073] [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS

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

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

Sam James  changed:

   What|Removed |Added

Summary|[13/14 regression]  |[13/14 regression]
   |False-positive  |False-positive
   |-Wstringop-overflow when|-Wstringop-overflow when
   |building gdb from trunk |building gdb from trunk
   ||with -D_GLIBCXX_ASSERTIONS

--- Comment #2 from Sam James  ---
Oh, interesting. It needs -D_GLIBCXX_ASSERTIONS (which my gcc has on by
default) to trigger.