[Bug middle-end/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7

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

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

--- Comment #5 from Sam James  ---
> the libarchive, is that also with -march=znver2? and is
> https://github.com/libarchive/libarchive?

Yeah, filed PR113734 for it.

[Bug middle-end/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-03
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #4 from Tamar Christina  ---
blah,

  gsi_move_before (_gsi, _gsi);

when dest_gsi is empty does not move the pointer.  It's not mentioned in the
description but in the function it eventually calls gsi_insert_before there's a
comment

/* If CUR is NULL, we link at the end of the sequence (this case happens

so it adds it to the end instead of start like you asked.

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 30b90d99925..e2587315020 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -11801,7 +11801,8 @@ move_early_exit_stmts (loop_vec_info loop_vinfo)

   gimple_stmt_iterator stmt_gsi = gsi_for_stmt (stmt);
   gsi_move_before (_gsi, _gsi);
-  gsi_prev (_gsi);
+  if (!gsi_end_p (dest_gsi))
+   gsi_prev (_gsi);
 }

fixes it.

the libarchive, is that also with -march=znver2? and is
https://github.com/libarchive/libarchive?

RE: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Li, Pan2]

Hi Edwin

> I believe the only problematic failures are the 5 vls calling convention 
> ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.

Does this "only 24" comes from calling-convention-1.c? 

> This is what I'm getting locally (first instance of wrong match):
> v32qi_RET1_ARG8:
> .LFB109:

V32qi will pass the args by reference instead of GPR(s), thus It is expected. I 
think we need to diff the asm code before and after the patch for the whole 
test-file.
The RE "ld\\s+a[0-1],\\s*[0-9]+\\(sp\\)" would like to check vls mode values 
are returned by a[0-1].

Pan

-Original Message-
From: Edwin Lu  
Sent: Saturday, February 3, 2024 8:29 AM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches 

Cc: Robin Dapp ; kito.cheng ; 
jeffreyalaw ; palmer ; vineetg 
; Patrick O'Neill 
Subject: Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

On 2/1/2024 8:28 PM, Li, Pan2 wrote:
> Hi Edwin,
> 
> Just rerun the newlib and there is no ICE but still 160 dump failures as 
> below.
> 
> Pan
> 

Hi Pan,

Thanks for confirming! Having dump failures is expected. There are 
around 7 more unique failures than I expected 
(https://github.com/patrick-rivos/gcc-postcommit-ci/issues/473 <-- 
postcommit found 46 while I expected 39 
https://inbox.sourceware.org/gcc-patches/12d205cd-3177-48ea-a54e-c2052fdde...@gmail.com/
 
https://github.com/ewlu/gcc-precommit-ci/issues/1178#issuecomment-1889782987) 


I included the 7 failed tests below and what was found instead.

I believe the only problematic failures are the 5 vls calling convention 
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.

FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 35
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 33
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 31
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29

This is what I'm getting locally (first instance of wrong match):
v32qi_RET1_ARG8:
.LFB109:
 .cfi_startproc
 li  t1,32
 vsetvli zero,t1,e8,mf8,ta,ma
 vle8.v  v1,0(a1)
 vle8.v  v4,0(a2)
 vle8.v  v3,0(a3)
 vle8.v  v2,0(a4)
 vadd.vv v1,v1,v4
 vadd.vv v1,v1,v3
 vle8.v  v3,0(a5)
 ld  a5,0(sp)  <-- used a5 instead of a1
 vadd.vv v1,v1,v2
 vle8.v  v2,0(a6)
 vadd.vv v1,v1,v3
 vle8.v  v3,0(a7)
 vadd.vv v1,v1,v2
 vle8.v  v2,0(a5)
 vadd.vv v1,v1,v3
 vadd.vv v1,v1,v2
 vse8.v  v1,0(a0)
 ret
 .cfi_endproc

If I understand correctly, this is wrong since we aren't returning 
anything (nothing gets stored in a[0-1])?

Edwin

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #15 from Li Pan  ---
(In reply to Tamar Christina from comment #14)
> Awesome! Feel free to reach out if you need any help.
> 
> It’s likely easier to start with add and sub and get things pipe cleaned and
> expand incrementally than to try and do it all at once.

Cool, thanks in advance.

I will first try to make a SAT_ADD to the direct optab for a POC following your
RFC and suggestion. Looks like at least match.pd and internal-fn.def will be
touched. I am learning how match.pd works right now.

Dedicated Servers Promotions and offers-gcc-b...@gcc.gnu.org

[gowebing via Gcc-bugs]

Mumara Email Template 

 

 

Dedicated Server Hosting 

 

 

 

Dedicated Servers Promotions and Offers

 

 

CPU:i3  RAM:8G Disk:1T United States

 

79 USD/M 
:http://click.return.gowebing.com/campaign/clicked/MjA5ODk3MDQw__MjgwNg%3D%3D__MzIxNjI5NTU%3D__ODkx__2036__3100__129/aHR0cHMlM0ElMkYlMkZ3d3cuZ293ZWJpbmcuY29tJTJGcHJvbW90aW9ucy5waHA=
 

 

  

 

 

gowebing  |  
unsubscribe:http://click.return.gowebing.com/campaign/unsub-email/MjgwNg%3D%3D/MzIxNjI5NTU%3D/MjAzNg%3D%3D__MjA5ODk3MDQw__ODkx

Dedicated Servers Promotions and offers-gcc-b...@gcc.gnu.org

[gowebing via Gcc-bugs]

Mumara Email Template 

 

 

Dedicated Server Hosting 

 

 

 

Dedicated Servers Promotions and Offers

 

 

CPU:i3  RAM:8G Disk:1T United States

 

79 USD/M 
:http://click.return.gowebing.com/campaign/clicked/MjA5ODk3MDQw__MjgwNg%3D%3D__MzIxNjI5NTU%3D__ODkx__2036__3100__129/aHR0cHMlM0ElMkYlMkZ3d3cuZ293ZWJpbmcuY29tJTJGcHJvbW90aW9ucy5waHA=
 

 

  

 

 

gowebing  |  
unsubscribe:http://click.return.gowebing.com/campaign/unsub-email/MjgwNg%3D%3D/MzIxNjI5NTU%3D/MjAzNg%3D%3D__MjA5ODk3MDQw__ODkx

Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

[Steve Kargl]

Jerry,

The patch looks good to me, but please give Harald a chance
to comment.

-- 
steve

On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> > 
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the handling of the EN0.0E0 and
> > > ES0.0E0 formatting by correctly calculating the number of digits needed
> > > for the exponents and building those exponents into the float string.
> > 
> > while your patch addresses ENw.dE0 and ESw.dE0 formatting,
> > it does not fix Ew.dE0, which can be seen with the following test:
> > 
> >    write(buffer,"(E0.3E0)") .6660_4
> >    print *, buffer
> >    write(buffer,"(E0.3)") .6660_4
> >    print *, buffer
> > 
> > I get even with your patch:
> > 
> >   0.666
> >   0.666
> > 
> > but would have expected:
> > 
> >   0.666E+0   ! F2018 & F2023, table 13.1
> >   0.666E+0   ! F2023, table 13.1
> > 
> 
> Tha attached file shows the complete revised patch and git log generated by
> using the 'git show' command. I only just discovered that one. (eye roll).
> 
> Regressions tested on x86-64.  OK for trunk?
> 
> Regards,
> 
> Jerry

> commit 95c878a97944f952aef226ff0224b2198abfbe0f
> Author: Jerry DeLisle 
> Date:   Fri Feb 2 18:12:33 2024 -0800
> 
> libgfortran: EN0.0E0 and ES0.0E0 format editing.
> 
> PR libgfortran/111022
> 
> F2018 and F2023 standards added zero width exponents. This required
> additional special handing in the process of building formatted
> floating point strings.
> 
> G formatting uses either F or E formatting as documented in
> write_float.def comments. This logic changes the format token from FMT_G
> to FMT_F or FMT_E. The new formatting requirements interfere with this
> process when a FMT_G float string is being built.  To avoid this, a new
> component called 'pushed' is added to the fnode structure to save this
> condition.  The 'pushed' condition is then used to bypass portions of
> the new ES,E,EN, and D formatting, falling through to the existing
> default formatting which is retained.
> 
> libgfortran/ChangeLog:
> 
> * io/format.c (get_fnode): Update initialization of fnode.
> (parse_format_list): Initialization.
> * io/format.h (struct fnode): Added the new 'pushed' component.
> * io/write.c (select_buffer): Whitespace.
> (write_real): Whitespace.
> (write_real_w0): Adjust logic for the d == 0 condition.
> * io/write_float.def (determine_precision): Whitespace.
> (build_float_string): Calculate width of ..E0 exponents and
> adjust logic accordingly.
> (build_infnan_string): Whitespace.
> (CALCULATE_EXP): Whitespace.
> (quadmath_snprintf): Whitespace.
> (determine_en_precision): Whitespace.
> 
> gcc/testsuite/ChangeLog:
> 
> * gfortran.dg/fmt_error_10.f: Show D+0 exponent.
> * gfortran.dg/pr96436_4.f90: Show E+0 exponent.
> * gfortran.dg/pr96436_5.f90: Show E+0 exponent.
> * gfortran.dg/pr111022.f90: New test.
> 
> diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f 
> b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> index 6e1a5f60bea..fc6620a60a6 100644
> --- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
> +++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> @@ -18,7 +18,7 @@
>  
>str = '(1pd0.15)'
>write (line,str,iostat=istat, iomsg=msg) 1.0d0
> -  if (line.ne."1.000") STOP 5
> +  if (line.ne."1.000D+0") STOP 5
>read (*,str,iostat=istat, iomsg=msg) x
>if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
>if (x.ne.555.25) STOP 7
> diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 
> b/gcc/testsuite/gfortran.dg/pr111022.f90
> new file mode 100644
> index 000..eef55ff5ce0
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr111022.f90
> @@ -0,0 +1,72 @@
> +! { dg-do run }
> +program pr111022
> +  character(20) :: buffer
> +  write(buffer,"(EN0.3E0)") .6660_4
> +  if (buffer.ne."666.000E-3") stop 1
> +  write(buffer,"(EN0.3E0)") 6.660_4
> +  if (buffer.ne."6.660E+0") stop 2
> +  write(buffer,"(EN0.3E0)") 66.60_4
> +  if (buffer.ne."66.600E+0") stop 3
> +  write(buffer,"(EN0.3E0)") 666.0_4
> +  if (buffer.ne."666.000E+0") stop 4
> +  write(buffer,"(EN0.3E0)") 6660.0_4
> +  if (buffer.ne."6.660E+3") stop 5
> +  write(buffer,"(EN0.3E0)") 66600.0_4
> +  if (buffer.ne."66.600E+3") stop 6
> +  
> +  write(buffer,"(EN0.0E0)") 666.0_4
> +  if (buffer.ne."666.E+0") stop 7
> +  write(buffer,"(EN0.0E1)") 666.0_4
> +  if (buffer.ne."666.E+0") stop 8
> +  write(buffer,"(EN0.0E2)") 666.0_4
> +  if (buffer.ne."666.E+00") stop 9
> +  write(buffer,"(EN0.0E3)") 666.0_4
> +  if (buffer.ne."666.E+000") stop 10
> +  write(buffer,"(EN0.0E4)") 666.0_4
> +  if (buffer.ne."666.E+") stop 11
> +  

Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

[Jerry D]

On 1/30/24 12:36 PM, Harald Anlauf wrote:

Hi Jerry,

Am 30.01.24 um 19:15 schrieb Jerry D:

The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.


while your patch addresses ENw.dE0 and ESw.dE0 formatting,
it does not fix Ew.dE0, which can be seen with the following test:

   write(buffer,"(E0.3E0)") .6660_4
   print *, buffer
   write(buffer,"(E0.3)") .6660_4
   print *, buffer

I get even with your patch:

  0.666
  0.666

but would have expected:

  0.666E+0   ! F2018 & F2023, table 13.1
  0.666E+0   ! F2023, table 13.1



Tha attached file shows the complete revised patch and git log generated 
by using the 'git show' command. I only just discovered that one. (eye 
roll).


Regressions tested on x86-64.  OK for trunk?

Regards,

Jerry
commit 95c878a97944f952aef226ff0224b2198abfbe0f
Author: Jerry DeLisle 
Date:   Fri Feb 2 18:12:33 2024 -0800

libgfortran: EN0.0E0 and ES0.0E0 format editing.

PR libgfortran/111022

F2018 and F2023 standards added zero width exponents. This required
additional special handing in the process of building formatted
floating point strings.

G formatting uses either F or E formatting as documented in
write_float.def comments. This logic changes the format token from FMT_G
to FMT_F or FMT_E. The new formatting requirements interfere with this
process when a FMT_G float string is being built.  To avoid this, a new
component called 'pushed' is added to the fnode structure to save this
condition.  The 'pushed' condition is then used to bypass portions of
the new ES,E,EN, and D formatting, falling through to the existing
default formatting which is retained.

libgfortran/ChangeLog:

* io/format.c (get_fnode): Update initialization of fnode.
(parse_format_list): Initialization.
* io/format.h (struct fnode): Added the new 'pushed' component.
* io/write.c (select_buffer): Whitespace.
(write_real): Whitespace.
(write_real_w0): Adjust logic for the d == 0 condition.
* io/write_float.def (determine_precision): Whitespace.
(build_float_string): Calculate width of ..E0 exponents and
adjust logic accordingly.
(build_infnan_string): Whitespace.
(CALCULATE_EXP): Whitespace.
(quadmath_snprintf): Whitespace.
(determine_en_precision): Whitespace.

gcc/testsuite/ChangeLog:

* gfortran.dg/fmt_error_10.f: Show D+0 exponent.
* gfortran.dg/pr96436_4.f90: Show E+0 exponent.
* gfortran.dg/pr96436_5.f90: Show E+0 exponent.
* gfortran.dg/pr111022.f90: New test.

diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f b/gcc/testsuite/gfortran.dg/fmt_error_10.f
index 6e1a5f60bea..fc6620a60a6 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
@@ -18,7 +18,7 @@
 
   str = '(1pd0.15)'
   write (line,str,iostat=istat, iomsg=msg) 1.0d0
-  if (line.ne."1.000") STOP 5
+  if (line.ne."1.000D+0") STOP 5
   read (*,str,iostat=istat, iomsg=msg) x
   if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
   if (x.ne.555.25) STOP 7
diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 b/gcc/testsuite/gfortran.dg/pr111022.f90
new file mode 100644
index 000..eef55ff5ce0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr111022.f90
@@ -0,0 +1,72 @@
+! { dg-do run }
+program pr111022
+  character(20) :: buffer
+  write(buffer,"(EN0.3E0)") .6660_4
+  if (buffer.ne."666.000E-3") stop 1
+  write(buffer,"(EN0.3E0)") 6.660_4
+  if (buffer.ne."6.660E+0") stop 2
+  write(buffer,"(EN0.3E0)") 66.60_4
+  if (buffer.ne."66.600E+0") stop 3
+  write(buffer,"(EN0.3E0)") 666.0_4
+  if (buffer.ne."666.000E+0") stop 4
+  write(buffer,"(EN0.3E0)") 6660.0_4
+  if (buffer.ne."6.660E+3") stop 5
+  write(buffer,"(EN0.3E0)") 66600.0_4
+  if (buffer.ne."66.600E+3") stop 6
+  
+  write(buffer,"(EN0.0E0)") 666.0_4
+  if (buffer.ne."666.E+0") stop 7
+  write(buffer,"(EN0.0E1)") 666.0_4
+  if (buffer.ne."666.E+0") stop 8
+  write(buffer,"(EN0.0E2)") 666.0_4
+  if (buffer.ne."666.E+00") stop 9
+  write(buffer,"(EN0.0E3)") 666.0_4
+  if (buffer.ne."666.E+000") stop 10
+  write(buffer,"(EN0.0E4)") 666.0_4
+  if (buffer.ne."666.E+") stop 11
+  write(buffer,"(EN0.0E5)") 666.0_4
+  if (buffer.ne."666.E+0") stop 12
+  write(buffer,"(EN0.0E6)") 666.0_4
+  if (buffer.ne."666.E+00") stop 13
+  
+  write(buffer,"(ES0.3E0)") .6660_4
+  if (buffer.ne."6.660E-1") stop 14
+  write(buffer,"(ES0.3E0)") 6.660_4
+  if (buffer.ne."6.660E+0") stop 15
+  write(buffer,"(ES0.3E0)") 66.60_4
+  if (buffer.ne."6.660E+1") stop 16
+  write(buffer,"(ES0.3E0)") 666.0_4
+  if (buffer.ne."6.660E+2") stop 17
+  

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com via Gcc-bugs]

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

--- Comment #10 from Ali Bahrami  ---
> I think the issue described here are all covered by pr 63572

Can you explain how? I might not have followed it, but
pr 63572 seems to revolve around generating correct DWARF
content? Here, we're not reading the DWARF at all, so its
correctness isn't a factor. We're not really making any claims
about gcc correctness.

The problem here is that what these optimizations do
cause us difficulties in our simple mapping of addresses
to names, while the optimizations themselves don't have
enough impact to fight for. Hence, we'd like the option
to opt out.

- Ali

[Bug middle-end/113734] New: [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7

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

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

Bug ID: 113734
   Summary: [14 regression] libarchive miscompiled (fails
libarchive_test_read_format_rar5_extra_field_version
test) since r14-8768-g85094e2aa6dba7
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---

This is the miscompilation in libarchive's test suite I mentioned as an aside
in PR113731.

Steps to reproduce:
1. wget
https://github.com/libarchive/libarchive/releases/download/v3.7.2/libarchive-3.7.2.tar.xz
2. tar xvf libarchive-3.7.2.tar.xz && cd libarchive-3.7.2
3. export CFLAGS="-O3 -march=znver2 -ggdb3" CXXFLAGS="-O3 -march=znver2 -ggdb3"
; cmake -B out -S . -G Ninja
4. ninja -C out
5. ninja -C out test

The test failure is pretty suspicious:
```
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:106:
bytes_read != fsize
  bytes_read=-30 (0xffe2, 0177742)
  fsize=95 (0x5f, 0137)
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:959:
Assertion failed: 0 == extract_one(a, ae, 0xF24181B7)
errno: 22
   detail: Failed to decode the distance slot

Totals:
  Tests run:1
  Tests failed: 1
  Assertions checked: 399
  Assertions failed:4
  Skips reported:   0

Failing tests:
  347: test_read_format_rar5_extra_field_version (4 failures)
```

If I run it under Valgrind, I then get:
```
$ valgrind "/home/sam/data/libarchive/libarchive-3.7.2/out/bin/libarchive_test"
"-vv" "-r" "/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test"
"test_read_fo
rmat_rar5_extra_field_version"
==205571== Memcheck, a memory error detector
==205571== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==205571== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==205571== Command:
/home/sam/data/libarchive/libarchive-3.7.2/out/bin/libarchive_test -vv -r
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test
test_read_format_rar5_extra_field_version
==205571==

If tests fail or crash, details will be in:
   /tmp/libarchive_test.2024-02-03T00.01.16-000

Reference files will be read from:
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test
Exercising: libarchive 3.7.2 zlib/1.3.1 liblzma/5.5.1alpha bz2lib/1.0.8
liblz4/1.9.4 libzstd/1.5.5
347: test_read_format_rar5_extra_field_version
==205571== Use of uninitialised value of size 8
==205571==at 0x2752A9: create_decode_tables
(archive_read_support_format_rar5.c:2504)
==205571==by 0x2752A9: parse_tables.constprop.0
(archive_read_support_format_rar5.c:2736)
==205571==by 0x27C942: process_block
(archive_read_support_format_rar5.c:3557)
==205571==by 0x27C942: do_uncompress_file
(archive_read_support_format_rar5.c:3753)
==205571==by 0x27C942: uncompress_file
(archive_read_support_format_rar5.c:3837)
==205571==by 0x27C942: do_unpack (archive_read_support_format_rar5.c:3923)
==205571==by 0x27C942: rar5_read_data
(archive_read_support_format_rar5.c:4087)
==205571==by 0x23D63B: archive_read_data (archive_read.c:841)
==205571==by 0x1AA34C: extract_one (test_read_format_rar5.c:104)
==205571==by 0x1B22CA: test_read_format_rar5_extra_field_version
(test_read_format_rar5.c:955)
==205571==by 0x11E0A4: test_run (test_main.c:3570)
==205571==by 0x11E0A4: main (test_main.c:4182)
[...]
==205571==
==205571== Conditional jump or move depends on uninitialised value(s)
==205571==at 0x275518: create_decode_tables
(archive_read_support_format_rar5.c:2524)
==205571==by 0x275518: parse_tables.constprop.0
(archive_read_support_format_rar5.c:2736)
==205571==by 0x27C942: process_block
(archive_read_support_format_rar5.c:3557)
==205571==by 0x27C942: do_uncompress_file
(archive_read_support_format_rar5.c:3753)
==205571==by 0x27C942: uncompress_file
(archive_read_support_format_rar5.c:3837)
==205571==by 0x27C942: do_unpack (archive_read_support_format_rar5.c:3923)
==205571==by 0x27C942: rar5_read_data
(archive_read_support_format_rar5.c:4087)
==205571==by 0x23D63B: archive_read_data (archive_read.c:841)
==205571==by 0x1AA34C: extract_one (test_read_format_rar5.c:104)
==205571==by 0x1B22CA: test_read_format_rar5_extra_field_version
(test_read_format_rar5.c:955)
==205571==by 0x11E0A4: test_run (test_main.c:3570)
==205571==by 0x11E0A4: main (test_main.c:4182)
==205571==
[...]
```

I will dig a bit more.

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 2/1/2024 8:28 PM, Li, Pan2 wrote:

Hi Edwin,

Just rerun the newlib and there is no ICE but still 160 dump failures as below.

Pan



Hi Pan,

Thanks for confirming! Having dump failures is expected. There are 
around 7 more unique failures than I expected 
(https://github.com/patrick-rivos/gcc-postcommit-ci/issues/473 <-- 
postcommit found 46 while I expected 39 
https://inbox.sourceware.org/gcc-patches/12d205cd-3177-48ea-a54e-c2052fdde...@gmail.com/ 
https://github.com/ewlu/gcc-precommit-ci/issues/1178#issuecomment-1889782987) 



I included the 7 failed tests below and what was found instead.

I believe the only problematic failures are the 5 vls calling convention 
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.


FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 35
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 33
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 31
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29


This is what I'm getting locally (first instance of wrong match):
v32qi_RET1_ARG8:
.LFB109:
.cfi_startproc
li  t1,32
vsetvli zero,t1,e8,mf8,ta,ma
vle8.v  v1,0(a1)
vle8.v  v4,0(a2)
vle8.v  v3,0(a3)
vle8.v  v2,0(a4)
vadd.vv v1,v1,v4
vadd.vv v1,v1,v3
vle8.v  v3,0(a5)
ld  a5,0(sp)  <-- used a5 instead of a1
vadd.vv v1,v1,v2
vle8.v  v2,0(a6)
vadd.vv v1,v1,v3
vle8.v  v3,0(a7)
vadd.vv v1,v1,v2
vle8.v  v2,0(a5)
vadd.vv v1,v1,v3
vadd.vv v1,v1,v2
vse8.v  v1,0(a0)
ret
.cfi_endproc

If I understand correctly, this is wrong since we aren't returning 
anything (nothing gets stored in a[0-1])?


Edwin

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug c++/110006] [11/12/13 Regression] friend function template with constraint doesn't match existing declaration

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug c++/112769] [11/12/13 Regression] ICE on valid code related to requires-expression

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE on valid code related   |on valid code related to
   |to requires-expression  |requires-expression

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14 so far.

[Bug c++/110006] [11/12/13 Regression] friend function template with constraint doesn't match existing declaration

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |friend function template|friend function template
   |with constraint doesn't |with constraint doesn't
   |match existing declaration  |match existing declaration

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14 so far.

[Bug c++/112769] [11/12/13/14 Regression] ICE on valid code related to requires-expression

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:686b5eb9c9ee623a604dde5c49fa11c23f384c62

commit r14-8770-g686b5eb9c9ee623a604dde5c49fa11c23f384c62
Author: Patrick Palka 
Date:   Fri Feb 2 19:07:08 2024 -0500

c++: requires-exprs and partial constraint subst [PR110006]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

These PRs however illustrate that we still sometimes do need to
partially substitute into a requires-expression, in particular when it
appears in associated constraints that we're directly substituting for
sake of declaration matching or dguide constraint rewriting.  In these
cases we're being called from tsubst_constraint during which
processing_constraint_expression_p is true, so this patch checks this
predicate to control whether we defer substitution or partially
substitute.

In turn, we now need to propagate semantic tsubst flags through
tsubst_requires_expr rather than just using tf_none, notably for sake of
dguide constraint rewriting which sets tf_dguide.

PR c++/110006
PR c++/112769

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/110006] [11/12/13/14 Regression] friend function template with constraint doesn't match existing declaration

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:686b5eb9c9ee623a604dde5c49fa11c23f384c62

commit r14-8770-g686b5eb9c9ee623a604dde5c49fa11c23f384c62
Author: Patrick Palka 
Date:   Fri Feb 2 19:07:08 2024 -0500

c++: requires-exprs and partial constraint subst [PR110006]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

These PRs however illustrate that we still sometimes do need to
partially substitute into a requires-expression, in particular when it
appears in associated constraints that we're directly substituting for
sake of declaration matching or dguide constraint rewriting.  In these
cases we're being called from tsubst_constraint during which
processing_constraint_expression_p is true, so this patch checks this
predicate to control whether we defer substitution or partially
substitute.

In turn, we now need to propagate semantic tsubst flags through
tsubst_requires_expr rather than just using tf_none, notably for sake of
dguide constraint rewriting which sets tf_dguide.

PR c++/110006
PR c++/112769

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.

Reviewed-by: Jason Merrill 

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:64b0130bb6702c67a13caefaae9facef23d6ac60

commit r14-8769-g64b0130bb6702c67a13caefaae9facef23d6ac60
Author: Gaius Mulley 
Date:   Sat Feb 3 00:03:39 2024 +

PR modula2/113730 Unexpected handling of mixed-precision integer arithmetic

This patch fixes a bug which occurs when an expression is created with
a ZType and an integer or cardinal.  The resulting subexpression is
incorrecly given a ZType which allows compatibility with another
integer/cardinal type.  The solution was to fix the subexpression
type.  In turn this required a minor change to SArgs.mod.

gcc/m2/ChangeLog:

PR modula2/113730
* gm2-compiler/M2Base.mod (IsUserType): New procedure function.
(MixTypes): Use IsUserType instead of IsType before calling
MixTypes.
* gm2-compiler/M2GenGCC.mod (GetTypeMode): Remove and import from
SymbolTable.
(CodeBinaryCheck): Replace call to MixTypes with MixTypesBinary.
(CodeBinary): Replace call to MixTypes with MixTypesBinary.
(CodeIfLess): Replace MixTypes with ComparisonMixTypes.
(CodeIfGre): Replace MixTypes with ComparisonMixTypes.
(CodeIfLessEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfGreEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfNotEqu): Replace MixTypes with ComparisonMixTypes.
(ComparisonMixTypes): New procedure function.
* gm2-compiler/M2Quads.mod (BuildEndFor): Replace GenQuadO
with GenQuadOtok and pass tokenpos for the operands to the AddOp
and XIndrOp.
(CheckRangeIncDec): Check etype against NulSym and dtype for a
pointer and set etype to Address.
(BuildAddAdrFunction): New variable opa.  Convert operand to an
address and save result in opa.  Replace GenQuad with GenQuadOtok.
(BuildSubAdrFunction): New variable opa.  Convert operand to an
address and save result in opa.  Replace GenQuad with GenQuadOtok.
(BuildDiffAdrFunction): New variable opa.  Convert operand to an
address and save result in opa.  Replace GenQuad with GenQuadOtok.
(calculateMultipicand): Replace GenQuadO with GenQuadOtok.
(ConvertToAddress): New procedure function.
(BuildDynamicArray): Convert index to address before adding to
the base.
* gm2-compiler/SymbolTable.def (GetTypeMode): New procedure
function.
* gm2-compiler/SymbolTable.mod (GetTypeMode): New procedure
function implemented (moved from M2GenGCC.mod).
* gm2-libs/SArgs.mod (GetArg): Replace cast to PtrToChar with
ADDRESS.

gcc/testsuite/ChangeLog:

PR modula2/113730
* gm2/extensions/fail/arith1.mod: New test.
* gm2/extensions/fail/arith2.mod: New test.
* gm2/extensions/fail/arith3.mod: New test.
* gm2/extensions/fail/arith4.mod: New test.
* gm2/extensions/fail/arithpromote.mod: New test.
* gm2/extensions/fail/extensions-fail.exp: New test.
* gm2/linking/fail/badimp.def: New test.
* gm2/linking/fail/badimp.mod: New test.
* gm2/linking/fail/linking-fail.exp: New test.
* gm2/linking/fail/testbadimp.mod: New test.

Signed-off-by: Gaius Mulley 

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

[Jakub Jelinek]

On Fri, Feb 02, 2024 at 11:43:21PM +, Jonathan Yong wrote:
> On 2/1/24 15:33, Jonathan Yong wrote:
> > On 2/1/24 15:25, Jakub Jelinek wrote:
> > > On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
> > > > No, besides the formatting being incorrect both in ChangeLog and in the
> > > > patch, this pessimizes ILP32 hosts unnecessarily.
> > > 
> > > So like this instead?
> > > 
> > > 2024-02-01  Jakub Jelinek  
> > > 
> > > * hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
> > > HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
> > > HOST_SIZE_T_PRINT_HEX_PURE): Define.
> > > * ira-conflicts.cc (build_conflict_bit_table): Use it.  Formatting
> > > fixes.
> > > 
> > 
> > Looks good for ILP32/LLP64.
> 
> Are you planning to push yet?

It needs to be reviewed first.

Passed successfully bootstrap/regtest on x86_64-linux and i686-linux.

Note, I think incrementally we should search for similar issues,
grep -C3 '%l[duxXi]' *.cc */*.cc | grep 'long)' | grep -v long.long | wc -l
101
is an upper bound on what should be looked at, I see at least a few dozens
from those (e.g. when the argument uses sizeof, or is say hash table
size () or elements () etc.).

Also, wonder if the pretty-printer.cc should get 'z' and 't' modifiers
added, for those we clearly can use 'z' or 't' when we implement it
ourselves.  But at least that part is stage1 material I'd say.
In translated messages we certainly can't use macros like
HOST_SIZE_T_PRINT_*, because it is then untranslatable.

Jakub

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #30 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:85094e2aa6dba7908f053046f02dd443e8f65d72

commit r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
Author: Tamar Christina 
Date:   Fri Feb 2 23:52:27 2024 +

middle-end: check memory accesses in the destination block [PR113588].

When analyzing loads for early break it was always the intention that for
the
exit where things get moved to we only check the loads that can be reached
from
the condition.

However the main loop checks all loads and we skip the destination BB.  As
such
we never actually check the loads reachable from the COND in the last BB
unless
this BB was also the exit chosen by the vectorizer.

This leads us to incorrectly vectorize the loop in the PR and in doing so
access
out of bounds.

gcc/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* tree-vect-data-refs.cc
(vect_analyze_data_ref_dependence):  Choose correct dest and fix
checks.
(vect_analyze_early_break_dependences): Update comments.

gcc/testsuite/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_108-pr113588.c: New test.
* gcc.dg/vect/vect-early-break_109-pr113588.c: New test.

[Bug tree-optimization/113588] [14 Regression] The vectorizer is introducing out-of-bounds memory access

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:85094e2aa6dba7908f053046f02dd443e8f65d72

commit r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
Author: Tamar Christina 
Date:   Fri Feb 2 23:52:27 2024 +

middle-end: check memory accesses in the destination block [PR113588].

When analyzing loads for early break it was always the intention that for
the
exit where things get moved to we only check the loads that can be reached
from
the condition.

However the main loop checks all loads and we skip the destination BB.  As
such
we never actually check the loads reachable from the COND in the last BB
unless
this BB was also the exit chosen by the vectorizer.

This leads us to incorrectly vectorize the loop in the PR and in doing so
access
out of bounds.

gcc/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* tree-vect-data-refs.cc
(vect_analyze_data_ref_dependence):  Choose correct dest and fix
checks.
(vect_analyze_early_break_dependences): Update comments.

gcc/testsuite/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_108-pr113588.c: New test.
* gcc.dg/vect/vect-early-break_109-pr113588.c: New test.

[PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings

[Jonathan Yong]

Attached patch OK? Fixes the following warnings:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function 
‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ 
[-Wbuiltin-declaration-mismatch]
   17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t 
__n)
  | ^~

coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function 
‘malloc’; expected ‘void *(long long unsigned int)’ 
[-Wbuiltin-declaration-mismatch]
   25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__))
  | ^~

Copied for review convenience:
diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c 
b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
index 5684d1b02d4..dadd27eaf41 100644
--- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
+++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
@@ -1,6 +1,6 @@
 /* Reduced from coreutils's sum.c: bsd_sum_stream */
 
-typedef long unsigned int size_t;

+typedef __SIZE_TYPE__ size_t;
 typedef unsigned char __uint8_t;
 typedef unsigned long int __uintmax_t;
 typedef struct _IO_FILE FILE;From 54731e86e4bdce03ef4a722860ea8cee931ec127 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Fri, 2 Feb 2024 23:47:47 +
Subject: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes the following warnings on x86_64-w64-mingw32:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch]
   17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n)
  | ^~

coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch]
   25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__))
  | ^~

gcc/testsuite:

	* coreutils-sum-pr108666.c: Use __SIZE_TYPE__ instead of
	long unsigned int for size_t definition.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
index 5684d1b02d4..dadd27eaf41 100644
--- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
+++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
@@ -1,6 +1,6 @@
 /* Reduced from coreutils's sum.c: bsd_sum_stream */
 
-typedef long unsigned int size_t;
+typedef __SIZE_TYPE__ size_t;
 typedef unsigned char __uint8_t;
 typedef unsigned long int __uintmax_t;
 typedef struct _IO_FILE FILE;
-- 
2.43.0

[Bug target/113733] New: Invalid APX TLS code squence

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113733
   Summary: Invalid APX TLS code squence
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, hongyuw at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

Created attachment 57301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57301=edit
A testcase

[hjl@gnu-cfl-3 apx-1]$ make
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -dp -S x.c
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -dp   -c -o x.o x.c
/tmp/ccbItraT.s: Assembler messages:
/tmp/ccbItraT.s:29: Error: TLS relocation cannot be used with `add'
make: *** [: x.o] Error 1
[hjl@gnu-cfl-3 apx-1]$ 

This NDD
addq%rax, a@gottpoff(%rip), %r15

can't be used in TLS code sequence.

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

[Jonathan Yong]

On 2/1/24 15:33, Jonathan Yong wrote:

On 2/1/24 15:25, Jakub Jelinek wrote:

On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:

No, besides the formatting being incorrect both in ChangeLog and in the
patch, this pessimizes ILP32 hosts unnecessarily.


So like this instead?

2024-02-01  Jakub Jelinek  

* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
HOST_SIZE_T_PRINT_HEX_PURE): Define.
* ira-conflicts.cc (build_conflict_bit_table): Use it.  Formatting
fixes.



Looks good for ILP32/LLP64.



Are you planning to push yet?

libgo patch committed: Better error messages for unsupported target

[Ian Lance Taylor]

This libgo patch generates better error messages then the Go GOARCH
and GOOS values can't be determined from the target.  This indicates
that the target is not supported.  This is for GCC PR 113530.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
cfc6d9ae8143cf0e903384bc63e8d659ca1c9fe7
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 18281c6cd1e..429904a2b8f 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-7ab229670f7dad1d79f33929f9a4f8e6e4a71526
+8c056e335cecec67d1d223a329b7ba4dac778a65
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index c95dc2106cd..3eccadbac67 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -497,6 +497,10 @@ s-version: Makefile
 zgoarch.go: s-zgoarch; @true
 s-zgoarch: Makefile goarch.sh
rm -f zgoarch.go.tmp
+   if ! $(SHELL) $(srcdir)/goarch.sh $(GOARCH) family >/dev/null 
2>/dev/null;  then \
+ $(SHELL) $(srcdir)/goarch.sh $(GOARCH) family; \
+ exit 1; \
+   fi
echo "package goarch" > zgoarch.go.tmp
echo >> zgoarch.go.tmp
echo 'const GOARCH = "'$(GOARCH)'"' >> zgoarch.go.tmp
diff --git a/libgo/configure.ac b/libgo/configure.ac
index e8d66f8415d..22158ac7f5d 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -209,6 +209,10 @@ AM_CONDITIONAL(LIBGO_IS_BSD, test $is_darwin = yes -o 
$is_dragonfly = yes -o $is
 AC_SUBST(GOOS)
 AC_SUBST(ALLGOOS)
 
+if test "${GOOS}" = "unknown"; then
+   AC_MSG_ERROR("could not determine GOOS from ${host}")
+fi
+
 dnl Test whether we need to use DejaGNU or whether we can use the
 dnl simpler gotest approach.  We can only use gotest for a native
 dnl build.
@@ -376,6 +380,10 @@ AC_SUBST(GOARCH)
 AC_SUBST(ALLGOARCH)
 AC_SUBST(ALLGOARCHFAMILY)
 
+if test "${GOARCH}" = "unknown"; then
+   AC_MSG_ERROR("could not determine GOARCH from ${host}")
+fi
+
 AM_CONDITIONAL(LIBGO_IS_X86, test "$GOARCH" = "386" -o "$GOARCH" = "amd64" -o 
"$GOARCH" = "amd64p32")
 
 FUNCTION_DESCRIPTORS=false

[Bug go/113530] libgo ftbfs on arc-linux-gnu

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r14-8763-gcfc6d9ae8143cf0e903384bc63e8d659ca1c9fe7
Author: Ian Lance Taylor 
Date:   Mon Jan 22 17:26:23 2024 -0800

libgo: better error messages for unknown GOARCH/GOOS

PR go/113530

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/557655

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug tree-optimization/113725] [14 Regression] ICE during GIMPLE pass: cunroll

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE during GIMPLE pass: |[14 Regression] ICE during
   |cunroll |GIMPLE pass: cunroll
   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

Go patch committed: Export the type "any" as a builtin

[Ian Lance Taylor]

This patch to the Go frontend exports the type "any" as a builtin.
Otherwise we can't tell the difference between builtin type "any" and
a locally defined type "any".

This will require updates to the gccgo export data parsers in the main
Go repo and the x/tools repo.  These updates are https://go.dev/cl/537195
and https://go.dev/cl/537215.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
e52d31804a910642c9817bdd400c290a593c98ef
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index c2a6032ae80..18281c6cd1e 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-ddf3758e4a45ca2816fb68f3e4224501a3c4c438
+7ab229670f7dad1d79f33929f9a4f8e6e4a71526
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/export.cc b/gcc/go/gofrontend/export.cc
index 7373deee310..40f6d5d4b2f 100644
--- a/gcc/go/gofrontend/export.cc
+++ b/gcc/go/gofrontend/export.cc
@@ -1661,6 +1661,7 @@ Export::register_builtin_types(Gogo* gogo)
   this->register_builtin_type(gogo, "error", BUILTIN_ERROR);
   this->register_builtin_type(gogo, "byte", BUILTIN_BYTE);
   this->register_builtin_type(gogo, "rune", BUILTIN_RUNE);
+  this->register_builtin_type(gogo, "any", BUILTIN_ANY);
 }
 
 // Register one builtin type in the export table.
diff --git a/gcc/go/gofrontend/export.h b/gcc/go/gofrontend/export.h
index 1f613434cab..be117ece2ce 100644
--- a/gcc/go/gofrontend/export.h
+++ b/gcc/go/gofrontend/export.h
@@ -51,8 +51,9 @@ enum Builtin_code
   BUILTIN_ERROR = -19,
   BUILTIN_BYTE = -20,
   BUILTIN_RUNE = -21,
+  BUILTIN_ANY = -22,
 
-  SMALLEST_BUILTIN_CODE = -21
+  SMALLEST_BUILTIN_CODE = -22
 };
 
 // Export data version number. New export data is written with the
diff --git a/gcc/go/gofrontend/import.cc b/gcc/go/gofrontend/import.cc
index 21691fa5ff4..3cc8a720ee4 100644
--- a/gcc/go/gofrontend/import.cc
+++ b/gcc/go/gofrontend/import.cc
@@ -1408,6 +1408,7 @@ Import::register_builtin_types(Gogo* gogo)
   this->register_builtin_type(gogo, "error", BUILTIN_ERROR);
   this->register_builtin_type(gogo, "byte", BUILTIN_BYTE);
   this->register_builtin_type(gogo, "rune", BUILTIN_RUNE);
+  this->register_builtin_type(gogo, "any", BUILTIN_ANY);
 }
 
 // Register a single builtin type.
diff --git a/libgo/go/go/internal/gccgoimporter/parser.go 
b/libgo/go/go/internal/gccgoimporter/parser.go
index 48335fa6d8f..2161df7f368 100644
--- a/libgo/go/go/internal/gccgoimporter/parser.go
+++ b/libgo/go/go/internal/gccgoimporter/parser.go
@@ -187,7 +187,6 @@ func (p *parser) parseQualifiedNameStr(unquotedName string) 
(pkgpath, name strin
 // getPkg returns the package for a given path. If the package is
 // not found but we have a package name, create the package and
 // add it to the p.imports map.
-//
 func (p *parser) getPkg(pkgpath, name string) *types.Package {
// package unsafe is not in the imports map - handle explicitly
if pkgpath == "unsafe" {
@@ -904,6 +903,7 @@ const (
gccgoBuiltinERROR  = 19
gccgoBuiltinBYTE   = 20
gccgoBuiltinRUNE   = 21
+   gccgoBuiltinANY= 22
 )
 
 func lookupBuiltinType(typ int) types.Type {
@@ -928,13 +928,13 @@ func lookupBuiltinType(typ int) types.Type {
gccgoBuiltinERROR:  types.Universe.Lookup("error").Type(),
gccgoBuiltinBYTE:   types.Universe.Lookup("byte").Type(),
gccgoBuiltinRUNE:   types.Universe.Lookup("rune").Type(),
+   gccgoBuiltinANY:types.Universe.Lookup("any").Type(),
}[typ]
 }
 
 // Type = "<" "type" ( "-" int | int [ TypeSpec ] ) ">" .
 //
 // parseType updates the type map to t for all type numbers n.
-//
 func (p *parser) parseType(pkg *types.Package, n ...any) types.Type {
p.expect('<')
t, _ := p.parseTypeAfterAngle(pkg, n...)
@@ -1117,9 +1117,10 @@ func (p *parser) maybeCreatePackage() {
 }
 
 // InitDataDirective = ( "v1" | "v2" | "v3" ) ";" |
-// "priority" int ";" |
-// "init" { PackageInit } ";" |
-// "checksum" unquotedString ";" .
+//
+// "priority" int ";" |
+// "init" { PackageInit } ";" |
+// "checksum" unquotedString ";" .
 func (p *parser) parseInitDataDirective() {
if p.tok != scanner.Ident {
// unexpected token kind; panic
@@ -1170,15 +1171,16 @@ func (p *parser) parseInitDataDirective() {
 }
 
 // Directive = InitDataDirective |
-// "package" unquotedString [ unquotedString ] [ unquotedString ] 
";" |
-// "pkgpath" unquotedString ";" |
-// "prefix" unquotedString ";" |
-// "import" unquotedString unquotedString string ";" |
-// "indirectimport" unquotedString unquotedstring ";" |
-// "func" Func ";" |
-// "type" Type ";" |
-// "var" Var ";" |
-// "const" 

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

--- Comment #3 from Sam James  ---
I also get a new libarchive test failure with it:
```
test_read_format_rar5_extra_field_version

/var/tmp/portage/app-arch/libarchive-3.7.2/work/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:106:
bytes_read != fsize
  bytes_read=-30 (0xffe2, 0177742)
  fsize=95 (0x5f, 0137)
/var/tmp/portage/app-arch/libarchive-3.7.2/work/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:955:
Assertion failed: 0 == extract_one(a, ae, 0xF24181B7)
errno: 22
   detail: Unpacker has written too many bytes
/var/tmp/portage/app-arch/libarchive-3.7.2/work/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:111:
computed_crc != crc
  computed_crc=1827567249 (0x6cee7691, 015473473221)
  crc=4064379319 (0xf24181b7, 036220300667)
```

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
I think the issue described here are all covered by pr 63572

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

[Greg McGary]

On 2/1/24 10:24 PM, Jeff Law wrote:


On 2/1/24 18:24, Greg McGary wrote:

However, for a machine where (WORD_REGISTER_OPERATIONS && 
load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM 
is  only known at runtime as 0s or 1s. That's the downstream bug. The 
fix for such machines is either (A) forbid static evaluation of the 
high part of a PSoM, or (B) forbid transforming (SIGN_EXTEND (MEM 
...) ) into a PSoM. My patch does B. Perhaps you prefer A? The 
trouble with A is that in the zero-extend case, it is valid to 
statically evaluate as 0. It is only the sign-extend case that isn't 
known until runtime. By the time we have a PSoM, its upstream 
ancestor as sign- or zero-extend is already lost.


Does that give you the understanding you desire, or are there deeper 
mysteries to probe?
It's a good start and I can see what you're trying to do -- and it may 
in fact be correct -- the quick discussion with Palmer Tuesday and 
your follow-up have helped a lot).


But just to be sure, what's the incoming rtl at function entry? just 
"debug_rtx (x)" should be sufficient.


input: (sign_extend:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] 
) [1 minus_1+0 S4 A32]))


result: (subreg:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] 
) [1 minus_1+0 S4 A32]) 0)


Later, the high part of the PSoM statically evaluates to 0, the code to 
load and test is elided, and the incorrect alternative is emitted 
unconditionally.


G

[PATCH v5] x86-64: Find a scratch register for large model profiling

[H.J. Lu]

Changes in v5:

1. Add pr113689-3.c.
2. Use %r10 if ix86_profile_before_prologue () return true.
3. Try a callee-saved register which has been saved on stack in the
prologue.

Changes in v4:

1. Remove pr113689-3.c.
2. Use df_get_live_out.

Changes in v3:

1. Remove r10_ok.

Changes in v2:

1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.

---
2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling.  But %r10 may be used by stack realignment and we
can't use %r10 in this case.  Add x86_64_select_profile_regnum to find
a caller-saved register which isn't live or a callee-saved register
which has been saved on stack in the prologue at entry for large model
profiling and sorry if we can't find one.

gcc/

PR target/113689
* config/i386/i386.cc (set_saved_int_registers_bit): New.
(test_saved_int_registers_bit): Likewise.
(ix86_emit_save_regs): Call set_saved_int_registers_bit on
saved register.
(ix86_emit_save_regs_using_mov): Likewise.
(x86_64_select_profile_regnum): New.
(x86_function_profiler): Call x86_64_select_profile_regnum to
get a scratch register for large model profiling.
* config/i386/i386.h (machine_function): Add
saved_int_registers.

gcc/testsuite/

PR target/113689
* gcc.target/i386/pr113689-1.c: New file.
* gcc.target/i386/pr113689-2.c: Likewise.
* gcc.target/i386/pr113689-3.c: Likewise.
---
 gcc/config/i386/i386.cc| 119 ++---
 gcc/config/i386/i386.h |   5 +
 gcc/testsuite/gcc.target/i386/pr113689-1.c |  49 +
 gcc/testsuite/gcc.target/i386/pr113689-2.c |  41 +++
 gcc/testsuite/gcc.target/i386/pr113689-3.c |  48 +
 5 files changed, 247 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-3.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index b3e7c74846e..1c7aaa4535e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -7387,6 +7387,32 @@ choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned int 
*align,
   return plus_constant (Pmode, base_reg, base_offset);
 }
 
+/* Set the integer register REGNO bit in saved_int_registers.  */
+
+static void
+set_saved_int_registers_bit (int regno)
+{
+  if (LEGACY_INT_REGNO_P (regno))
+cfun->machine->saved_int_registers |= 1 << regno;
+  else
+cfun->machine->saved_int_registers
+  |= 1 << (regno - FIRST_REX_INT_REG + 8);
+}
+
+/* Return true if the integer register REGNO bit in saved_int_registers
+   is set.  */
+
+static bool
+test_saved_int_registers_bit (int regno)
+{
+  if (LEGACY_INT_REGNO_P (regno))
+return (cfun->machine->saved_int_registers
+   & (1 << regno)) != 0;
+  else
+return (cfun->machine->saved_int_registers
+   & (1 << (regno - FIRST_REX_INT_REG + 8))) != 0;
+}
+
 /* Emit code to save registers in the prologue.  */
 
 static void
@@ -7403,6 +7429,7 @@ ix86_emit_save_regs (void)
insn = emit_insn (gen_push (gen_rtx_REG (word_mode, regno),
TARGET_APX_PPX));
RTX_FRAME_RELATED_P (insn) = 1;
+   set_saved_int_registers_bit (regno);
  }
 }
   else
@@ -7415,6 +7442,7 @@ ix86_emit_save_regs (void)
   for (regno = FIRST_PSEUDO_REGISTER - 1; regno >= 0; regno--)
if (GENERAL_REGNO_P (regno) && ix86_save_reg (regno, true, true))
  {
+   set_saved_int_registers_bit (regno);
if (aligned)
  {
regno_list[loaded_regnum++] = regno;
@@ -7567,6 +7595,7 @@ ix86_emit_save_regs_using_mov (HOST_WIDE_INT cfa_offset)
   {
 ix86_emit_save_reg_using_mov (word_mode, regno, cfa_offset);
cfa_offset -= UNITS_PER_WORD;
+   set_saved_int_registers_bit (regno);
   }
 }
 
@@ -22749,6 +22778,48 @@ current_fentry_section (const char **name)
   return true;
 }
 
+/* Return a caller-saved register which isn't live or a callee-saved
+   register which has been saved on stack in the prologue at entry for
+   profile.  */
+
+static int
+x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
+{
+  /* Use %r10 if the profiler is emitted before the prologue or it isn't
+ used by DRAP.  */
+  if (ix86_profile_before_prologue ()
+  || !crtl->drap_reg
+  || REGNO (crtl->drap_reg) != R10_REG)
+return R10_REG;
+
+  /* The profiler is emitted after the prologue.  If there is a
+ caller-saved register which isn't live or a callee-saved
+ register saved on stack in the prologue, use it.  */
+
+  bitmap reg_live = df_get_live_out 

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com via Gcc-bugs]

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

--- Comment #8 from Ali Bahrami  ---
> I am not quite sure how this confuses stack unwinding on Solaris?

I don't think that most of what you described is a problem
for stack unwinding on Solaris. As discussed in the initial
note, the problem is that we use a table that maps address to
function names ("sort sections") to map virtual addresses to
symbols, and then use those symbol names for the stack
trace. The localalias, and similar, symbols that gcc is
producing make trouble for us, in a couple of ways:

(1) Since these symbols have the same addresses as the
original functions, they might show up in the stack
trace output, rather than the "real" name that the
programmer used.

(2) In the case where gcc replaces multiple identical
function bodies with one instance, the original 1:1
relationship between name and address is lost. Imagine
that my code has functions fooA() and fooB() that get
collapsed into one body, and now, both functions have
the same address. My stack traces may show one when the
programmer actually called the other.

(1) is just an annoyance. (2) is a bit more serious, since
conceptually, fooA() and fooB() really are different, and the
programmer really should see a stack that reflects what their
source code says.

As to why this is done, it's a way to get a useful
stack trace for code that has no debug sections, or
in contexts where running a debugger to get a trace
isn't possible. We put a high priority on observabilty
in contexts where debug sections are not available, or
running a debugger is not possible.

As I hope was clear in my original note, we think these gcc
optimizations are very useful for lots (maybe most) code,
but for our very simple C code base, the win is small, and
the negative aspects are a problem. It would be very useful
for us if this class of optimization could be disabled with
a simple switch.

We filed this request almost 4 years ago, and seeing that it
wasn't getting traction, I've since modified our link-editor
to drop all symbols of the form

XXX.isra.dd
XXX.localalias.dd
XXX.part.dd

from the sort sections. It's an effective hack against
problem (1) above, though not (2). It's also not how
linking ought to work: hardwiring and checking the names
of symbols produced by a specific compiler as a side effect
of optimization settings is ugly and error prone. I'd love
to rip it out if we can get back to gcc producing the 1:1
symbol to code address relationship.

Let me know if more explanation is needed. Thanks.

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

--- Comment #2 from Sam James  ---
```
char* inet_net_pton_ipv4_bits;
char inet_net_pton_ipv4_odst;
void __errno_location();
void inet_net_pton_ipv4();
void inet_net_pton() { inet_net_pton_ipv4(); }
void inet_net_pton_ipv4(char *dst, int size) {
  while ((inet_net_pton_ipv4_bits > dst) & inet_net_pton_ipv4_odst) {
if (size-- <= 0)
  goto emsgsize;
*dst++ = '\0';
  }
emsgsize:
  __errno_location();
}
```

gcc-12-20240202 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20240202 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20240202/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 28f95c81382243fc4e6f1b22741d258f5fd7541f

You'll find:

 gcc-12-20240202.tar.xz   Complete GCC

  SHA256=fde19be26aebc01f74d4b18f6ac56cd8ee09c4a61ca0dc1da8b88d0026249305
  SHA1=fcdab7bbeb3db4786a249f8b015b02abc020c86f

Diffs from 12-20240126 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug libstdc++/113732] [14 Regression] FAIL: g++.dg/modules/hello-1_b.C caused by r14-8710

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug libstdc++/113732] New: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C caused by r14-8710

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113732
   Summary: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C
caused by r14-8710
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r14-8710 caused:

FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (internal compiler error: canonical 
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
.
..> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (internal compiler error: canonical 
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
.
..> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (internal compiler error: canonical 
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
.
..> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (test for excess errors)

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

--- Comment #1 from Sam James  ---
```
$ gcc -c inet_net_pton.i -O3 -march=znver2 -wrapper valgrind
==3723094== Memcheck, a memory error detector
==3723094== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3723094== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==3723094== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/14/cc1 -fpreprocessed
inet_net_pton.i -quiet -dumpbase inet_net_pton.i -dumpbase-ext .i -march=znver2
-O3 -o /tmp/cclQ7eCN.s
==3723094==
==3723094== Invalid read of size 8
==3723094==at 0x21DDFBE: UnknownInlinedFun (gimple-iterator.h:236)
==3723094==by 0x21DDFBE: UnknownInlinedFun (tree-vect-loop.cc:11804)
==3723094==by 0x21DDFBE: vect_transform_loop(_loop_vec_info*, gimple*)
(tree-vect-loop.cc:11969)
==3723094==by 0x24647FD: vect_transform_loops(hash_table*&, loop*, gimple*, function*) [clone .lto_priv.0]
(tree-vectorizer.cc:1006)
==3723094==by 0x23D9AB1: UnknownInlinedFun (tree-vectorizer.cc:1152)
==3723094==by 0x23D9AB1: try_vectorize_loop(hash_table*&, unsigned int*, loop*, function*)
(tree-vectorizer.cc:1182)
==3723094==by 0x2112028: (anonymous
namespace)::pass_vectorize::execute(function*) [clone .lto_priv.0]
(tree-vectorizer.cc:1298)
==3723094==by 0x1B18654: execute_one_pass(opt_pass*) (passes.cc:2646)
==3723094==by 0x1BDC0EB: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==3723094==by 0x1BDC108: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==3723094==by 0x1BDC108: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==3723094==by 0x1BDBE18: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==3723094==by 0x2295983: cgraph_node::expand() (cgraphunit.cc:1843)
==3723094==by 0x1B14F13: UnknownInlinedFun (cgraphunit.cc:2026)
==3723094==by 0x1B14F13: symbol_table::compile() (cgraphunit.cc:2400)
==3723094==by 0x22A7598: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2585)
==3723094==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==3723094==
during GIMPLE pass: vect
In file included from
/var/tmp/portage/dev-libs/libbsd-0.11.8/work/libbsd-0.11.8/src/inet_net_pton.c:28:
/usr/include/arpa/inet.h: In function ‘inet_net_pton’:
/usr/include/arpa/inet.h:89:12: internal compiler error: Segmentation fault
   89 | extern int inet_net_pton (int __af, const char *__cp,
  |^
0x1262376 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/toplev.cc:317
0x21ddfbe gsi_prev(gimple_stmt_iterator*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/gimple-iterator.h:236
0x21ddfbe move_early_exit_stmts
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11804
0x21ddfbe vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11969
0x24647fd vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1006
0x23d9ab1 try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1152
0x23d9ab1 try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1182
0x2112028 execute
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1298
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 middle-end/113731] New: [14 regression] ICE when building libbsd

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

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

Bug ID: 113731
   Summary: [14 regression] ICE when building libbsd
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57300=edit
inet_net_pton.i

[This is trunk at r14-8727-gf4998609908e49 with
https://inbox.sourceware.org/gcc-patches/vi1pr08mb5325c266e259acb3b572fad6ff...@vi1pr08mb5325.eurprd08.prod.outlook.com/
applied on top. Just filing as it's easier than giving lots of diff. logs on
IRC.]

I'll try reduce it now.

```
$ gcc -c inet_net_pton.i -O3 -march=znver2
during GIMPLE pass: vect
In file included from
/var/tmp/portage/dev-libs/libbsd-0.11.8/work/libbsd-0.11.8/src/inet_net_pton.c:28:
/usr/include/arpa/inet.h: In function ‘inet_net_pton’:
/usr/include/arpa/inet.h:89:12: internal compiler error: Segmentation fault
   89 | extern int inet_net_pton (int __af, const char *__cp,
  |^
0x562c4cda2376 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/toplev.cc:317
0x562c4dd1dfbe gsi_prev(gimple_stmt_iterator*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/gimple-iterator.h:236
0x562c4dd1dfbe move_early_exit_stmts
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11804
0x562c4dd1dfbe vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11969
0x562c4dfa47fd vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1006
0x562c4df19ab1 try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1152
0x562c4df19ab1 try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1182
0x562c4dc52028 execute
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1298
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 modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #2 from Gaius Mulley  ---
Created attachment 57299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57299=edit
Proposed fix

Here is the proposed patch.

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-02

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug modula2/113730] New: Unexpected handling of mixed-precision integer arithmetic

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

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

Bug ID: 113730
   Summary: Unexpected handling of mixed-precision integer
arithmetic
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the gm2 mailing list the compiler incorrectly compiles mixed
precision arithmetic when an expression uses a ZType constant.   It would
appear that the expression is widened to a ZType which is then compatible with
another fixed sized type.

For example:

VAR
   c32: CARDINAL32 ;
   c64: CARDINAL64 ;
BEGIN
   c32 := 1 ;
   c64 := 2 ;
   c64 := c64 + c32 ;   (* Correctly: fails with incompatible expression.  *)
   c64 := c64 * 2 + c32 ;  (* Incorrectly passes!  *)

[Bug c/113727] csmith: differences from nothing to -O1

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

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

--- Comment #7 from Sam James  ---
Can you try produce a testcase without UB please?

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
As expected:

trunk.20210101 $ git bisect good 35b5bb475375dba4
6decda1a35be5764101987c210b5693a0d914e58 is the first bad commit
commit 6decda1a35be5764101987c210b5693a0d914e58
Author: Richard Biener 
Date:   Thu Oct 12 11:34:57 2023 +0200

tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA

[Bug target/113729] New: Missing APX NDD optimization

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113729
   Summary: Missing APX NDD optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, hongyuw at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

APX spec has

---
Unlike the merge-upper behavior at a destination register of a typical x86
integer instruction when OSIZE
is 8b or 16b, the NDD register is always zero-uppered
---

But GCC 14 generates:

[hjl@gnu-tgl-3 pr113711]$ cat b.c
extern unsigned char b;

unsigned int
foo (void)
{
  return 200 + b;
}
[hjl@gnu-tgl-3 pr113711]$ make b.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -S b.c
[hjl@gnu-tgl-3 pr113711]$ cat b.s
.file   "b.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl  b(%rip), %eax
addl$200, %eax
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 14.0.1 20240202 (experimental)"
.section.note.G
[hjl@gnu-tgl-3 pr113711]$

addb$200, b(%rip), %al

should be generated.

[Bug libgcc/113604] runtime SIGFPE with _BitInt() division

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Should be fixed now, thanks for the report.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
> some 155 commits.

Current range seems to be g:0f40e59f193f96f1 to g:6decda1a35be5764.

Of those 5 commits, 3 are for RISC-V and look unrelated and these two:

g:6decda1a35be5764101987c210b5693a0d914e58
g:35b5bb475375dba4ea9101d6db13a6012c4e84ca

look likely candidates, both by Richard. Adding Richard for their opinion.

My first attempt at a reduction didn't work. 
I will have another go sometime over the weekend.

[Bug sanitizer/113728] libasan uses incorrect prctl prototype

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

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

--- Comment #1 from Andrew Pinski  ---
Can you file this upstream to LLVM too?

[Bug sanitizer/113728] New: libasan uses incorrect prctl prototype

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

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

Bug ID: 113728
   Summary: libasan uses incorrect prctl prototype
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw 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
  Target Milestone: ---
Target: powerpc64le-linux-gnu

The prctl function in glibc is variadic, but the internal prototype used by
libasan has a fixed argument list.

This causes crashes on powerpc64le-linux-gnu with current glibc because the
glibc implementation is variadic as well, it uses . Older glibc uses
an assembler implementation which does not bother with variadic arguments. For
variadic function calls, it's the caller's responsibility to set up the
parameter save area, but that does not happen if function prototype is
incorrect and non-variadic.

I'll try to get this worked around in glibc, but I couldn't get my ABI
regression fix applied the first time I posted it. The libasan library isn't
the first application impacted by the prctl ABI change.

[PATCH] aarch64: Fix undefined code in vect_ctz_1.c

[Andrew Pinski]

The testcase gcc.target/aarch64/vect_ctz_1.c fails execution when running
with -march=armv9-a due to the testcase calls __builtin_ctz with a value of 0.
The testcase should not depend on undefined behavior of __builtin_ctz. So this
changes it to use the g form with the 2nd argument of 32. Now the execution part
of the testcase work. It still has a scan-assembler failure which should be 
fixed
seperately.

OK? Tested on aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/vect_ctz_1.c (TEST): Use g form of the builtin and 
pass 32
as the value expected at 0.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c 
b/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c
index c4eaf5b3a91..5fcf1e31ab2 100644
--- a/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c
@@ -9,7 +9,7 @@ count_tz_##name (unsigned *__restrict a, int *__restrict b) \
 { \
   int i; \
   for (i = 0; i < count; i++) \
-b[i] = __builtin_##subname (a[i]); \
+b[i] = __builtin_##subname##g (a[i], 32); \
 }
 
 #define CHECK(name, count, input, output) \
-- 
2.43.0

[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #6 from Iain Buclaw  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Rainer Orth  ---
> > I wonder how to handle this: while DejaGnu has an ucn effective-target 
> > keyword,
> > the gdc.test testsuite doesn't use those at all.
> 
> What I think could be done is
> 
> * Add "//UTF-8 chars" comments to testmodule.d and ufcs.d; mangle.d
>   already has one.
> 
> * Make gdc-utils.exp (gdc-convert-test) check for those annotations,
>   adding
> 
>   // { dg-require-effective-target ucn}
> 
>   if found.
> 
> The new annotations would have to go upstream, I believe.  WDYT?

Can give it a go.

https://github.com/dlang/dmd/pull/16136

[Bug libgcc/113604] runtime SIGFPE with _BitInt() division

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-8761-gfbb569315a291d2d5b32ad0fdaf0c42da9f5e93b
Author: Jakub Jelinek 
Date:   Fri Feb 2 22:14:33 2024 +0100

libgcc: Fix up _BitInt division [PR113604]

The following testcase ends up with SIGFPE in __divmodbitint4.
The problem is a thinko in my attempt to implement Knuth's algorithm.

The algorithm does (where b is 65536, i.e. one larger than what
fits in their unsigned short word):
// Compute estimate qhat of q[j].
qhat = (un[j+n]*b + un[j+n-1])/vn[n-1];
rhat = (un[j+n]*b + un[j+n-1]) - qhat*vn[n-1];
  again:
if (qhat >= b || qhat*vn[n-2] > b*rhat + un[j+n-2])
{ qhat = qhat - 1;
  rhat = rhat + vn[n-1];
  if (rhat < b) goto again;
}
The problem is that it uses a double-word / word -> double-word
division (and modulo), while all we have is udiv_qrnnd unless
we'd want to do further library calls, and udiv_qrnnd is a
double-word / word -> word division and modulo.
Now, as the algorithm description says, it can produce at most
word bits + 1 bit quotient.  And I believe that actually the
highest qhat the original algorithm can produce is
(1 << word_bits) + 1.  The algorithm performs earlier canonicalization
where both the divisor and dividend are shifted left such that divisor
has msb set.  If it has msb set already before, no shifting occurs but
we start with added 0 limb, so in the first uv1:uv0 double-word uv1
is 0 and so we can't get too high qhat, if shifting occurs, the first
limb of dividend is shifted right by UWtype bits - shift count into
a new limb, so again in the first iteration in the uv1:uv0 double-word
uv1 doesn't have msb set while vv1 does and qhat has to fit into word.
In the following iterations, previous iteration should guarantee that
the previous quotient digit is correct.  Even if the divisor was the
maximal possible vv1:all_ones_in_all_lower_limbs, if the old
uv0:lower_limbs
would be larger or equal to the divisor, the previous quotient digit
would increase and another divisor would be subtracted, which I think
implies that in the next iteration in uv1:uv0 double-word uv1 <= vv1,
but uv0 could be up to all ones, e.g. in case of all lower limbs
of divisor being all ones and at least one dividend limb below uv0
being not all ones.  So, we can e.g. for 64-bit UWtype see
uv1:uv0 / vv1 0x8000UL:0xUL /
0x8000UL
or 0xUL:0xUL / 0xUL
In all these cases (when uv1 == vv1 && uv0 >= uv1), qhat is
0x10001UL, i.e. 2 more than fits into UWtype result,
if uv1 == vv1 && uv0 < uv1 it would be 0x1UL, i.e.
1 more than fits into UWtype result.
Because we only have udiv_qrnnd which can't deal with those too large
cases (SIGFPEs or otherwise invokes undefined behavior on those), I've
tried to handle the uv1 >= vv1 case separately, but for one thing
I thought it would be at most 1 larger than what fits, and for two
have actually subtracted vv1:vv1 from uv1:uv0 instead of subtracting
0:vv1 from uv1:uv0.
For the uv1 < vv1 case, the implementation already performs roughly
what the algorithm does.
Now, let's see what happens with the two possible extra cases in
the original algorithm.
If uv1 == vv1 && uv0 < uv1, qhat above would be b, so we take
if (qhat >= b, decrement qhat by 1 (it becomes b - 1), add
vn[n-1] aka vv1 to rhat and goto again if rhat < b (but because
qhat already fits we can goto to the again label in the uv1 < vv1
code).  rhat in this case is uv0 and rhat + vv1 can but doesn't
have to overflow, say for uv0 42UL and vv1 0x8000UL
it will not (and so we should goto again), while for uv0
0x8000UL and vv1 0x8001UL it will (and
we shouldn't goto again).
If uv1 == vv1 && uv0 >= uv1, qhat above would be b + 1, so we
take if (qhat >= b, decrement qhat by 1 (it becomes b), add
vn[n-1] aka vv1 to rhat. But because vv1 has msb set and
rhat in this case is uv0 - vv1, the rhat + vv1 addition
certainly doesn't overflow, because (uv0 - vv1) + vv1 is uv0,
so in the algorithm we goto again, again take if (qhat >= b and
decrement qhat so it finally becomes b - 1, and add vn[n-1]
aka vv1 to rhat again.  But this time I believe it must always
overflow, simply because we added (uv0 - vv1) + vv1 + vv1 and
vv1 has msb set, so already vv1 + vv1 must overflow.  And
because it overflowed, it will not goto again.
So, I believe the following patch implements this correctly, by
subtracting vv1 

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to David Binderman from comment #2)
> > I have a bisection running too. I am trying out g:0f2e2080685e7509
> 
> That seems bad. Trying g:328745607c5d403a.

Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
some 155 commits.

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

[Jason Merrill]

On 2/2/24 15:57, Patrick Palka wrote:

On Fri, 2 Feb 2024, Patrick Palka wrote:


On Fri, 2 Feb 2024, Jason Merrill wrote:


On 2/2/24 14:41, Patrick Palka wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?

-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.


Actually, I don't think we want to enter the scope when rewriting constraints.
Would tsubst_scope work instead?


Oops yes, because of the maybe_dependent_member_ref stuff, the handling
for which doesn't trigger here for some reason.  Ah, I think it's
because the tf_dguide flag gets dropped during tsubst_requires_expr
since it uses tf_none rather than complain & ~tf_warning_or_error
which would preserve special tsubst flags such as tf_dguide.  I'll fix...


Like so?  Lightly tested so far, bootstrap+regtest in progress.


OK, thanks.


-- >8 --

Subject: [PATCH v2] c++: requires-exprs and partial constraint subst [PR112769]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.

In turn, tsubst_requires_expr now needs to propagate semantic tsubst flags
rather than just using tf_none, in particular for dguide constraint rewriting
which sets tf_dguide.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Likewise.  Return a substituted _REQ
node when processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
  gcc/cp/constraint.cc  | 56 +++
  gcc/cp/pt.cc  |  3 +-
  .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +
  .../g++.dg/cpp2a/concepts-friend16.C  | 25 +
  4 files changed, 84 insertions(+), 13 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..d9569013bd3 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -85,7 +85,7 @@ struct subst_info
/* True if we should not diagnose errors.  */
bool quiet() const
{
-return complain == tf_none;
+return !(complain & tf_warning_or_error);
}
  
/* True if we should diagnose errors.  */

@@ -1991,8 +1991,9 @@ hash_placeholder_constraint (tree c)
  static tree
  tsubst_valid_expression_requirement (tree t, tree args, sat_info info)
  {
-  tree r = tsubst_expr (t, args, tf_none, info.in_decl);
-  if (convert_to_void (r, ICV_STATEMENT, tf_none) != error_mark_node)
+  tsubst_flags_t quiet = info.complain & ~tf_warning_or_error;
+  tree r = tsubst_expr (t, args, quiet, info.in_decl);
+  if (convert_to_void (r, ICV_STATEMENT, quiet) != error_mark_node)
  return r;
  
if (info.diagnose_unsatisfaction_p ())

@@ -2028,6 +2029,8 @@ 

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> I have a bisection running too. I am trying out g:0f2e2080685e7509

That seems bad. Trying g:328745607c5d403a.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #8 from H.J. Lu  ---
My branch is at

https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113711/master

We need to add more tests:

1. All NDD instructions are 15 bytes or less.
2. Use "op imm, mem, reg" whenever possible.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Hongyu Wang from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Hongyu Wang from comment #4)
> > > Previously I added 
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > > h=d564198f960a2f5994dde3f6b83d7a62021e49c3
> > > 
> > > to prohibit several *POFF constant usage in NDD add alternative. If 
> > > checking
> > > ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that 
> > > change?
> > 
> > Are there are any testcases for this change?
> > 
> 
> Cut and edit from gcc.dg\torture\tls\tls-test.c
> 
> #include 
> __thread int a = 255; 
> __thread int *b;
> int *volatile a_in_other_thread = (int *) 12345;
> 
> void *
> thread_func (void *arg)
> {
>   a_in_other_thread =  //Previously it will try to generate addq
> $a@tpoff, %fs:0, %rax 
>   a+=11144; //this was not fixed on trunk as UNSPEC_TPOFF is in mem operand
>   *((int *) arg) = a;
> 
>   return (void *)0;
> }

My patch seems to work.  But we need to add such tests to gcc.target/i386.

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

[Patrick Palka]

On Fri, 2 Feb 2024, Patrick Palka wrote:

> On Fri, 2 Feb 2024, Jason Merrill wrote:
> 
> > On 2/2/24 14:41, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > look OK for trunk?
> > > 
> > > -- >8 --
> > > 
> > > In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
> > > substitute into a requires-expression so as to avoid checking its
> > > requirements out of order during e.g. generic lambda regeneration.
> > > 
> > > Unfortunately we still do need to partially substitute into a
> > > requires-expression in rare cases, in particular when it's used in
> > > associated constraints that we are directly substituting for sake of
> > > declaration matching or dguide constraint rewriting.  We can identify
> > > this situation by checking processing_constraint_expression_p, so this
> > > patch uses this predicate to control whether we defer substitution or
> > > partially substitute.  The entering_scope=true change in tsubst_baselink
> > > is needed to avoid ICEing from tsubst_baselink during name lookup when
> > > rewriting std::ranges::ref_view's dguide constraints.
> > 
> > Actually, I don't think we want to enter the scope when rewriting 
> > constraints.
> > Would tsubst_scope work instead?
> 
> Oops yes, because of the maybe_dependent_member_ref stuff, the handling
> for which doesn't trigger here for some reason.  Ah, I think it's
> because the tf_dguide flag gets dropped during tsubst_requires_expr
> since it uses tf_none rather than complain & ~tf_warning_or_error
> which would preserve special tsubst flags such as tf_dguide.  I'll fix...

Like so?  Lightly tested so far, bootstrap+regtest in progress.

-- >8 --

Subject: [PATCH v2] c++: requires-exprs and partial constraint subst [PR112769]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.

In turn, tsubst_requires_expr now needs to propagate semantic tsubst flags
rather than just using tf_none, in particular for dguide constraint rewriting
which sets tf_dguide.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Likewise.  Return a substituted _REQ
node when processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
 gcc/cp/constraint.cc  | 56 +++
 gcc/cp/pt.cc  |  3 +-
 .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +
 .../g++.dg/cpp2a/concepts-friend16.C  | 25 +
 4 files changed, 84 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..d9569013bd3 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -85,7 +85,7 @@ struct subst_info
   /* True if we should not diagnose errors.  */
   bool quiet() const
   {
-return complain == tf_none;
+return !(complain & tf_warning_or_error);
   }
 
   /* True if we should diagnose errors.  */
@@ -1991,8 +1991,9 @@ hash_placeholder_constraint (tree c)
 static tree
 tsubst_valid_expression_requirement (tree t, tree args, sat_info info)
 {
-  tree r = tsubst_expr (t, args, tf_none, info.in_decl);
-  if (convert_to_void (r, ICV_STATEMENT, tf_none) != error_mark_node)
+  tsubst_flags_t quiet = info.complain & ~tf_warning_or_error;
+  tree r = tsubst_expr (t, args, quiet, info.in_decl);
+  if (convert_to_void (r, ICV_STATEMENT, quiet) != error_mark_node)
 return r;
 
   if 

[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #11 from Iain Buclaw  ---
Mainline got this in r14-5678.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I have a bisection running too. I am trying out g:0f2e2080685e7509

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

[Patrick Palka]

On Fri, 2 Feb 2024, Jason Merrill wrote:

> On 2/2/24 14:41, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk?
> > 
> > -- >8 --
> > 
> > In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
> > substitute into a requires-expression so as to avoid checking its
> > requirements out of order during e.g. generic lambda regeneration.
> > 
> > Unfortunately we still do need to partially substitute into a
> > requires-expression in rare cases, in particular when it's used in
> > associated constraints that we are directly substituting for sake of
> > declaration matching or dguide constraint rewriting.  We can identify
> > this situation by checking processing_constraint_expression_p, so this
> > patch uses this predicate to control whether we defer substitution or
> > partially substitute.  The entering_scope=true change in tsubst_baselink
> > is needed to avoid ICEing from tsubst_baselink during name lookup when
> > rewriting std::ranges::ref_view's dguide constraints.
> 
> Actually, I don't think we want to enter the scope when rewriting constraints.
> Would tsubst_scope work instead?

Oops yes, because of the maybe_dependent_member_ref stuff, the handling
for which doesn't trigger here for some reason.  Ah, I think it's
because the tf_dguide flag gets dropped during tsubst_requires_expr
since it uses tf_none rather than complain & ~tf_warning_or_error
which would preserve special tsubst flags such as tf_dguide.  I'll fix...

> 
> Jason
> 
> 

[Bug c/113727] csmith: differences from nothing to -O1

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
With UBSAN, I get:
```
$ gcc-13 -ggdb3 -fsanitize=address,undefined /tmp/PR113727.c -o /tmp/PR113727
$ /tmp/PR113727
runData/keep/in.9954.c:416:134: runtime error: store to misaligned address
0x55a497188a23 for type 'uint32_t', which requires 4 byte alignment
0x55a497188a23: note: pointer points here
 00  a5 07 00 83 88 64 91 23  2a 00 28 bc 14 00 50 fe  ff 15 00 00 00 00 00 00 
00 00 00 00 00 00 00
  ^
#0 0x55a49716fda5 in func_46 runData/keep/in.9954.c:416
#1 0x55a49716c2fb in func_19 runData/keep/in.9954.c:352
#2 0x55a49716661e in func_1 runData/keep/in.9954.c:153
#3 0x55a49717dc21 in main runData/keep/in.9954.c:838
#4 0x7f9632452e69  (/usr/lib64/libc.so.6+0x25e69)
#5 0x7f9632452f1c in __libc_start_main (/usr/lib64/libc.so.6+0x25f1c)
#6 0x55a4971632e0 in _start (/tmp/PR113727+0x172e0)
```

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> Note I think gcc.target/aarch64/sve/mask_struct_load_3_run.c is the runtime
> failure I mentioned.

And gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c (when tested with
-march=armv9-a which I added to my testing recently).

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

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

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

--- Comment #10 from Andrew Pinski  ---
Note I think gcc.target/aarch64/sve/mask_struct_load_3_run.c is the runtime
failure I mentioned.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

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

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

--- Comment #6 from Hongyu Wang  ---
(In reply to H.J. Lu from comment #5)
> (In reply to Hongyu Wang from comment #4)
> > Previously I added 
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=d564198f960a2f5994dde3f6b83d7a62021e49c3
> > 
> > to prohibit several *POFF constant usage in NDD add alternative. If checking
> > ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that change?
> 
> Are there are any testcases for this change?
> 

Cut and edit from gcc.dg\torture\tls\tls-test.c

#include 
__thread int a = 255; 
__thread int *b;
int *volatile a_in_other_thread = (int *) 12345;

void *
thread_func (void *arg)
{
  a_in_other_thread =  //Previously it will try to generate addq $a@tpoff,
%fs:0, %rax 
  a+=11144; //this was not fixed on trunk as UNSPEC_TPOFF is in mem operand
  *((int *) arg) = a;

  return (void *)0;
}

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

[Jason Merrill]

On 2/2/24 14:41, Patrick Palka wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?

-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.


Actually, I don't think we want to enter the scope when rewriting 
constraints.  Would tsubst_scope work instead?


Jason

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

[Jason Merrill]

On 2/2/24 14:41, Patrick Palka wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?


OK.


-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (tsubst_simple_requirement): Return a
substituted _REQ node when processing_template_decl.
(tsubst_type_requirement): Likewise.
(tsubst_compound_requirement): Likewise.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution
when processing_constraint_expression_p is true, in which
case return a substituted REQUIRES_EXPR.
* pt.cc (tsubst_baselink): Use tsubst_aggr_type with
entring_scope=true instead of tsubst to substitute
qualifying_scope.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
  gcc/cp/constraint.cc  | 38 +--
  gcc/cp/pt.cc  |  3 +-
  .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +++
  .../g++.dg/cpp2a/concepts-friend16.C  | 25 
  4 files changed, 74 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..450ae548f9a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2028,6 +2028,8 @@ tsubst_simple_requirement (tree t, tree args, sat_info 
info)
tree expr = tsubst_valid_expression_requirement (t0, args, info);
if (expr == error_mark_node)
  return error_mark_node;
+  if (processing_template_decl)
+return finish_simple_requirement (EXPR_LOCATION (t), expr);
return boolean_true_node;
  }
  
@@ -2068,6 +2070,8 @@ tsubst_type_requirement (tree t, tree args, sat_info info)

tree type = tsubst_type_requirement_1 (t0, args, info, EXPR_LOCATION (t));
if (type == error_mark_node)
  return error_mark_node;
+  if (processing_template_decl)
+return finish_type_requirement (EXPR_LOCATION (t), type);
return boolean_true_node;
  }
  
@@ -2182,6 +2186,9 @@ tsubst_compound_requirement (tree t, tree args, sat_info info)

}
  }
  
+  if (processing_template_decl)

+return finish_compound_requirement (EXPR_LOCATION (t),
+   expr, type, noexcept_p);
return boolean_true_node;
  }
  
@@ -2190,6 +2197,15 @@ tsubst_compound_requirement (tree t, tree args, sat_info info)

  static tree
  tsubst_nested_requirement (tree t, tree args, sat_info info)
  {
+  if (processing_template_decl)
+{
+  tree req = TREE_OPERAND (t, 0);
+  req = tsubst_constraint (req, args, info.complain, info.in_decl);
+  if (req == error_mark_node)
+   return error_mark_node;
+  return finish_nested_requirement (EXPR_LOCATION (t), req);
+}
+
sat_info quiet (tf_none, info.in_decl);
tree result = constraint_satisfaction_value (t, args, quiet);
if (result == boolean_true_node)
@@ -2330,18 +2346,25 @@ tsubst_requires_expr (tree t, tree args, sat_info info)
  
args = add_extra_args (REQUIRES_EXPR_EXTRA_ARGS (t), args,

 info.complain, info.in_decl);
-  if (processing_template_decl)
+  if (processing_template_decl
+  && !processing_constraint_expression_p ())
  {
/* We're partially instantiating a generic lambda.  Substituting into
 this requires-expression now may cause its requirements to get
 checked out of order, so instead just remember the template
-arguments and wait until we can substitute them all at once.  */
+arguments and wait until we can substitute them all at once.
+
+Except if this requires-expr is part of associated constraints
+that we're substituting into directly (for e.g. declaration
+matching or dguide constraint rewriting), in which case we need
+to partially substitute.  */
t = copy_node (t);
REQUIRES_EXPR_EXTRA_ARGS (t) = build_extra_args 

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:28f95c81382243fc4e6f1b22741d258f5fd7541f

commit r12-10129-g28f95c81382243fc4e6f1b22741d258f5fd7541f
Author: Jason Merrill 
Date:   Fri Feb 2 12:04:11 2024 -0500

c++: op== defaulted outside class [PR110084]

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.

(cherry picked from commit e17a122d417fc0d606bcb3a3705b93ee81745cab)

[PATCH 2/2] c++: remove lookup_template_class's entering_scope flag

[Patrick Palka]

Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement?  This is not a bugfix and barely related to the previous
patch, but the previous patch's new use of entering_scope=true motivated
me to submit this patch since it seems like a nice simplification.

-- >8 --

lookup_template_class's entering_scope flag controls whether to prefer
returning the primary template type A instead of the corresponding
implicit instantiation A.  When we want to set this flag as part of
substitution, we need to use tsubst_aggr_type which also takes the flag,
but this separate entry point to substitution turned out to be subtly
problematic because it doesn't reuse typedefs like tsubst does, which
r13-4729-gbe124477b38a71 fixed in a way that respects the flag after the
fact, by adjusting the entering_scope=false result of
lookup_template_class as if entering_scope=true was passed.

But if that's possible then it means lookup_template_class's the
entering_scope flag is not necessary after all -- we can just do the
after-the-fact adjustment everywhere that we currently pass
entering_scope=true to it and tsubst_aggr_type.

To that end, this patch replaces this flag with an adjustment function
adjust_type_for_entering_scope, to be used whereever we currently need
the entering_scope=true behavior.  This means we can also get rid of
tsubst_aggr_type, since the only reason we needed this entry point
was to be able to pass entering_scope=true to lookup_template_class.

gcc/cp/ChangeLog:

* coroutines.cc (instantiate_coro_traits): Adjust call to
lookup_template_class.
(instantiate_coro_handle_for_promise_type): Likewise.
* cp-tree.h (adjust_type_for_entering_scope): Declare.
(lookup_template_class): Adjust declaration.
* decl.cc (make_typename_type): Adjust call to
lookup_template_class. Likewise.
(get_tuple_size): Likewise.
(get_tuple_element_type): Likewise.
* pt.cc (adjust_type_for_entering_scope): Define.
(lookup_template_class): Remove entering_scope parameter.
Replace tsubst_aggr_type call with tsubst followed by
adjust_type_for_entering_scope.
(tsubst_aggr_type): Remove.
(tsubst_aggr_type_1): Inline into tsubst.
(tsubst_function_decl): Replace tsubst_aggr_type call
with tsubst followed by adjust_type_for_entering_scope.
(tsubst_template_decl): Likewise.
(tsubst_decl): Likewise.
(tsubst) :
Inlined from tsubst_aggr_type_1.
: Adjust calls to
lookup_template_class.
: Replace tsubst_aggr_type call with
tsubst tsubst_scope followed by adjust_type_for_entering_scope.
: Replace tsubst_aggr_type
call with tsubst followed by adjust_type_for_entering_scope.
Increment processing_template_decl when substituting the
context.
(tsubst_baselink): Replace tsubst_aggr_type call with tsubst
followed by adjust_type_for_entering_scope.
(tsubst_expr) : Replace tsubst_aggr_type
call with tsubst followed by adjust_type_for_entering_scope.
: Likewise.
(instantiate_template): Likewise.
(resolve_typename_type): Adjust lookup_template_class call
and call adjust_type_for_entering_scope afterward.
(listify): Adjust lookup_template_class call.
(alias_ctad_tweaks): Likewise.
* semantics.cc (finish_template_type): Adjust lookup_template_class
call and maybe call adjust_type_for_entering_scope afterward.
---
 gcc/cp/coroutines.cc |   4 +-
 gcc/cp/cp-tree.h |   3 +-
 gcc/cp/decl.cc   |   4 +-
 gcc/cp/pt.cc | 212 +--
 gcc/cp/semantics.cc  |   4 +-
 5 files changed, 91 insertions(+), 136 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 3194c911e8c..8dab173d5cb 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -353,7 +353,7 @@ instantiate_coro_traits (tree fndecl, location_t kw)
   tree traits_class
 = lookup_template_class (coro_traits_templ, targ,
 /*in_decl=*/NULL_TREE, /*context=*/NULL_TREE,
-/*entering scope=*/false, tf_warning_or_error);
+tf_warning_or_error);
 
   if (traits_class == error_mark_node)
 {
@@ -400,7 +400,7 @@ instantiate_coro_handle_for_promise_type (location_t kw, 
tree promise_type)
 = lookup_template_class (coro_handle_identifier, targ,
 /* in_decl=*/NULL_TREE,
 /* context=*/std_node,
-/* entering scope=*/false, tf_warning_or_error);
+tf_warning_or_error);
 
   if (handle_type == error_mark_node)
 {
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 969c7239c97..4f73a7c84b6 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7506,8 +7506,9 @@ extern tree push_template_decl 

[PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

[Patrick Palka]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?

-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (tsubst_simple_requirement): Return a
substituted _REQ node when processing_template_decl.
(tsubst_type_requirement): Likewise.
(tsubst_compound_requirement): Likewise.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution
when processing_constraint_expression_p is true, in which
case return a substituted REQUIRES_EXPR.
* pt.cc (tsubst_baselink): Use tsubst_aggr_type with
entring_scope=true instead of tsubst to substitute
qualifying_scope.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
 gcc/cp/constraint.cc  | 38 +--
 gcc/cp/pt.cc  |  3 +-
 .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +++
 .../g++.dg/cpp2a/concepts-friend16.C  | 25 
 4 files changed, 74 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..450ae548f9a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2028,6 +2028,8 @@ tsubst_simple_requirement (tree t, tree args, sat_info 
info)
   tree expr = tsubst_valid_expression_requirement (t0, args, info);
   if (expr == error_mark_node)
 return error_mark_node;
+  if (processing_template_decl)
+return finish_simple_requirement (EXPR_LOCATION (t), expr);
   return boolean_true_node;
 }
 
@@ -2068,6 +2070,8 @@ tsubst_type_requirement (tree t, tree args, sat_info info)
   tree type = tsubst_type_requirement_1 (t0, args, info, EXPR_LOCATION (t));
   if (type == error_mark_node)
 return error_mark_node;
+  if (processing_template_decl)
+return finish_type_requirement (EXPR_LOCATION (t), type);
   return boolean_true_node;
 }
 
@@ -2182,6 +2186,9 @@ tsubst_compound_requirement (tree t, tree args, sat_info 
info)
}
 }
 
+  if (processing_template_decl)
+return finish_compound_requirement (EXPR_LOCATION (t),
+   expr, type, noexcept_p);
   return boolean_true_node;
 }
 
@@ -2190,6 +2197,15 @@ tsubst_compound_requirement (tree t, tree args, sat_info 
info)
 static tree
 tsubst_nested_requirement (tree t, tree args, sat_info info)
 {
+  if (processing_template_decl)
+{
+  tree req = TREE_OPERAND (t, 0);
+  req = tsubst_constraint (req, args, info.complain, info.in_decl);
+  if (req == error_mark_node)
+   return error_mark_node;
+  return finish_nested_requirement (EXPR_LOCATION (t), req);
+}
+
   sat_info quiet (tf_none, info.in_decl);
   tree result = constraint_satisfaction_value (t, args, quiet);
   if (result == boolean_true_node)
@@ -2330,18 +2346,25 @@ tsubst_requires_expr (tree t, tree args, sat_info info)
 
   args = add_extra_args (REQUIRES_EXPR_EXTRA_ARGS (t), args,
 info.complain, info.in_decl);
-  if (processing_template_decl)
+  if (processing_template_decl
+  && !processing_constraint_expression_p ())
 {
   /* We're partially instantiating a generic lambda.  Substituting into
 this requires-expression now may cause its requirements to get
 checked out of order, so instead just remember the template
-arguments and wait until we can substitute them all at once.  */
+arguments and wait until we can substitute them all at once.
+
+Except if this requires-expr is part of associated constraints
+that we're substituting into directly (for e.g. declaration
+matching or dguide constraint rewriting), in which case we need
+to partially substitute.  */
   t = copy_node (t);
   REQUIRES_EXPR_EXTRA_ARGS (t) = build_extra_args (t, args, info.complain);
   return t;
 }
 
-  if (tree parms = 

[Bug c/113727] New: csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113727
   Summary: csmith: differences from nothing to -O1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57298=edit
C source code

The attached C code seems to produce different answers
between no optimisation flags and -O1:

foundBugs $ ../results/bin/gcc -w bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 0
foundBugs $ ../results/bin/gcc -w -O1 bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 1
foundBugs $ diff 0 1 
469,478c469,478
< ...checksum after hashing g_994.f3 : 5F99C263
< ...checksum after hashing g_994.f4 : 6E61EEE1
< ...checksum after hashing g_994.f5 : 8A4973F3
< ...checksum after hashing g_994.f6 : 1A47F5E1
< ...checksum after hashing g_994.f7 : CD2C240E
< ...checksum after hashing g_994.f8 : 7E61A9F
< ...checksum after hashing g_1368 : 74B15A31
< ...checksum after hashing g_1659 : 322B1FCB
< ...checksum after hashing g_1720 : 65F2763C
< checksum = 65F2763C
---
> ...checksum after hashing g_994.f3 : 3D4A5D24
> ...checksum after hashing g_994.f4 : 23E1696C
> ...checksum after hashing g_994.f5 : B115BFA4
> ...checksum after hashing g_994.f6 : E3A4BBDA
> ...checksum after hashing g_994.f7 : D44B3E01
> ...checksum after hashing g_994.f8 : 656901A2
> ...checksum after hashing g_1368 : 3B45689
> ...checksum after hashing g_1659 : EBA715C1
> ...checksum after hashing g_1720 : BDD5FC31
> checksum = BDD5FC31

I have a reduction running. 

The bug first seems to occur sometime between dates 20231001 and 20231119. 
Git hashes are g:5f3da480e7541a9c and eaeaad3fcac4d7a3.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Hongyu Wang from comment #4)
> Previously I added 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=d564198f960a2f5994dde3f6b83d7a62021e49c3
> 
> to prohibit several *POFF constant usage in NDD add alternative. If checking
> ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that change?

Are there are any testcases for this change?

> And I'd suggest to use j prefix for all APX related constraints like jf.

Will do.

[Bug target/113721] [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail when calling 'free' in the target regsion

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Tobias Burnus  ---
Hmm, while I did see it on two systems, bisecting failed (always passing) and
now it passes with both the quicker build and full build.

I did not complete the bisecting as I did not see interesting commits in
between, hence, I cannot rule out that there was an in-between issue very
recently. Nor do I rule out some odd build issue.

Oddly, I had the very same issue on two system.

Anyway, close as WORKSFORME.

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:3b5d906b2de6fd28dd329b70b014ab9784b5

commit r13-8273-g3b5d906b2de6fd28dd329b70b014ab9784b5
Author: Jason Merrill 
Date:   Fri Feb 2 12:04:11 2024 -0500

c++: op== defaulted outside class [PR110084]

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.

(cherry picked from commit e17a122d417fc0d606bcb3a3705b93ee81745cab)

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com,
   ||patrick at rivosinc dot com

--- Comment #2 from Edwin Lu  ---
Also on rv32/64 linux/newlib
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/477

/disk-1/github/patrick-postcommit-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:
In function 'int main()':
/disk-1/github/patrick-postcommit-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:7:3:
internal compiler error: canonical types differ for identical types
'std::tuple_element<__i, std::tuple<_Elements ...> >' and
'std::tuple_element<__i, std::tuple<_Elements ...> >'
0xd67da3 comptypes(tree_node*, tree_node*, int)
../../../gcc/gcc/cp/typeck.cc:1710
0xd672c7 structural_comptypes
../../../gcc/gcc/cp/typeck.cc:1590
0xbad023 trees_in::is_matching_decl(tree_node*, tree_node*, bool)
../../../gcc/gcc/cp/module.cc:11362
0xbcae0b trees_in::decl_value()
../../../gcc/gcc/cp/module.cc:8341
0xbccbf7 trees_in::tree_node(bool)
../../../gcc/gcc/cp/module.cc:9403
0xbd58d3 module_state::read_cluster(unsigned int)
../../../gcc/gcc/cp/module.cc:15114
0xbd5ea3 module_state::load_section(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:18491
0xbd5f6f module_state::lazy_load(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:19166
0xbcd417 trees_in::tree_node(bool)
../../../gcc/gcc/cp/module.cc:9951
0xbd55cb module_state::read_cluster(unsigned int)
../../../gcc/gcc/cp/module.cc:15020
0xbd5ea3 module_state::load_section(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:18491
0xbd5f6f module_state::lazy_load(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:19166
0xbcd417 trees_in::tree_node(bool)
../../../gcc/gcc/cp/module.cc:9951
0xbd55cb module_state::read_cluster(unsigned int)
../../../gcc/gcc/cp/module.cc:15020
0xbd5ea3 module_state::load_section(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:18491
0xbd60d7 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../../gcc/gcc/cp/module.cc:19203
0xbed89f name_lookup::search_namespace_only(tree_node*)
../../../gcc/gcc/cp/name-lookup.cc:920
0xbef63f name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../../gcc/gcc/cp/name-lookup.cc:1143
0xbf81c7 lookup_name(tree_node*, LOOK_where, LOOK_want)
../../../gcc/gcc/cp/name-lookup.cc:7892
0xc0b0cb lookup_name(tree_node*, LOOK_want)
../../../gcc/gcc/cp/name-lookup.h:407
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.
compiler exited with status 1
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (internal compiler error: canonical
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
...> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')

Re: [PATCH v4] x86-64: Find a scratch register for large model profiling

[H.J. Lu]

On Fri, Feb 02, 2024 at 05:10:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 07:42:00AM -0800, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -22749,6 +22749,39 @@ current_fentry_section (const char **name)
> >return true;
> >  }
> >  
> > +/* Return an caller-saved register, which isn't live, at entry for
> > +   profile.  */
> > +
> > +static int
> > +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
> > +{
> > +  /* Use %r10 if it isn't used by DRAP.  */
> > +  if (!crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG)
> 
> I'd really like to see flag_fentry != 0 || here, if the profiler is
> emitted before the prologue (so before initializing the drap register),
> %r10 is a fine choice.

Fixed in v5.

> > +return R10_REG;
> > +
> > +  bitmap reg_live = df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN (cfun));
> 
> I meant at pro_and_epilogue time, but perhaps doing it here
> can discover arguments of the function which are used somewhere in
> the body too.

My patch works when an argument is unused in the function body.  The
the unused argument register will be used for profiler.  I will add
a testcase in v5 to verify it.

> 
> > +  int i;
> > +  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> > +if (GENERAL_REGNO_P (i)
> > +   && i != R10_REG
> > +#ifdef NO_PROFILE_COUNTERS
> > +   && (r11_ok || i != R11_REG)
> > +#else
> > +   && i != R11_REG
> > +#endif
> > +   && (!REX2_INT_REGNO_P (i) || TARGET_APX_EGPR)
> > +   && !fixed_regs[i]
> > +   && call_used_regs[i]
> 
> I wonder if this shouldn't be && (call_used_regs[i] || X)
> where X would cover registers known to be saved in the prologue
> which aren't live from the prologue to the body (stuff like hard frame
> pointer if used).
> Because if the prologue say saves %r12 or %rbx to stack but doesn't
> yet set it to something, why couldn't the profiler use it?
> I'd expect cfun->machine contains something what has been saved there.

Added

 /* Bit mask for integer registers saved on stack in prologue.  The
 lower 8 bits are for legacy registers and the upper 8 bits are
 for r8-r15.  */
  unsigned int saved_int_registers : 16;

to track them.

> 
> > +   && !REGNO_REG_SET_P (reg_live, i))
> > +  return i;
> > +
> > +  sorry ("no register available for profiling %<-mcmodel=large%s%>",
> > +ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
> > +
> > +  return INVALID_REGNUM;
> > +}
> > +
> >  /* Output assembler code to FILE to increment profiler label # LABELNO
> > for profiling a function entry.  */
> >  void
> > @@ -22783,42 +22816,60 @@ x86_function_profiler (FILE *file, int labelno 
> > ATTRIBUTE_UNUSED)
> > fprintf (file, "\tleaq\t%sP%d(%%rip), %%r11\n", LPREFIX, labelno);
> >  #endif
> >  
> > +  int scratch;
> > +  const char *reg_prefix;
> > +  const char *reg;
> > +
> >if (!TARGET_PECOFF)
> > {
> >   switch (ix86_cmodel)
> > {
> > case CM_LARGE:
> > - /* NB: R10 is caller-saved.  Although it can be used as a
> > -static chain register, it is preserved when calling
> > -mcount for nested functions.  */
> > + scratch = x86_64_select_profile_regnum (true);
> > + reg = hi_reg_name[scratch];
> > + reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > -   fprintf (file, "1:\tmovabs\tr10, OFFSET FLAT:%s\n"
> > -  "\tcall\tr10\n", mcount_name);
> > +   fprintf (file,
> > +"1:\tmovabs\t%s%s, OFFSET FLAT:%s\n"
> > +"\tcall\t%s%s\n",
> > +reg_prefix, reg, mcount_name, reg_prefix, reg);
> >   else
> > -   fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> > -mcount_name);
> > +   fprintf (file,
> > +"1:\tmovabsq\t$%s, %%%s%s\n\tcall\t*%%%s%s\n",
> > +mcount_name, reg_prefix, reg, reg_prefix, reg);
> >   break;
> > case CM_LARGE_PIC:
> >  #ifdef NO_PROFILE_COUNTERS
> > + scratch = x86_64_select_profile_regnum (false);
> > + reg = hi_reg_name[scratch];
> > + reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > {
> >   fprintf (file, "1:movabs\tr11, "
> >  "OFFSET FLAT:_GLOBAL_OFFSET_TABLE_-1b\n");
> > - fprintf (file, "\tlea\tr10, 1b[rip]\n");
> > - fprintf (file, "\tadd\tr10, r11\n");
> > + fprintf (file, "\tlea\t%s%s, 1b[rip]\n",
> > +  reg_prefix, reg);
> > + fprintf (file, "\tadd\t%s%s, r11\n",
> > +  reg_prefix, reg);
> >   fprintf (file, "\tmovabs\tr11, OFFSET FLAT:%s@PLTOFF\n",
> >mcount_name);
> > - fprintf (file, "\tadd\tr10, r11\n");
> > -

[Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection
  Known to fail||10.1.0, 12.1.0
  Known to work||8.1.0, 9.1.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
Summary|lto crash: when building|[11/12/13/14 Regression]
   |641.leela_s peek with   |lto crash: when building
   |Example-gcc-linux-x86.cfg   |641.leela_s peek with
   |(SPEC2017 1.1.9)|Example-gcc-linux-x86.cfg
   ||(SPEC2017 1.1.9)

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

[Bug lto/113712] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)

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

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

--- Comment #15 from Andrew Pinski  ---
Created attachment 57297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57297=edit
testcase

Compile with `-r -fprofile-generate  -O3 -flto -fno-use-linker-plugin 
-flto-partition=max`

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Jonathan Wakely]

On 02/02/24 17:59 +0100, Florian Weimer wrote:

---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)


base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify 
common issues
and provide solutions. Let us know if you have suggestions for improvements!


+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up;>
+  Function prototyping was added, first to help enforce type checking
+  on both the types of the arguments passed to the function, and also
+  to check the assignment compatibility of the function return type.
+  
+Standard C: The ANSI Draft Grows Up.
+  PC Magazine, September 13, 1988, page 117.
+  
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse.  For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only.  Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied.  Programs that bundle parts
+of https://www.gnu.org/software/gnulib/;>gnulib or
+https://www.gnu.org/software/autoconf-archive/;>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types 
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error.  For example, a flag like
+
+
+  static initialized;
+
+
+might turn into:
+
+
+  static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct.  This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list.  Using the correct
+type maybe required to avoid int-conversion errors (see below).
+In the example below, the type of s should be
+const char *, not int:
+
+
+  write_string (fd, s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+  void
+  write_string (int fd, const char *s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+Implicit function declarations 
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared.  In general, the solution is to include a header file with
+an appropriate function prototype.  Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’ 
[-Wimplicit-function-declaration]
+5 |   return strlen (s);
+  |  ^~
+note: include ‘string.h>’ or provide a declaration of ‘strlen’
+  +++ |+#include string.h>
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature 
Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as stdio.h>.
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same project are called 

[pushed] c++: op== defaulted outside class [PR110084]

[Jason Merrill]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.
---
 gcc/cp/pt.cc  |  1 +
 gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C   | 11 +++
 gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C |  2 +-
 3 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 9d30a271713..355e9609bd3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -14812,6 +14812,7 @@ tsubst_function_decl (tree t, tree args, tsubst_flags_t 
complain,
   if (DECL_SECTION_NAME (t))
 set_decl_section_name (r, t);
   if (DECL_DEFAULTED_OUTSIDE_CLASS_P (r)
+  && COMPLETE_TYPE_P (DECL_CONTEXT (r))
   && !processing_template_decl)
 defaulted_late_check (r);
 
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C
new file mode 100644
index 000..e5538ea9890
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C
@@ -0,0 +1,11 @@
+// PR c++/110084
+// { dg-do compile { target c++20 } }
+
+template 
+class BadTuple {
+  constexpr bool operator==(const BadTuple&) const;
+};
+template
+constexpr bool BadTuple::operator==(const BadTuple&) const = default;
+
+BadTuple a;
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C
index a4d8b32922f..aaa0264e7b3 100644
--- a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C
@@ -5,7 +5,7 @@ template
 struct A {};
 
 struct B {
-constexpr auto operator<=>(const B&) const = default; // { dg-error "" }
+constexpr auto operator<=>(const B&) const = default; // { dg-error 
"strong_ordering" }
 int value;
 };
 

base-commit: 1c3cfb5a95dcc7f797ec2815690a6291878580c4
-- 
2.39.3

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8759-ge17a122d417fc0d606bcb3a3705b93ee81745cab
Author: Jason Merrill 
Date:   Fri Feb 2 12:04:11 2024 -0500

c++: op== defaulted outside class [PR110084]

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

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

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

--- Comment #4 from Hongyu Wang  ---
Previously I added 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d564198f960a2f5994dde3f6b83d7a62021e49c3

to prohibit several *POFF constant usage in NDD add alternative. If checking
ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that change?

And I'd suggest to use j prefix for all APX related constraints like jf.

[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #3 from Roger Sayle  ---
Sorry for the inconvenience.  alpha.md's define_expand that creates RTL that
contains a MULT with operands of different modes looks highly suspicious. 
Uros' patch to use the (relatively recently added) UMUL_HIGHPART rtx_code is
certainly a step in the right direction.

Re: [PATCH 1/2] libdecnumber: fixed undefined behavior in `decFloatFMA`

[Ian McCormack]

I've confirmed that these changes fix the error in MIRI, too. I'll post
an updated patch once I confirm that there aren't any regressions.

On Fri, Feb 2, 2024 at 10:38 AM Jakub Jelinek  wrote:

> On Fri, Feb 02, 2024 at 04:32:09PM +0100, Jakub Jelinek wrote:
> > Anyway, I think all of
> > decBasic.c: for (; UBTOUI(umsd)==0 && umsd+3 > decBasic.c: for (; *umsd==0 && umsd > decBasic.c:  for (; UBTOUI(hi->msd)==0 && hi->msd+3lsd;) hi->msd+=4;
> > decBasic.c:  for (; *hi->msd==0 && hi->msdlsd;) hi->msd++;
> > decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
> > decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
> > decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;)
> lo->msd+=4;
> > decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
> > decCommon.c:  for (; *umsd==0 && umsd
> even more than that:
> decBasic.c:  for (; *msua==0 && msua>=lsua;) msua--;
> decBasic.c:if (*msua==0 && msua==lsua) break;
> decCommon.c:  if (*ulsd==0 && ulsd==umsd) { /* have zero */
> decNumber.c:for (; *msu1==0 && msu1>var1; msu1--) var1units--;
> too just from simple grep.
>
> Jakub
>
>

[Bug middle-end/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #25 from Patrick O'Neill  ---
Confirmed fixed. Thanks!

[committed] hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

[John David Anglin]

Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.

This is the first step in fixing PR target/59778.  libatomic/fenv.c
needs fixing for hppa so exceptions are correctly raised.

Committed to trunk.

Dave
---

hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

This change implements __builtin_get_fpsr() and __builtin_set_fpsr(x)
to get and set the floating-point status register.  They are used to
implement pa_atomic_assign_expand_fenv().

2024-02-02  John David Anglin  

gcc/ChangeLog:

PR target/59778
* config/pa/pa.cc (enum pa_builtins): Add PA_BUILTIN_GET_FPSR
and PA_BUILTIN_SET_FPSR builtins.
* (pa_builtins_icode): Declare.
* (def_builtin, pa_fpu_init_builtins): New.
* (pa_init_builtins): Initialize FPU builtins.
* (pa_builtin_decl, pa_expand_builtin_1): New.
* (pa_expand_builtin): Handle PA_BUILTIN_GET_FPSR and
PA_BUILTIN_SET_FPSR builtins.
* (pa_atomic_assign_expand_fenv): New.
* config/pa/pa.md (UNSPECV_GET_FPSR, UNSPECV_SET_FPSR): New
UNSPECV constants.
(get_fpsr, put_fpsr): New expanders.
(get_fpsr_32, get_fpsr_64, set_fpsr_32, set_fpsr_64): New
insn patterns.

diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
index c58b0a0d75e..694123e37c9 100644
--- a/gcc/config/pa/pa.cc
+++ b/gcc/config/pa/pa.cc
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "gimple.h"
 #include "df.h"
 #include "tm_p.h"
 #include "stringpool.h"
@@ -142,6 +143,7 @@ static void pa_asm_out_destructor (rtx, int);
 #endif
 static void pa_init_builtins (void);
 static rtx pa_expand_builtin (tree, rtx, rtx, machine_mode mode, int);
+static tree pa_builtin_decl (unsigned, bool);
 static rtx hppa_builtin_saveregs (void);
 static void hppa_va_start (tree, rtx);
 static tree hppa_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
@@ -205,6 +207,7 @@ static bool pa_modes_tieable_p (machine_mode, machine_mode);
 static bool pa_can_change_mode_class (machine_mode, machine_mode, reg_class_t);
 static HOST_WIDE_INT pa_starting_frame_offset (void);
 static section* pa_elf_select_rtx_section(machine_mode, rtx, unsigned 
HOST_WIDE_INT) ATTRIBUTE_UNUSED;
+static void pa_atomic_assign_expand_fenv (tree *, tree *, tree *);
 
 /* The following extra sections are only used for SOM.  */
 static GTY(()) section *som_readonly_data_section;
@@ -314,9 +317,10 @@ static size_t n_deferred_plabels = 0;
 
 #undef TARGET_INIT_BUILTINS
 #define TARGET_INIT_BUILTINS pa_init_builtins
-
 #undef TARGET_EXPAND_BUILTIN
 #define TARGET_EXPAND_BUILTIN pa_expand_builtin
+#undef  TARGET_BUILTIN_DECL
+#define TARGET_BUILTIN_DECL  pa_builtin_decl
 
 #undef TARGET_REGISTER_MOVE_COST
 #define TARGET_REGISTER_MOVE_COST hppa_register_move_cost
@@ -426,6 +430,9 @@ static size_t n_deferred_plabels = 0;
 #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
 
+#undef TARGET_ATOMIC_ASSIGN_EXPAND_FENV
+#define TARGET_ATOMIC_ASSIGN_EXPAND_FENV pa_atomic_assign_expand_fenv
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Parse the -mfixed-range= option string.  */
@@ -592,6 +599,10 @@ pa_option_override (void)
 
 enum pa_builtins
 {
+  /* FPU builtins.  */
+  PA_BUILTIN_GET_FPSR,
+  PA_BUILTIN_SET_FPSR,
+
   PA_BUILTIN_COPYSIGNQ,
   PA_BUILTIN_FABSQ,
   PA_BUILTIN_INFQ,
@@ -600,10 +611,48 @@ enum pa_builtins
 };
 
 static GTY(()) tree pa_builtins[(int) PA_BUILTIN_max];
+static GTY(()) enum insn_code pa_builtins_icode[(int) PA_BUILTIN_max];
+
+/* Add a PA  builtin function with NAME, ICODE, CODE and TYPE.  Return the
+   function decl or NULL_TREE if the builtin was not added.  */
+
+static tree
+def_builtin (const char *name, enum insn_code icode, enum pa_builtins code,
+tree type)
+{
+  tree t
+= add_builtin_function (name, type, code, BUILT_IN_MD, NULL, NULL_TREE);
+
+  if (t)
+{
+  pa_builtins[code] = t;
+  pa_builtins_icode[code] = icode;
+}
+
+  return t;
+}
+
+/* Create builtin functions for FPU instructions.  */
+
+static void
+pa_fpu_init_builtins (void)
+{
+  tree ftype;
+
+  ftype = build_function_type_list (unsigned_type_node, 0);
+  def_builtin ("__builtin_get_fpsr", CODE_FOR_get_fpsr,
+  PA_BUILTIN_GET_FPSR, ftype);
+  ftype = build_function_type_list (void_type_node, unsigned_type_node, 0);
+  def_builtin ("__builtin_set_fpsr", CODE_FOR_set_fpsr,
+  PA_BUILTIN_SET_FPSR, ftype);
+}
 
 static void
 pa_init_builtins (void)
 {
+  if (!TARGET_SOFT_FLOAT)
+pa_fpu_init_builtins ();
+
 #ifdef DONT_HAVE_FPUTC_UNLOCKED
   {
 tree decl = builtin_decl_explicit (BUILT_IN_PUTC_UNLOCKED);
@@ -663,6 +712,92 @@ pa_init_builtins (void)
 }
 }
 
+/* Implement TARGET_BUILTIN_DECL.  */
+
+static tree
+pa_builtin_decl (unsigned int code, bool initialize_p ATTRIBUTE_UNUSED)
+{
+  if (code >= PA_BUILTIN_max)
+return 

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Jonathan Wakely]

On 02/02/24 17:59 +0100, Florian Weimer wrote:

---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)


base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify 
common issues
and provide solutions. Let us know if you have suggestions for improvements!


+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up;>
+  Function prototyping was added, first to help enforce type checking
+  on both the types of the arguments passed to the function, and also
+  to check the assignment compatibility of the function return type.
+  
+Standard C: The ANSI Draft Grows Up.
+  PC Magazine, September 13, 1988, page 117.
+  
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse.  For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only.  Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied.  Programs that bundle parts
+of https://www.gnu.org/software/gnulib/;>gnulib or
+https://www.gnu.org/software/autoconf-archive/;>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types 
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error.  For example, a flag like
+
+
+  static initialized;
+
+
+might turn into:
+
+
+  static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct.  This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list.  Using the correct
+type maybe required to avoid int-conversion errors (see below).


s/maybe/may be/


+In the example below, the type of s should be
+const char *, not int:
+
+
+  write_string (fd, s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+  void
+  write_string (int fd, const char *s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+Implicit function declarations 
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared.  In general, the solution is to include a header file with
+an appropriate function prototype.  Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’ 
[-Wimplicit-function-declaration]
+5 |   return strlen (s);
+  |  ^~
+note: include ‘string.h>’ or provide a declaration of ‘strlen’
+  +++ |+#include string.h>
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature 
Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as stdio.h>.
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same 

[Bug target/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by John David Anglin :

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

commit r14-8758-g1c3cfb5a95dcc7f797ec2815690a6291878580c4
Author: John David Anglin 
Date:   Fri Feb 2 18:05:06 2024 +

hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

This change implements __builtin_get_fpsr() and __builtin_set_fpsr(x)
to get and set the floating-point status register.  They are used to
implement pa_atomic_assign_expand_fenv().

2024-02-02  John David Anglin  

gcc/ChangeLog:

PR target/59778
* config/pa/pa.cc (enum pa_builtins): Add PA_BUILTIN_GET_FPSR
and PA_BUILTIN_SET_FPSR builtins.
* (pa_builtins_icode): Declare.
* (def_builtin, pa_fpu_init_builtins): New.
* (pa_init_builtins): Initialize FPU builtins.
* (pa_builtin_decl, pa_expand_builtin_1): New.
* (pa_expand_builtin): Handle PA_BUILTIN_GET_FPSR and
PA_BUILTIN_SET_FPSR builtins.
* (pa_atomic_assign_expand_fenv): New.
* config/pa/pa.md (UNSPECV_GET_FPSR, UNSPECV_SET_FPSR): New
UNSPECV constants.
(get_fpsr, put_fpsr): New expanders.
(get_fpsr_32, get_fpsr_64, set_fpsr_32, set_fpsr_64): New
insn patterns.

[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |Concepts requirement|Concepts requirement
   |falsely reporting cyclic|falsely reporting cyclic
   |dependency, breaks  |dependency, breaks
   |tag_invoke pattern  |tag_invoke pattern

--- Comment #19 from Patrick Palka  ---
The unwanted constraint recursion should be fixed in GCC 14 for the most common
cases.

[Bug c++/112769] [11/12/13/14 Regression] ICE on valid code related to requires-expression

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=111222|
 CC||stevenxia990430 at gmail dot 
com

--- Comment #3 from Patrick Palka  ---
*** Bug 111222 has been marked as a duplicate of this bug. ***

[Bug c++/111222] ICE on basic_string_view and alias templates with missing template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=112769|
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Patrick Palka  ---
The underlying bug is the same as PR112769 which is a regression, so let's call
this one a dup.

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

[Bug c++/112769] [11/12/13/14 Regression] ICE on valid code related to requires-expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||ppalka at gcc dot gnu.org
Summary|ICE on valid code related   |[11/12/13/14 Regression]
   |to requires-expression  |ICE on valid code related
   ||to requires-expression
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-02
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101181
   Target Milestone|--- |11.5
  Known to work||11.1.0
  Known to fail||11.4.0, 12.3.0, 13.2.0,
   ||14.0

--- Comment #2 from Patrick Palka  ---
Confirmed, we started ICEing with a non-checking compiler after r12- /
r11-8734.

Re: Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer via Gcc]

* Martin Jambor:

> Given you probably have the most experience with it, can you please also
> suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
> would describe this change?  (I was thinking of proposing something
> myself, but I don't really know just how much verbose such an entry
> should be.)

Thank you for the reminder.  I veered somewhat on the verbose side and
submitted:

  [PATCH] Notes on the warnings-as-errors change in GCC 14
  


Florian

[Bug target/113697] RISC-V: Redundant vsetvl insn in function

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:922e4599e6261644d336b009b6901cd221ec95fd

commit r14-8757-g922e4599e6261644d336b009b6901cd221ec95fd
Author: Juzhe-Zhong 
Date:   Fri Feb 2 09:56:59 2024 +0800

RISC-V: Expand VLMAX scalar move in reduction

This patch fixes the following:

vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetivlizero,1,e32,m1,ta,ma
vmv.s.x v2,zero
vsetvli a5,zero,e32,m1,ta,ma  ---> Redundant vsetvl.
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret

VSETVL PASS is able to fuse avl = 1 of scalar move and VLMAX avl of
reduction.

However, this following RTL blocks the fusion in dependence analysis in
VSETVL PASS:

(insn 49 24 50 5 (set (reg:RVVM1SI 98 v2 [148])
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI [
(const_int 1 [0x1])
repeat [
(const_int 0 [0])
]
])
(const_int 1 [0x1])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(const_vector:RVVM1SI repeat [
(const_int 0 [0])
])
(unspec:RVVM1SI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) 3813 {*pred_broadcastrvvm1si_zero}
 (nil))
(insn 50 49 51 5 (set (reg:DI 15 a5 [151])  > 
It set a5, blocks the following VLMAX into the scalar move above.
(unspec:DI [
(const_int 32 [0x20])
] UNSPEC_VLMAX)) 2566 {vlmax_avldi}
 (expr_list:REG_EQUIV (unspec:DI [
(const_int 32 [0x20])
] UNSPEC_VLMAX)
(nil)))
(insn 51 50 52 5 (set (reg:RVVM1SI 97 v1 [150])
(unspec:RVVM1SI [
(unspec:RVVMF32BI [
(const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:DI 15 a5 [151])
(const_int 2 [0x2])
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(unspec:RVVM1SI [
(reg:RVVM1SI 97 v1 [orig:134 vect_result_14.6 ]
[134])
(reg:RVVM1SI 98 v2 [148])
] UNSPEC_REDUC_SUM)
(unspec:RVVM1SI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF)
] UNSPEC_REDUC)) 17541 {pred_redsumrvvm1si}
 (expr_list:REG_DEAD (reg:RVVM1SI 98 v2 [148])
(expr_list:REG_DEAD (reg:SI 66 vl)
(expr_list:REG_DEAD (reg:DI 15 a5 [151])
(expr_list:REG_DEAD (reg:DI 0 zero)
(nil))

Such situation can only happen on auto-vectorization, never happen on
intrinsic codes.
Since the reduction is passed VLMAX AVL, it should be more natural to pass
VLMAX to the scalar move which initial the value of the reduction.

After this patch:

vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetvli a5,zero,e32,m1,ta,ma
vmv.s.x v2,zero
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret

Tested on both RV32/RV64 no regression.

PR target/113697

gcc/ChangeLog:

* config/riscv/riscv-v.cc (expand_reduction): Pass VLMAX avl to
scalar move.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr113697.c: New test.

Re: GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

this is just a reminder that the organization application period of GSoC
2024 closes on Tuesday February 6th (6pm UTC).  We have already applied
but that is when we are expected to have our project idea list basically
ready.  So please review old ideas and if you have a new one and/or
would like to be a mentor, please speak up.

Thanks,

Martin


On Mon, Jan 15 2024, Martin Jambor wrote:
[...]
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

Re: GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

this is just a reminder that the organization application period of GSoC
2024 closes on Tuesday February 6th (6pm UTC).  We have already applied
but that is when we are expected to have our project idea list basically
ready.  So please review old ideas and if you have a new one and/or
would like to be a mentor, please speak up.

Thanks,

Martin


On Mon, Jan 15 2024, Martin Jambor wrote:
[...]
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken since r14-1455

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 57296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57296=edit
gcc14-pr113722.patch

Untested fix.