[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #7 from uecker at gcc dot gnu.org ---
What is strange is that not updating TYPE_CANONICAL also seems wrong even
before C23, because then it seems we should be able to get pointers with
different TYPE_CANONICAL which are compatible (to the incomplete and to the
completed struct). But apparently this never did cause problems...

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #6)
> (In reply to kargls from comment #5)
> > The pointers to expr->symtree is NULL.  This new patch catches your example.
> 
> It does, but behaves weird for some other cases.  Try:
> 
> program main
>   complex :: c = 1.
>   complex, parameter :: z = 1.
>   print *, atan(c,c)
>   print *, atan(z,z)
> end
> 
> This gives now:
> 
> pr113412.f90:4:18:
> 
> 4 |   print *, atan(c,c)
>   |  1
> Error: 'c' argument of 'atan' intrinsic at (1) must be the same type and
> kind as 'c'
> pr113412.f90:5:18:
> 
> 5 |   print *, atan(z,z)
>   |  1
> Error: 'z' argument of 'atan' intrinsic at (1) must be the same type and
> kind as 'z'
>

Looks like I'll need to look at a more robust testcase and look
at (*ap)->expr and (*ap)->next->expr to catch the individual
issues.  I won't have time to work on this for at least 2 weeks.

> I wonder whether we can reuse existing checks for atan2 for the 2-argument
> version of atan.
> 
> I tried the following:
> 
> diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
> index c35f2bdd183..261d4229139 100644
> --- a/gcc/fortran/intrinsic.cc
> +++ b/gcc/fortran/intrinsic.cc
> @@ -4370,6 +4370,11 @@ sort_actual (const char *name, gfc_actual_arglist
> **ap,
>if (a == NULL)
>  goto do_sort;
>  
> +  if ((gfc_option.allow_std & GFC_STD_F2008) != 0
> +  && strcmp(name, "atan") == 0
> +  && !gfc_check_atan_2 (actual->expr, actual->next->expr))
> +return false;
> +

I tried a similar patch in comment #2, but with (*ap)->expr
and (*ap)->next->expr.  I don't remember why this did not
work.  Perhaps, using actual->expr and actual->next->expr
sidesteps whatever I ran into.

> This is indeed sort of hackish and produces for testcase:
> 
> program main
>   complex :: c = 1.
>   print *, atan (c,c)
>   print *, atan2(c,c)
> end
> 
> pr113412.f90:3:17:
> 
> 3 |   print *, atan (c,c)
>   | 1
> Error: 'x' argument of 'atan' intrinsic at (1) must be REAL
> pr113412.f90:4:17:
> 
> 4 |   print *, atan2(c,c)
>   | 1
> Error: 'y' argument of 'atan2' intrinsic at (1) must be REAL
> 
> Note that the name of the formal argument is now wrong, probably because
> the association of actuals with formals is missing.

gfc_check_atan_2 reports errors with dummy argument names.  actual->expr
could be a literal-constant, a variable, or expression.  So a name may not
be available.

I need to look at the standard again.  For atan(x), x can be real or complex.
gfc_check_atan is invoked for this check.  For atan(y,x), x and y must be with
real, and the result is the same as atan2(y,x).  

If you want to put this aside until I can return to gfortran hacking, that
fine with me.  If you want to take a stab at refining the error messages in
sort_actual(), I'm fine with that too.

[Bug c++/33068] volatile struct bit fields not treated as volatile

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.1.0

--- Comment #3 from Andrew Pinski  ---
Looks working GCC 13:
ProcedureBitStructVolatile():
.LFB12:
.cfi_startproc
move.w BitStruct,%d0
rts

[Bug c++/25548] Rejects dependent destructor on a non dedendent name (for basic types) too late

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||
   Keywords|accepts-invalid |rejects-valid

--- Comment #2 from Andrew Pinski  ---
Hmm, EDG and MSVC accept the code for both GetChar having Foo and char as
return types. Even accepts this and runs correctly:
```
class Foo {};
Foo a;

struct Bing
{
  Foo *GetChar(){return }
};

template struct Bar
{
  void Wibble()
  {
bing.GetChar()->~T(); // How can this be legal if T isn't char?
  }
  Bing bing;
};

int main(){Bar a;a.Wibble();}
```

Also Clang has the same error message as GCC here (for `Foo*` return type
only). I am not sure if there is not a defect report in this area even.

[Bug gcov-profile/113765] [14 Regression] ICE: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Eugene Rozenfeld :

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

commit r14-9780-gfe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
Author: Eugene Rozenfeld 
Date:   Tue Mar 26 16:28:08 2024 -0700

Don't set full_profile in auto-profile [PR113765]

auto-profile currently doesn't guarantee that it will set probabilities
on all edges because of zero basic block counts. Normally those edges
just have probabilities set by the preceding profile_estimate pass but
under -O0 profile_estimate pass doesn't run. The patch removes setting
of full_profile to true in auto-profile.

Tested on x86_64-pc-linux-gnu.

gcc/ChangeLog:
PR gcov-profile/113765
* auto-profile.cc (afdo_annotate_cfg): Don't set full_profile to
true

[Bug c++/89305] CWG DR 253 is not implemented

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

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

--- Comment #2 from Andrew Pinski  ---
I should note even though the other examples of DR 253 seems to be correctly
accepting now; this one still fails.

Note also EDG rejects this even though accepting the other examples of DR 253
issues; maybe EDG and GCC implement the same rules and not the expanded rules.
Clang accepts it though.

[Bug c++/57820] [DR 253] NSDMI and const objects

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #6 from Andrew Pinski  ---
[Adopted at the November, 2016 meeting as part of paper P0490R0.]

[Bug c++/60284] [DR 253] Default-initialization without user-provided constructor allowed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #2 from Andrew Pinski  ---
>From cwg253
(https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#253):
[Adopted at the November, 2016 meeting as part of paper P0490R0.]


But I can't tell if it was a adopted as a defect report or just implemented as
part of C++17.

[Bug c++/10118] Bad diagnostic with cast in template argument expression

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

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

--- Comment #12 from Andrew Pinski  ---
Hmm, clang accepts this also for -std=c++17 (and above).
While EDG accepts this for --c++11 (and above).

Is this valid in C++11+ or C++17+ now?

[Bug target/40771] generated code is ~25% slower when autovectorization is enabled

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

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

--- Comment #4 from Andrew Pinski  ---
AARCH64 vectorization looks decent too:
```
dup v31.8h, w0
adrpx2, .LC0
adrpx0, .LC1
adrpx1, .LANCHOR0
ldr q30, [x2, #:lo12:.LC0]
ldr q29, [x0, #:lo12:.LC1]
add v30.8h, v31.8h, v30.8h
add v29.8h, v31.8h, v29.8h
uzp2v29.16b, v30.16b, v29.16b
str q29, [x1, #:lo12:.LANCHOR0]
```

The only improvement that can be made there is with SVE, those ldr could be
`index` instructions instead but that is PR 113328 .

[Bug middle-end/29231] need a way to produce trampolines not on the stack

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
Most of the support was added in r14-4821-g28d8c680aaea46 .

Maybe Iain can provide more information on what else is needed to be done if
anything.

[Bug c/28141] thread-local ptr initialized to address of thread-local misclassified as non-constant initializer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Andrew Pinski  ---
This is a won't fix as the C11's thread_local does not allow for it either.
C++'s thread_local does but that is because it allows dynamically
initialization; just like global variables in C++.

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80320
  Known to fail||

--- Comment #14 from Andrew Pinski  ---
I think this and PR 80320 both have the same underlying issue.

[Bug target/114576] [14 regression] VEX-prefixed AES instruction without AVX enabled

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #3)
> vaesenc etc. instructions can be used even if just -maes -mavx, not just
> -mvaes -mavx512vl.

Correct, that's just VEX-prefixed AESNI instructions.

VAES added the 256-bit and 512-bit versions of those instructions. The table at
felix's website is accurate: https://www.felixcloutier.com/x86/aesenc

This is actually similar to GFNI:
* GFNI: 128-bit only, non-VEX, non-EVEX
* GFNI+AVX: VEX allowed, 128- and 256-bit; no EVEX
* GFNI+AVX512F: 128- and 256-bit with VEX, 512-bit with EVEX
* GFNI+AVX512VL: 128- and 256-bit with VEX, all with EVEX
* GFNI+AVX10 without EVEX512: 128- and 256-bit with VEX and EVEX, no 512-bit

The F-no-VL case does not exist in practice.

> But, it is especially messy because -mvaes doesn't imply -maes, so IMHO if
> somebody e.g. asks for -mvaes -mavx512vl -mno-aes and the insns don't use
> any xmm16+ register, it would emit the insn using VEX encoding rather than
> EVEX, so I think we need to use {evex} prefixes.

Would it be simpler to just imply that VAES includes AESNI? There are no
processors that have VAES without AESNI and it doesn't make sense for there to
be one.

[Bug middle-end/47048] misc vect.exp failures with -fgraphite-identity enabled at -O2.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Keywords||missed-optimization
   Assignee|spop at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 CC||pinskia at gcc dot gnu.org

[Bug target/40988] incorrect code when using ..._bit macros from asm/bitops.h in a loop in userspace program

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

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

--- Comment #3 from Andrew Pinski  ---
One more note the Linux kernel sources has been corrected already.

They do now:
asm volatile(__ASM_SIZE(btr) " %2,%1"
 CC_SET(c)
 : CC_OUT(c) (oldbit)
 : ADDR, "Ir" (nr) : "memory");
return oldbit;


and 

asm volatile(__ASM_SIZE(bts) " %1,%0" : : ADDR, "Ir" (nr) : "memory");

Which describes the same thing as "+" as the memory clobber says it will update
memory too.

Linux commit 5b77e95dd7790 changed it from "+" to the above.
Linux commit 92934bcbf96bc (in 2006 which was included in 2.6.16) fixed it to
be "+" so you must have copied the linux sources from FC6 and didn't look to
see if the Linux kernel header was updated in your FC11 system.

[Bug target/114576] [14 regression]VEX-prefixed AES instruction without AVX enabled

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #2)
> Something like this should fix it (but I am not 100% sure it is correct nor
> can I test it):

This is IMHO not correct.
vaesenc etc. instructions can be used even if just -maes -mavx, not just -mvaes
-mavx512vl.
But, it is especially messy because -mvaes doesn't imply -maes, so IMHO if
somebody e.g. asks for -mvaes -mavx512vl -mno-aes and the insns don't use any
xmm16+ register, it would emit the insn using VEX encoding rather than EVEX, so
I think we need to use {evex} prefixes.

So I think we want:
--- gcc/config/i386/i386.md.jj  2024-03-18 10:33:27.983419363 +0100
+++ gcc/config/i386/i386.md 2024-04-04 00:17:48.818340648 +0200
@@ -568,13 +568,14 @@ (define_attr "unit" "integer,i387,sse,mm

 ;; Used to control the "enabled" attribute on a per-instruction basis.
 (define_attr "isa" "base,x64,nox64,x64_sse2,x64_sse4,x64_sse4_noavx,
-   x64_avx,x64_avx512bw,x64_avx512dq,aes,apx_ndd,
+   x64_avx,x64_avx512bw,x64_avx512dq,apx_ndd,
sse_noavx,sse2,sse2_noavx,sse3,sse3_noavx,sse4,sse4_noavx,
   
avx,noavx,avx2,noavx2,bmi,bmi2,fma4,fma,avx512f,avx512f_512,
noavx512f,avx512bw,avx512bw_512,noavx512bw,avx512dq,
noavx512dq,fma_or_avx512vl,avx512vl,noavx512vl,avxvnni,
avx512vnnivl,avx512fp16,avxifma,avx512ifmavl,avxneconvert,
-   avx512bf16vl,vpclmulqdqvl,avx_noavx512f,avx_noavx512vl"
+   avx512bf16vl,vpclmulqdqvl,avx_noavx512f,avx_noavx512vl,
+   aes_avx,vaes_avx512vl"
   (const_string "base"))

 ;; The (bounding maximum) length of an instruction immediate.
@@ -915,7 +916,6 @@ (define_attr "enabled" ""
   (symbol_ref "TARGET_64BIT && TARGET_AVX512BW")
 (eq_attr "isa" "x64_avx512dq")
   (symbol_ref "TARGET_64BIT && TARGET_AVX512DQ")
-(eq_attr "isa" "aes") (symbol_ref "TARGET_AES")
 (eq_attr "isa" "sse_noavx")
   (symbol_ref "TARGET_SSE && !TARGET_AVX")
 (eq_attr "isa" "sse2") (symbol_ref "TARGET_SSE2")
@@ -968,6 +968,10 @@ (define_attr "enabled" ""
   (symbol_ref "TARGET_VPCLMULQDQ && TARGET_AVX512VL")
 (eq_attr "isa" "apx_ndd")
   (symbol_ref "TARGET_APX_NDD")
+(eq_attr "isa" "aes_avx")
+  (symbol_ref "TARGET_AES && TARGET_AVX")
+(eq_attr "isa" "vaes_avx512vl")
+  (symbol_ref "TARGET_VAES && TARGET_AVX512VL")

 (eq_attr "mmx_isa" "native")
   (symbol_ref "!TARGET_MMX_WITH_SSE")
--- gcc/config/i386/sse.md.jj   2024-03-18 08:58:45.942772799 +0100
+++ gcc/config/i386/sse.md  2024-04-04 00:33:32.386194779 +0200
@@ -26277,75 +26277,79 @@ (define_insn "xop_vpermil23"
 

 (define_insn "aesenc"
-  [(set (match_operand:V2DI 0 "register_operand" "=x,x,v")
-   (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x,v")
-  (match_operand:V2DI 2 "vector_operand" "xja,xm,vm")]
+  [(set (match_operand:V2DI 0 "register_operand" "=x,x,x,v")
+   (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x,x,v")
+  (match_operand:V2DI 2 "vector_operand" "xja,xm,xm,vm")]
  UNSPEC_AESENC))]
   "TARGET_AES || (TARGET_VAES && TARGET_AVX512VL)"
   "@
aesenc\t{%2, %0|%0, %2}
vaesenc\t{%2, %1, %0|%0, %1, %2}
+   %{evex%} vaesenc\t{%2, %1, %0|%0, %1, %2}
vaesenc\t{%2, %1, %0|%0, %1, %2}"
-  [(set_attr "isa" "noavx,aes,avx512vl")
+  [(set_attr "isa" "noavx,aes_avx,vaes_avx512vl,vaes_avx512vl")
(set_attr "type" "sselog1")
-   (set_attr "addr" "gpr16,*,*")
+   (set_attr "addr" "gpr16,*,*,*")
(set_attr "prefix_extra" "1")
-   (set_attr "prefix" "orig,vex,evex")
-   (set_attr "btver2_decode" "double,double,double")
+   (set_attr "prefix" "orig,vex,evex,evex")
+   (set_attr "btver2_decode" "double,double,double,double")
(set_attr "mode" "TI")])

 (define_insn "aesenclast"
-  [(set (match_operand:V2DI 0 "register_operand" "=x,x,v")
-   (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x,v")
-  (match_operand:V2DI 2 "vector_operand" "xja,xm,vm")]
+  [(set (match_operand:V2DI 0 "register_operand" "=x,x,x,v")
+   (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x,x,v")
+  (match_operand:V2DI 2 "vector_operand" "xja,xm,xm,vm")]
  UNSPEC_AESENCLAST))]
   "TARGET_AES || (TARGET_VAES && TARGET_AVX512VL)"
   "@
aesenclast\t{%2, %0|%0, %2}
vaesenclast\t{%2, %1, %0|%0, %1, %2}
+   %{evex%} vaesenclast\t{%2, %1, %0|%0, %1, %2}

[Bug target/40988] incorrect code when using ..._bit macros from asm/bitops.h in a loop in userspace program

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
So yes I was correct in saying the inline-asm was incorrect. it should have
been:
```

__asm__ __volatile__(
"btrl %2,%1\n\tsbbl %0,%0"
:"=r" (oldbit), "+m" (ADDR)
:"Ir" (nr) : "memory");
return oldbit;
```

as this both reads and write the memory.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|willschm at gcc dot gnu.org|bergner at gcc dot 
gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2022-Septemb
   ||er/601825.html

--- Comment #17 from Peter Bergner  ---
I'm working on updating the patch Will submitted to take into consideration the
patch reviews plus trunk changes since it was submitted.  Mine now.

[Bug target/36512] relocation overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
The problem here is related to intl/libintl.a getting compiled vs having
libiconv.dylib installed.

libiconv.dylib is not normally installed on darwin either.

[Bug driver/81358] libatomic not automatically linked with C11 code

[bunk at stusta dot de via Gcc-bugs]

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

--- Comment #15 from Adrian Bunk  ---
(In reply to Tobias Burnus from comment #11)
> RFC draft patch – also to solve an offload problem with atomic and nvptx
> libgomp:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556297.html
> See reply for what still needs to be done (esp. related to building
> libraries + testsuite).

Was there any reason why this was stalled?

More and more packages in Debian need manual addition of libatomic on some
32bit vintage architectures (armv5/m68k/mips/powerpc/sh4) due to this, which is
a pain.

Is the only issue that noone has addressed the comments in the reply on the
mailing list, or have there also been other problems?

[Bug target/32775] init_machine_status doc bug

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
   Last reconfirmed|2010-02-21 00:52:44 |2024-4-3
 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
Note init_machine_status should really be a target hook rather than just some
random function pointer too.

The change in the function pointer type happened with r0-4-ge2500fedef1a1c
(aka PCH merge or rather use GC for most things).

[Bug target/34629] cexp call broken on solaris 10 32bit code with gcc and -fPIC option

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.3.0

--- Comment #4 from Andrew Pinski  ---
Fixed by r0-80529-g29173496a0453f for GCC 4.3.0 .


https://gcc.gnu.org/pipermail/gcc-patches/2007-April/214873.html . I didn't
look to see if it was backported to the 4.2.x branch though which this bug
report was reported against (a few months after the fix went into the trunk at
the time). But it has been fixed for a long time now so closing as fixed.

[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data

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

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

--- Comment #7 from Patrick Palka  ---
There's a patch pending review at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647203.html

Until that's merged, one should be able to work around this error with a trunk
compiler by using --param=ggc-min-expand=1000 (or an ever larger value) to
prevent garbage collection from occurring as often.

[Bug c/23872] .original dump weirdness

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
The  issue was fixed with r0-73077-g953ff28998b59b which was
included in GCC 4.2.0.

The DECL_EXPR issue is still there.
Currently the code is:
case DECL_EXPR:
  print_declaration (pp, DECL_EXPR_DECL (node), spc, flags);
  is_stmt = false;
  break;

I will do a patch to wrap a `DECL_EXPR < ... >` the printing so it becomes
obvious what it does.

[Bug target/86466] [X86] gcc checks the range of the immediate to _mm_blend_ps, but not _mm_blend_epi32

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid
   Last reconfirmed||2024-04-03
 Ever confirmed|0   |1

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

[Bug target/86466] [X86] gcc checks the range of the immediate to _mm_blend_ps, but not _mm_blend_epi32

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

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

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

Please next time attach or place the testcase inline instead of just linking to
godbolt, we were just lucky that the godbolt URLs are still valid after these
few years.

[Bug c++/86303] Constructor is not used for type conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Note the rule change for C++17+ is the "Prvalue semantics" (which is described
here https://en.cppreference.com/w/cpp/language/copy_elision ). In C++11 and
C++14, copy elision is not required to be done and you need to do a copy so the
code is invalid since there is a copy that needed to done but there is no way
to do a copy in this case since the "copy constructor" cannot bind a temporary.

Anyways clang accepts it for C++11 and C++14 modes is a bug there and should be
reported back to them.

Note clang/msvc does not even use:
 auto_ptr(auto_ptr_ref);
for C++11 as if I mark it as delete(d), clang accepts it still.

Which makes me suspecision of them doing the copy elision but then not also
checking if the copy would be valid. In the case of GCC there was a bug
previously where the check was not done and it was fixed and there was many
complaints in then but that was over 10 years ago.

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> The pointers to expr->symtree is NULL.  This new patch catches your example.

It does, but behaves weird for some other cases.  Try:

program main
  complex :: c = 1.
  complex, parameter :: z = 1.
  print *, atan(c,c)
  print *, atan(z,z)
end

This gives now:

pr113412.f90:4:18:

4 |   print *, atan(c,c)
  |  1
Error: 'c' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'c'
pr113412.f90:5:18:

5 |   print *, atan(z,z)
  |  1
Error: 'z' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'z'


I wonder whether we can reuse existing checks for atan2 for the 2-argument
version of atan.

I tried the following:

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..261d4229139 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4370,6 +4370,11 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
   if (a == NULL)
 goto do_sort;

+  if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+  && strcmp(name, "atan") == 0
+  && !gfc_check_atan_2 (actual->expr, actual->next->expr))
+return false;
+
 whoops:
   gfc_error ("Too many arguments in call to %qs at %L", name, where);
   return false;


This is indeed sort of hackish and produces for testcase:

program main
  complex :: c = 1.
  print *, atan (c,c)
  print *, atan2(c,c)
end

pr113412.f90:3:17:

3 |   print *, atan (c,c)
  | 1
Error: 'x' argument of 'atan' intrinsic at (1) must be REAL
pr113412.f90:4:17:

4 |   print *, atan2(c,c)
  | 1
Error: 'y' argument of 'atan2' intrinsic at (1) must be REAL


Note that the name of the formal argument is now wrong, probably because
the association of actuals with formals is missing.

[Bug target/86027] string literals get corrupted with -O3 and gas on solaris i386

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug bootstrap/84017] [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||subscribe at teskor dot de

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

[Bug target/85919] Incomplete transition to IFNs for scatter/gather support, drop vectorize.builtin_{gather,scatter} target hooks

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/85919] Incomplete transition to IFNs for scatter/gather support, drop vectorize.builtin_{gather,scatter} target hooks

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/85620] Missing ENDBR after swapcontext

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED
   Target Milestone|9.0 |13.0

--- Comment #13 from Andrew Pinski  ---
.

[Bug target/81652] [meta-bug] -fcf-protection=full bugs

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 85620, which changed state.

Bug 85620 Summary: Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug target/85236] missing _mm256_atan2_ps

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

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

--- Comment #7 from Andrew Pinski  ---
clang does not implement this intrinsics either and there is no issue filed
there about it either (I am kinda of shocked).

Note ICX (which is the new ICC but with using clang/LLVM) does and it calls
__svml_atan2f8_e9 directly.


Looks like SIMD-everywhere has implement it though, see
https://github.com/simd-everywhere/simde/issues/40

and
https://github.com/simd-everywhere/simde/commit/5b28b3d4672a9cc0616d5d6813b8e31e9bde8148

[Bug libstdc++/93672] std::basic_istream::ignore hangs if delim MSB is set

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

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

--- Comment #3 from Jonathan Wakely  ---
So maybe:

--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -112,7 +112,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 basic_istream::
 ignore(streamsize __n, int_type __delim)
 {
-  if (traits_type::eq_int_type(__delim, traits_type::eof()))
+  // If __delim is eof() we ignore up to __n chars, and for any other
+  // negative value using eq_int_type(sgetc(), __delim) will never be
true,
+  // so just treat all negative __delim values as eof().
+  if (__delim < 0)
return ignore(__n);

   _M_gcount = 0;

[Bug target/85236] missing _mm256_atan2_ps

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

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

--- Comment #6 from Andrew Pinski  ---
https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#!=undefined=SVML=_mm256_atan2_ps_expand=393

[Bug target/114577] New: Inefficient codegen for SVE/NEON bridge

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

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

Bug ID: 114577
   Summary: Inefficient codegen for SVE/NEON bridge
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

The following sequence:

#include 

svint32_t f (int *a, int *b)
{
  int32x4_t va = vld1q_s32 (a);
  svint32_t za = svset_neonq_s32 (svundef_s32 (), va);
  return za;
}

-O2 -march=armv9-a

is expected to be a simple load but generates:

f:
ldr q31, [x0]
ptrue   p3.s, vl4
sel z0.s, p3, z31.s, z0.s
ret

instead of the expected (from clang):

f:  // @f
ldr q0, [x0]
ret

it looks like GCC's implementation of svset_neonq_s32 with svundef does not
become a view_convert/subreg.

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 113363, which changed state.

Bug 113363 Summary: ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363

   What|Removed |Added

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

[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |14.0
 Status|NEW |RESOLVED

--- Comment #4 from anlauf at gcc dot gnu.org ---
This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 .

[Bug sanitizer/84210] __ubsan_handle_builtin_unreachable shoun't be const

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107300
   Last reconfirmed|2021-12-19 00:00:00 |2024-4-3

--- Comment #5 from Andrew Pinski  ---
And then there was an issue where we convert __builtin_unreachable to
__builtin_trap which had the similar issue so we added:
DEF_GCC_BUILTIN(BUILT_IN_UNREACHABLE_TRAP, "unreachable trap",
BT_FN_VOID, ATTR_CONST_NORETURN_NOTHROW_LEAF_COLD_LIST)

instead, see PR 107300 for the issue there. 

So the question becomes why was __builtin_unreachable marked as const, I have
no idea.
Anyways reconfirmed.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #6 from uecker at gcc dot gnu.org ---
Hm, this is enough:

const struct S * x;
struct S {};
void f(const struct S **);

The TYPE_CANONICAL of the pointer type depends on TYPE_CANONICAL of the target.
So it seems if I set it for completed types the new pointer get a new
TYPE_CANONICAL while old pointers to the incomplete struct are not updated
which then somehow triggers the assertion  (and is wrong).

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #11 from Nicolas Boulenguez  ---
Created attachment 57869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57869=edit
Ada: import nanosleep from System.OS_Primitives.Timed_Delay

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #10 from Nicolas Boulenguez  ---
Created attachment 57868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57868=edit
Ada: drop unneeded darwin, solaris, x32 variants of System.OS_Primitives

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #9 from Nicolas Boulenguez  ---
Created attachment 57867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57867=edit
Ada: drop unneeded posix2008 variant of System.Parameters

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #8 from Nicolas Boulenguez  ---
Created attachment 57866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57866=edit
Ada: drop unneeded x32 variant of System.Linux

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #7 from Nicolas Boulenguez  ---
Hello.

The attached suggestions (based on gcc-13/13.2.0) might solve the current
issue, or at least simplify the investigation, but they are so intrusive that I
would like a quick review by experts before testing anything.  For now, I have
not even tried a build.

In principle, is there a chance that you accept such changes upstream, once/if
they are tested in Debian?

The main suggestion is of course 'Define time_t ... in a single place'. Then,
```
diff -u --color=auto libgnarl/s-linux{,__x32}.ads
diff -u --color=auto libgnat/s-parame{,__posix2008}.ads
diff -u --color=auto libgnat/s-osprim__{unix,solaris}.adb
diff -u --color=auto libgnat/s-osprim__{rtems,darwin}.adb
diff -u --color=auto libgnat/s-osprim__{rtems,x32}.adb
```
should validate the removal and the last suggestion should be trivial.

Thanks in advance.

[Bug target/114576] [14 regression][config/i386] GCC 14/trunk emits VEX-prefixed AES instruction without AVX enabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Something like this should fix it (but I am not 100% sure it is correct nor can
I test it):
```
apinski@xeond:~/src/upstream-gcc-match/gcc/gcc/config/i386$ git diff
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 6ac401154e4..82cf92653f4 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -916,6 +916,7 @@ (define_attr "enabled" ""
 (eq_attr "isa" "x64_avx512dq")
   (symbol_ref "TARGET_64BIT && TARGET_AVX512DQ")
 (eq_attr "isa" "aes") (symbol_ref "TARGET_AES")
+(eq_attr "isa" "vaes") (symbol_ref "TARGET_VAES")
 (eq_attr "isa" "sse_noavx")
   (symbol_ref "TARGET_SSE && !TARGET_AVX")
 (eq_attr "isa" "sse2") (symbol_ref "TARGET_SSE2")
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 3286d3a4fac..af79f3b126d 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -26286,7 +26286,7 @@ (define_insn "aesenc"
aesenc\t{%2, %0|%0, %2}
vaesenc\t{%2, %1, %0|%0, %1, %2}
vaesenc\t{%2, %1, %0|%0, %1, %2}"
-  [(set_attr "isa" "noavx,aes,avx512vl")
+  [(set_attr "isa" "noavx,vaes,avx512vl")
(set_attr "type" "sselog1")
(set_attr "addr" "gpr16,*,*")
(set_attr "prefix_extra" "1")
@@ -26304,7 +26304,7 @@ (define_insn "aesenclast"
aesenclast\t{%2, %0|%0, %2}
vaesenclast\t{%2, %1, %0|%0, %1, %2}
vaesenclast\t{%2, %1, %0|%0, %1, %2}"
-  [(set_attr "isa" "noavx,aes,avx512vl")
+  [(set_attr "isa" "noavx,vaes,avx512vl")
(set_attr "type" "sselog1")
(set_attr "addr" "gpr16,*,*")
(set_attr "prefix_extra" "1")
@@ -26322,7 +26322,7 @@ (define_insn "aesdec"
aesdec\t{%2, %0|%0, %2}
vaesdec\t{%2, %1, %0|%0, %1, %2}
vaesdec\t{%2, %1, %0|%0, %1, %2}"
-  [(set_attr "isa" "noavx,aes,avx512vl")
+  [(set_attr "isa" "noavx,vaes,avx512vl")
(set_attr "type" "sselog1")
(set_attr "addr" "gpr16,*,*")
(set_attr "prefix_extra" "1")
@@ -26340,7 +26340,7 @@ (define_insn "aesdeclast"
aesdeclast\t{%2, %0|%0, %2}
vaesdeclast\t{%2, %1, %0|%0, %1, %2}
vaesdeclast\t{%2, %1, %0|%0, %1, %2}"
-  [(set_attr "isa" "noavx,aes,avx512vl")
+  [(set_attr "isa" "noavx,vaes,avx512vl")
(set_attr "addr" "gpr16,*,*")
(set_attr "type" "sselog1")
(set_attr "prefix_extra" "1")

```

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

Nicolas Boulenguez  changed:

   What|Removed |Added

 CC||nicolas at debian dot org

--- Comment #6 from Nicolas Boulenguez  ---
Created attachment 57865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57865=edit
Ada: define time_t timeval timespec C types in a single place

[Bug libstdc++/93672] std::basic_istream::ignore hangs if delim MSB is set

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

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

--- Comment #2 from Jonathan Wakely  ---
On second thoughts, I don't think that fix is right.

istream::ignore takes an int_type for the delimiter, so passing it a char_type
with a negative value will confuse it. For example, str.ignore(n, '\xff`) will
treat the delimiter as EOF and ignore up to n chars, ignoring any '\xff`
characters that might be in the stream buffer's get area. That means it's wrong
to call ignore(n, '\xff') on a platform where char is signed, because it won't
do what you expect (unless you're really intending to treat \xff as EOF).

This case is similar, it ignores up to n characters, or until sgetc() returns a
character equal to '\x80' ... but that can never happen because sgetc() never
returns a negative value unless it reaches EOF.

So there is a gcc bug here, because we should not loop forever. But the problem
is that we use inconsistent conditions for deciding whether we've found the
delimiter.

[Bug target/114576] [14 regression][config/i386] GCC 14/trunk emits VEX-prefixed AES instruction without AVX enabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13 |[14
   |regression][config/i386]|regression][config/i386]
   |GCC 14/trunk emits  |GCC 14/trunk emits
   |VEX-prefixed AES|VEX-prefixed AES
   |instruction without AVX |instruction without AVX
   |enabled |enabled
   Target Milestone|--- |14.0
   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
(define_insn "aesenc"
  [(set (match_operand:V2DI 0 "register_operand" "=x,x,v")
(unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x,v")
   (match_operand:V2DI 2 "vector_operand" "xja,xm,vm")]
  UNSPEC_AESENC))]
  "TARGET_AES || (TARGET_VAES && TARGET_AVX512VL)"
  "@
   aesenc\t{%2, %0|%0, %2}
   vaesenc\t{%2, %1, %0|%0, %1, %2}
   vaesenc\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "isa" "noavx,aes,avx512vl")
   (set_attr "type" "sselog1")
   (set_attr "addr" "gpr16,*,*")
   (set_attr "prefix_extra" "1")
   (set_attr "prefix" "orig,vex,evex")
   (set_attr "btver2_decode" "double,double,double")
   (set_attr "mode" "TI")])

r14-104-g24a8acc1662c37

Also, since -mvaes indicates that we could use VEX encoding for ymm, we
should imply AVX for VAES.

[Bug other/80719] gcc build fails on libiberty conflicting types: CP_STATIC_IF_GLIBCPP_V3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
As mentioned, combined trees of released tar balls of gcc and binutils is not
exactly supported due to the shared nature of the sources. You have to manually
make sure the sources are merged and using the newest version of each and still
compatiable with the binutils/gcc/gdb sources too.

[Bug target/114576] New: [13 regression][config/i386] GCC 14/trunk emits VEX-prefixed AES instruction without AVX enabled

[thiago at kde dot org via Gcc-bugs]

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

Bug ID: 114576
   Summary: [13 regression][config/i386] GCC 14/trunk emits
VEX-prefixed AES instruction without AVX enabled
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

Re: https://bugreports.qt.io/browse/QTBUG-123965
Re: https://bugzilla.redhat.com/show_bug.cgi?id=2262640,
https://bugzilla.redhat.com/show_bug.cgi?id=2272758
Godbolt link: https://gcc.godbolt.org/z/6P9fMvoxW

Found while compiling Qt 6.6 or 6.7 with GCC 14 (current trunk). This is a
regression from GCC 13.

This function from qhash.cpp
:

Q_ALWAYS_INLINE __m128i AESHashSeed::state1() const
{
{
// unlike the Go code, we don't have more per-process seed
__m128i state1 = _mm_aesenc_si128(state0, mseed2);
return state1;
}
}

Is apparently getting assembled to:
.L2:
leaq(%rdi,%rsi), %rdx
vaesenc %xmm1, %xmm0, %xmm1

Though there's no AVX enabled in this code (the original version in Qt has some
AVX/VAES and AVX512 code but the reduced example does not).

This function:
// hash twice 16 bytes, running 2 scramble rounds of AES on itself
static void QT_FUNCTION_TARGET(AES) QT_VECTORCALL
hash2x16bytes(__m128i , __m128i , const __m128i *src0, const
__m128i *src1)
{
__m128i data0 = _mm_loadu_si128(src0);
__m128i data1 = _mm_loadu_si128(src1);
state0 = _mm_xor_si128(data0, state0);
state1 = _mm_xor_si128(data1, state1);
state0 = _mm_aesenc_si128(state0, state0);
state1 = _mm_aesenc_si128(state1, state1);
state0 = _mm_aesenc_si128(state0, state0);
state1 = _mm_aesenc_si128(state1, state1);
}

Is even emitting:
.L20:
movdqu  (%rax), %xmm2
pxor%xmm0, %xmm2
movdqu  -16(%rdx), %xmm0
pxor%xmm0, %xmm1
vaesenc %xmm2, %xmm2, %xmm0
aesenc  %xmm1, %xmm1
aesenc  %xmm0, %xmm0
aesenc  %xmm1, %xmm1

and that makes no sense to use AVX for one of four instructions alone, called
from the same source function.

For reference, GCC 13 generates respectively:

.L2:
movdqa  %xmm0, %xmm1
leaq(%rdi,%rsi), %rdx
aesenc  %xmm2, %xmm1
and
.L20:
movdqu  (%rax), %xmm2
pxor%xmm0, %xmm2
movdqu  -16(%rdx), %xmm0
aesenc  %xmm2, %xmm2
pxor%xmm0, %xmm1
movdqa  %xmm2, %xmm0
aesenc  %xmm1, %xmm1
aesenc  %xmm2, %xmm0
aesenc  %xmm1, %xmm1

You can tell that they are the same source block because the labels are the
same.

Sources:

#include 
#ifdef _MSC_VER
#  define Q_ALWAYS_INLINE __forceinline
#  define QT_VECTORCALL __vectorcall
#  define QT_FUNCTION_TARGET(x)
#else
#  define Q_ALWAYS_INLINE inline __attribute__((always_inline))
#  define QT_VECTORCALL
#  define QT_FUNCTION_TARGET(x) __attribute__((target(QT_FUNCTION_TARGET_##x)))
#  define QT_FUNCTION_TARGET_AES"sse4.2,aes"
//#  define qCpuHasFeature(x) __builtin_cpu_supports(QT_FUNCTION_TARGET_ ## x)
#endif
#define QT_COMPILER_SUPPORTS_HERE(x)true
#define mm_set1_epz _mm_set1_epi64x
#define mm_cvtsz_si128  _mm_cvtsi64_si128
#define mm_cvtsi128_sz  _mm_cvtsi128_si64
#define mm256_set1_epz  _mm256_set1_epi64x
extern bool qCpuHasFeature(const char *) noexcept;
#define qCpuHasFeature(x) qCpuHasFeature(#x)

using uchar = unsigned char;
using quintptr = unsigned long long;
using qint8 = signed char;

// hash 16 bytes, running 3 scramble rounds of AES on itself (like label
"final1")
static void Q_ALWAYS_INLINE QT_FUNCTION_TARGET(AES) QT_VECTORCALL
hash16bytes(__m128i , __m128i data)
{
state0 = _mm_xor_si128(state0, data);
state0 = _mm_aesenc_si128(state0, state0);
state0 = _mm_aesenc_si128(state0, state0);
state0 = _mm_aesenc_si128(state0, state0);
}

// hash twice 16 bytes, running 2 scramble rounds of AES on itself
static void QT_FUNCTION_TARGET(AES) QT_VECTORCALL
hash2x16bytes(__m128i , __m128i , const __m128i *src0, const
__m128i *src1)
{
__m128i data0 = _mm_loadu_si128(src0);
__m128i data1 = _mm_loadu_si128(src1);
state0 = _mm_xor_si128(data0, state0);
state1 = _mm_xor_si128(data1, state1);
state0 = _mm_aesenc_si128(state0, state0);
state1 = _mm_aesenc_si128(state1, state1);
state0 = _mm_aesenc_si128(state0, state0);
state1 = _mm_aesenc_si128(state1, state1);
}

struct AESHashSeed
{
__m128i state0;
__m128i mseed2;
AESHashSeed(size_t seed, size_t seed2) QT_FUNCTION_TARGET(AES);
__m128i state1() const QT_FUNCTION_TARGET(AES);
  

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
I am not 100% sure but I suspect _BitInt support satisfies this request here
also.

[Bug c/79217] Feature request: high half of an integer multiplication

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> I saw a proposal for C23 (I think it was C23) for arbitrary bit size
> integers.  I don't know if that included big integers either.

It does and _BitInt(128) is supported on x86 (both 32 and 64 bit) in GCC 14.
aarch64 (Little-endian only) is adding support too and should be included in
GCC 14.

I think arm will be adding it for GCC 15 though.

I am not 100% sure but I suspect _BitInt support satisfies this request here.

[Bug target/78926] Build fails after update to GCC 6.3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #15 from Andrew Pinski  ---
We have been more careful at LTO versioning in recent versions of GCC releases.
There is not much we can do with older releases so closing as won't fix.

[Bug libstdc++/93672] std::basic_istream::ignore hangs if delim MSB is set

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Looks like I missed this one when it was filed.

The fix is:

--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -126,6 +126,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  const int_type __eof = traits_type::eof();
  __streambuf_type* __sb = this->rdbuf();
  int_type __c = __sb->sgetc();
+ __delim = traits_type::to_int_type(__cdelim);

  bool __large_ignore = false;
  while (true)

[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

Hmm,
  this seems to have worked in GCC 5 and before but I don't know if that was
due to not having checking here or not.

[Bug middle-end/107916] bigger vector_size than the target can handle causes extra load/stores inside loops

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ajidala at gmail dot com

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

[Bug middle-end/88670] [meta-bug] generic vector extension issues

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 100745, which changed state.

Bug 100745 Summary: GCC generates suboptimal assembly from vector extensions on 
AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745

   What|Removed |Added

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

[Bug tree-optimization/100745] GCC generates suboptimal assembly from vector extensions on AArch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup, yes this one is older than the dup but I feel PR 107916 has the best info
in it.

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

[Bug middle-end/88670] [meta-bug] generic vector extension issues

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 114570, which changed state.

Bug 114570 Summary: GCC doesn't perform good loop invariant code motion for 
very long vector operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114570

   What|Removed |Added

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

[Bug middle-end/107916] bigger vector_size than the target can handle causes extra load/stores inside loops

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

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

[Bug middle-end/114570] GCC doesn't perform good loop invariant code motion for very long vector operations.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup. (there might be another too).

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

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> BTW, with additional -mno-red-zone there is still movement of these insns,
> 

The problem is even bigger.  Live range splitting uses a standard insn
dependency calculation of the scheduler.  The scheduler can not recognize that
there should be dependencies between insns 60/66 and 65/71:

   60: {sp:DI=sp:DI-0x40;clobber flags:CC;} 
   65:
{r262:DI=0;r161:DI=r132:DI<<0x2+r129:DI;r162:DI=r132:DI<<0x2+r140:DI;[r129:DI]=[r140:DI];use
r132:DI;}   
   66: {sp:DI=r129:DI-0x40;clobber flags:CC;}   
   71:
{r263:DI=0;r165:DI=r132:DI<<0x2+r136:DI;r166:DI=r132:DI<<0x2+r128:DI;[r136:DI]=[r128:DI];use
r132:DI;}   

Therefore it moves insns 65 and 71 before insn 60 during live range shrinkage. 
It is wrong when there is no red zone but, even worse, split3 inserts the
following

  446: [--sp:DI]=0x10
  447: cx:DI=[sp:DI++]

between insns 65 and 71 before insn 60 which makes code wrong (rewriting memory
updated by insn 65) even if there is a red zone.

The analogous problem could occur in sched1 or/and sched2 when we don't use
live range shrinkage.

There is no way that the scheduler find and create specific deps 60->65, 66->65
(too much analysis is required to find insn 65 or 71 works with the stack)

I see two possible solutions:
  1. prohibit sched1, sched2, and live range shrinkage when accumulating args
is used
  2. create deps between any stack modification insns and memory modification
insns

The first one is easier and affects only one target (although the same problem
can be on other targets).  Still probably the same should be done for selective
scheduler.

The second one is the safest approach solving problems on all targets but may
affect performance of other targets.  The fix can require more time to
implement.

I'll think a bit about the possible fixes and inform you tomorrow.

[Bug target/114510] [14 Regression] missed proping of multiply by 2 into address of load/stores

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #3 from Tamar Christina  ---
Richard's patch should fix this next year.

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634166.html

We'll then stop relying on combine or other passes to fix this.

[Bug rtl-optimization/93565] [11/12/13 Regression] Combine duplicates instructions

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

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

--- Comment #31 from Wilco  ---
(In reply to Andrew Pinski from comment #29)
> Looking back at this one, I (In reply to Wilco from comment #8)
> > Here is a much simpler example:
> > 
> > void f (int *p, int y)
> > {
> >   int a = y & 14;
> >   *p = a | p[a];
> > }
> After r14-9692-g839bc42772ba7af66af3bd16efed4a69511312ae, we now get:
> f:
> .LFB0:
> .cfi_startproc
> and w2, w1, 14
> mov x1, x2
> ldr w2, [x0, x2, lsl 2]
> orr w1, w2, w1
> str w1, [x0]
> ret
> .cfi_endproc
> 
> There is an extra move still but the duplicated and is gone. (with
> -frename-registers added, the move is gone as REE is able to remove the zero
> extend but then there is a life range conflict so can't remove the move too).

Even with the mov it is better since that can be done with zero latency in
rename in most CPUs.

> So maybe this should be closed as fixed for GCC 14 and the cost changes for
> clz reverted.

The ctz costs are correct since it is a 2-instruction sequence - it only needs
adjusting for CSSC.

[Bug libstdc++/88607] forward_list.h contains utf-8 charactor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jonathan Wakely  ---
This was fixed for gcc 9.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #5 from Jakub Jelinek  ---
Oops, return stmt missing:
struct S foo (const struct S *);
struct S {};
struct S bar (const struct S **) { return (struct S) {}; }

[Bug rtl-optimization/114575] [14 Regression] SVE addressing modes broken since g:839bc42772ba7af66af3bd16efed4a69511312ae

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114510
   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
Definitely related to PR 114510 (but that is not caused by the combine patch as
it was happening beforehand).

There does seems like some address cost model issue here too.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #4 from Jakub Jelinek  ---
Slightly cleaned up testcase:
struct S foo (const struct S *);
struct S {};
struct S bar (const struct S **) {}

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Adjusted testcase:
namespace std {
template
constexpr T
bit_cast (const F& f) noexcept
{
  return __builtin_bit_cast (T, f);
}
}

struct A { unsigned char a : 7; };
struct B { unsigned char b; };
constexpr unsigned char c = __builtin_bit_cast (B, A{1}).b;
constexpr unsigned char d = std::bit_cast  (A{1}).b;

This shows that we diagnose correctly the c case:
pr114536.C:12:58: error: accessing uninitialized member ‘B::b’
   12 | constexpr unsigned char c = __builtin_bit_cast (B, A{1}).b;
  | ~^
but don't diagnose when the builtin call is wrapped in another call
(std::bit_cast).
The reason for that is:
  /* The result of a constexpr function must be completely initialized.

 However, in C++20, a constexpr constructor doesn't necessarily have
 to initialize all the fields, so we don't clear CONSTRUCTOR_NO_CLEARING
 in order to detect reading an unitialized object in constexpr instead
 of value-initializing it.  (reduced_constant_expression_p is expected to
 take care of clearing the flag.)  */
  if (TREE_CODE (result) == CONSTRUCTOR
  && (cxx_dialect < cxx20
  || !DECL_CONSTRUCTOR_P (fun)))
clear_no_implicit_zero (result);
hunk in cxx_eval_call_expression.

This is done there since PR80829 for the nested CONSTRUCTOR_NO_CLEARING, and on
the outermost since r7-4090-gf64e0c029c452c9fc508adebf18d0ceb3ffdc066.
If it is UB to return not completely initialized aggregate, shouldn't
clear_no_implicit_zero actually diagnose it if CONSTRUCTOR_NO_CLEARING is set
and not all ctor elements are initialized?

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
Mine.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114575

--- Comment #10 from Tamar Christina  ---
This has also broken our addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114575

[Bug rtl-optimization/114575] New: [14 Regression] SVE addressing modes broken since g:839bc42772ba7af66af3bd16efed4a69511312ae

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

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

Bug ID: 114575
   Summary: [14 Regression] SVE addressing modes broken since
g:839bc42772ba7af66af3bd16efed4a69511312ae
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

Created attachment 57864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57864=edit
addr.cc

Since the offending commit, compiling the example attached with -O3
-march=armv8.5-a+sve2 results in:

.L14:
lsl x0, x1, 1
add x1, x1, 8
add x2, x3, x0
add x6, x0, x4
ld1hz2.h, p7/z, [x2]
ld1hz22.h, p7/z, [x6]
add x0, x0, x5
fmadz22.h, p7/m, z21.h, z2.h
ld1hz20.h, p7/z, [x0]
fmadz20.h, p7/m, z26.h, z22.h
st1hz20.h, p7, [x2]
cmp x1, 808
bne .L14

instead of what it was before the commit:

.L14:
ld1hz2.h, p7/z, [x1, x0, lsl 1]
ld1hz22.h, p7/z, [x2, x0, lsl 1]
ld1hz20.h, p7/z, [x3, x0, lsl 1]
fmadz22.h, p7/m, z21.h, z2.h
fmadz20.h, p7/m, z26.h, z22.h
st1hz20.h, p7, [x1, x0, lsl 1]
add x0, x0, 8
cmp x0, 808
bne .L14

It's now no longer pushing in the register shifts. This causes significant
performance loss as it needs to now perform the integer ALU ops before doing
the load and they're on the critical path.

[Bug c++/114569] GCC accepts forming pointer to function type which is ref qualified

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jason Liam  ---
(In reply to Marek Polacek from comment #1)
> So the code should compile.

But https://timsong-cpp.github.io/cppwp/n4950/dcl.ptr#4.sentence-2 says:

> [Note 1: [...] Forming a function pointer type is ill-formed if the function 
> type has cv-qualifiers or a ref-qualifier; see [dcl.fct]. [...]]

And since `FTDecay` is `int (*)() &`, this should be ill-formed?

[Bug c++/114537] bit_cast does not work NSDMI of bitfields

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-8577-gae11f0154116f4e5fa8769b1ea1600b1b1c22958
Author: Iain Sandoe 
Date:   Thu Feb 8 17:54:31 2024 +

libstdc++, Darwin: Handle a linker warning [PR112397].

Darwin's linker warns when we make a direct branch to code that is
in a weak definition (citing that if a different implementation of
the weak function is chosen by the dynamic linker this would be an
error).

As the analysis in the PR shows, this can happen when we have hot/
cold partitioning and there is an error path that is primarily cold
but makes use of epilogue code in the hot section.  In this simple
case, we can easily deduce that the code is in fact safe; however
that is not something we can realistically implement in the linker.

Since the user-replaceable allocators are implemented using weak
definitions, this is a warning that is frequently flagged up in both
the testsuite and end-user code.

The chosen solution here is to suppress the hot/cold partitioning for
these cases (it is unlikely to impact performance much c.f. the
actual allocation).

PR target/112397

libstdc++-v3/ChangeLog:

* configure: Regenerate.
* configure.ac: Detect if we are building for Darwin.
* libsupc++/Makefile.am: If we are building for Darwin, then
suppress hot/cold partitioning for the array allocators.
* libsupc++/Makefile.in: Regenerated.

Signed-off-by: Iain Sandoe 
Co-authored-by: Jonathan Wakely 
(cherry picked from commit 1609fdff16f17ead37666f6d0e801800ee3d04d2)

[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:44514fde12e2a8f75fca88fdd6ff7a0e678ac966

commit r13-8573-g44514fde12e2a8f75fca88fdd6ff7a0e678ac966
Author: Francois-Xavier Coudert 
Date:   Mon Dec 11 09:26:23 2023 +0100

Testsuite: restrict test to nonpic targets

The test is currently failing on x86_64-apple-darwin.

gcc/testsuite/ChangeLog:

PR testsuite/112297
* gcc.target/i386/pr100936.c: Require nonpic target.

(cherry picked from commit 02f562484c17522d79a482ac702a5fa3c2dfdd10)

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #26 from Iain Sandoe  ---
NOTE: I adjusted the PR lines in the commit header so that the commits get
reflected on the PR.

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #25 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-8572-ge95ab9e60ce1d9aa7751d79291133fd5af9209d7
Author: Francois-Xavier Coudert 
Date:   Sat Mar 16 09:50:00 2024 +0100

libcc1: fix  include

Use INCLUDE_VECTOR before including system.h, instead of directly
including , to avoid running into poisoned identifiers.

Signed-off-by: Dimitry Andric 

PR middle-end/111632

libcc1/ChangeLog:

* libcc1plugin.cc: Fix include.
* libcp1plugin.cc: Fix include.

(cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #24 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:68057560ff1fc0fb2df38c2f9627a20c9a8da5c5

commit r13-8571-g68057560ff1fc0fb2df38c2f9627a20c9a8da5c5
Author: Francois-Xavier Coudert 
Date:   Thu Mar 7 14:36:03 2024 +0100

Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

When building gcc's C++ sources against recent libc++, the poisoning of
the ctype macros due to including safe-ctype.h before including C++
standard headers such as , , etc, causes many compilation
errors, similar to:

  In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
  In file included from /home/dim/src/gcc/master/gcc/system.h:233:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from
  /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from
  /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute
  only applies to structs, variables, functions, and namespaces
546 | _LIBCPP_INLINE_VISIBILITY
| ^
  /usr/include/c++/v1/__config:813:37: note: expanded from macro
  '_LIBCPP_INLINE_VISIBILITY'
813 | #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
| ^
  /usr/include/c++/v1/__config:792:26: note: expanded from macro
  '_LIBCPP_HIDE_FROM_ABI'
792 |
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(
  _LIBCPP_VERSIONED_IDENTIFIER
|  ^
  In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
  In file included from /home/dim/src/gcc/master/gcc/system.h:233:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from
  /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from
  /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of
  declaration list
547 | char_type toupper(char_type __c) const
| ^
  /usr/include/c++/v1/__locale:553:48: error: too many arguments
  provided to function-like macro invocation
553 | const char_type* toupper(char_type* __low, const
char_type* __high) const
|^
  /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note:
  macro 'toupper' defined here
146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
| ^

This is because libc++ uses different transitive includes than
libstdc++, and some of those transitive includes pull in various ctype
declarations (typically via ).

There was already a special case for including  before
safe-ctype.h, so move the rest of the C++ standard header includes to
the same location, to fix the problem.

PR middle-end/111632

gcc/ChangeLog:

* system.h: Include safe-ctype.h after C++ standard headers.

Signed-off-by: Dimitry Andric 
(cherry picked from commit 9970b576b7e4ae337af1268395ff221348c4b34a)

[Bug middle-end/114552] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[13/14 Regression] wrong|[13 Regression] wrong code
   |code at -O1 and above on|at -O1 and above on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
   |r13-990 |r13-990

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/114569] GCC accepts forming pointer to function type which is ref qualified

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
[dcl.fct]/10:
A function type with a cv-qualifier-seq or a ref-qualifier shall appear only
as: 
-- [...]
-- the type-id of a template-argument for a type-parameter

So the code should compile.

[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

[ossman at cendio dot se via Gcc-bugs]

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

--- Comment #3 from Pierre Ossman  ---
And another odd case; gcc 5 complains about this:

> const char *a;
> a = NULL;

but not:

> const char *a = NULL;

gcc 13 complains about neither, and clang about both.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|[14 regression] ICE when|[14 regression] ICE when
   |building curl with LTO  |building curl with LTO
   |(fld_incomplete_type_of, at |(fld_incomplete_type_of, at
   |ipa-free-lang-data.cc:257)  |ipa-free-lang-data.cc:257)
   ||since r14-9763
   Last reconfirmed||2024-04-03
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0
 CC||jakub at gcc dot gnu.org,
   ||uecker at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r14-9763-g871bb5ad2dd56343d80b6a6d269e85efdce5

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #15 from Jan Hubicka  ---
> Fixed for GCC 14 so far
It is simple patch, so backporting is OK after a week in mainline.

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

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

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

H.J. Lu  changed:

   What|Removed |Added

  Known to work||14.0

--- Comment #14 from H.J. Lu  ---
Fixed for GCC 14 so far

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r14-9775-gcab32bacaea268ec062b1fb4fc662d90c9d1cfce
Author: H.J. Lu 
Date:   Mon Feb 26 08:38:58 2024 -0800

tree-profile: Disable indirect call profiling for IFUNC resolvers

We can't profile indirect calls to IFUNC resolvers nor their callees as
it requires TLS which hasn't been set up yet when the dynamic linker is
resolving IFUNC symbols.

Add an IFUNC resolver caller marker to cgraph_node and set it if the
function is called by an IFUNC resolver.  Disable indirect call profiling
for IFUNC resolvers and their callees.

Tested with profiledbootstrap on Fedora 39/x86-64.

gcc/ChangeLog:

PR tree-optimization/114115
* cgraph.h (symtab_node): Add check_ifunc_callee_symtab_nodes.
(cgraph_node): Add called_by_ifunc_resolver.
* cgraphunit.cc (symbol_table::compile): Call
symtab_node::check_ifunc_callee_symtab_nodes.
* symtab.cc (check_ifunc_resolver): New.
(ifunc_ref_map): Likewise.
(is_caller_ifunc_resolver): Likewise.
(symtab_node::check_ifunc_callee_symtab_nodes): Likewise.
* tree-profile.cc (gimple_gen_ic_func_profiler): Disable indirect
call profiling for IFUNC resolvers and their callees.

gcc/testsuite/ChangeLog:

PR tree-optimization/114115
* gcc.dg/pr114115.c: New test.

[Bug other/111966] GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #7 from Tobias Burnus  ---
FIXED on mainline (= GCC 14).

Namely, the following was fixed. All of those issues involve compiling with
'-g' such that 'mkoffload' generates also a GCN .o file for which the ELF flag
has to match the other .o files.

(A) The issue of comment 0: ELF Flag mismatch if GCC was configured with a
--with-arch=... that does not match the default setting.
→ Fix: See comment 6

Earlier fixes, only vaguely related to comment 0:

(B)
* Compiler default was changed to gfx900 but mkoffload still had Fiji as
default
* Race in handling the debug files
→ Fix: See comment 1

(C)
* Fixed issues related to xnack/sram-ecc, which also lead to ELF flag
mismatches
→ Fix: See comment 4

[Bug tree-optimization/114555] ICE: definition in block 14 does not dominate use in block 15 at -O and above with _BitInt() bitfield

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

So far lightly tested patch.

[Bug c++/114573] -Wzero-as-null-pointer-constant complains on enum with explicit cast

[ossman at cendio dot se via Gcc-bugs]

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

--- Comment #2 from Pierre Ossman  ---
Indeed. It is part of an effort to have a more modern C++ style in TigerVNC.
One item was preferring nullptr over NULL, and this issue became an obstacle
there.

Right now, we did a #pragma, but if there is a better workaround, then we are
all ears.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257)

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

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

--- Comment #2 from Sam James  ---
Reduced:
```
struct X509_algor_st sk_X509_ALGOR_copyfunc(const struct X509_algor_st *);
struct X509_algor_st {
} PKCS8_pkey_get0(const struct X509_algor_st **) {
}
```

[Bug tree-optimization/114485] [13/14 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
(In reply to Robin Dapp from comment #4)
> Yes, the vectorization looks ok.  The extracted live values are not used
> afterwards and therefore the whole vectorized loop is being thrown away.
> Then we do one iteration of the epilogue loop, inverting the original c and
> end up with -8 instead of 8.  This is pretty similar to what's happening in
> the related PR.
> 
> We properly populate the phi in question in
> slpeel_update_phi_nodes_for_guard1:
> 
> c_lsm.7_64 = PHI <_56(23), pretmp_34(17)>
> 
> but vect_update_ivs_after_vectorizer changes that into
> 
> c_lsm.7_64 = PHI .
> 
> Just as a test, commenting out
> 
>   if (!LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo))
>   vect_update_ivs_after_vectorizer (loop_vinfo, niters_vector_mult_vf,
> update_e);
> 
> at least makes us keep the VEC_EXTRACT and not fail anymore.

I'll note that on x86_64 we do the same and not fail the testcase.  x86
cannot use partial vectors because we don't implement EXTRACT_LAST,
so that might be the "key" to the failure (partial vectors). And we
might need to "fail" vectorization of the special inductions when
using them?

This might be also out-of-sync handling of which ones we handle with
vect_update_ivs_after_vectorizer and which ones with
vectorizable_live_operation - as indeed we do generate the EXTRACT_LAST here.

[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524

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

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
I'll take it.

Paul

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257)

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

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

--- Comment #1 from Sam James  ---
reducing

[Bug testsuite/114568] [14 regression] g++.dg/vect/pr84556.cc fails to produce executable since r14-9706-gb8e7aaaf350a45

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

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

--- Comment #5 from Maxim Kuvyrkov  ---
Looking at this problem more, I think the issue is due to ARM target trying
hard to avoid UNSUPPORTED tests, instead of embracing them.

For the vectorization NEON check we have ...
===
proc check_effective_target_arm_neon_ok_nocache { } {
global et_arm_neon_flags
set et_arm_neon_flags ""
if { [check_effective_target_arm32] } {
foreach flags {"" "-mfloat-abi=softfp" "-mfpu=neon" "-mfpu=neon
-mfloat-abi=softfp" "-mfpu=neon -mfloat-abi=softfp -march=armv7-a"
"-mfloat-abi=hard" "-mfpu=neon -mfloat-abi=hard" "-mfpu=neon -mfloat-abi=hard
-march=armv7-a"} {
if { [check_no_compiler_messages_nocache arm_neon_ok object {
#include 
...
===
... where target tries to find a set of flags compatible with _any_ of the
built multilibs to run the testsuite.

I think this is excessive, since each multilib should be tested on its own
merits, and if armv7-m does not support vectorization, there should be no
effort to try and switch to armv7-a or armv8-m+mve multilib in order to run
vectorization tests.  In other words, vectorization tests should be marked
UNSUPPORTED in armv7-m, and PASS/FAIL in armv7-a and/or armv8-m+mve.

In practical terms, my proposed solution to this problem is to remove all
"foreach flags" options except for the default "".

ARM maintainers, what am I missing?

[Bug lto/114574] New: [14 regression] ICE when building curl with LTO (internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257)

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

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

Bug ID: 114574
   Summary: [14 regression] ICE when building curl with LTO
(internal compiler error: in fld_incomplete_type_of,
at ipa-free-lang-data.cc:257)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57861=edit
libcurl_la-curl_ntlm_core.i.xz

Tonnes of these failures. Just picked curl at random.

```
$ x86_64-pc-linux-gnu-gcc -m32 -mfpmath=sse -DHAVE_CONFIG_H
-I/var/tmp/portage/net-misc/curl-8.7.1-r1/work/curl-8.7.1/include -I../lib
-I/var/tmp/portage/net-misc/curl-8.7.1-r1/work/curl-8.7.1/lib
-DBUILDING_LIBCURL -DCURL_HIDDEN_SYMBOLS -fvisibility=hidden -O3 -pipe
-march=native -fdiagnostics-color=always -flto -fno-vect-cost-model
-fpermissive -Werror-implicit-function-declaration -c
/var/tmp/portage/net-misc/curl-8.7.1-r1/work/curl-8.7.1/lib/curl_ntlm_core.c 
-fPIC -DPIC -o .libs/libcurl_la-curl_ntlm_core.o
during IPA pass: *free_lang_data
/var/tmp/portage/net-misc/curl-8.7.1-r1/work/curl-8.7.1/lib/curl_ntlm_core.c:665:1:
internal compiler error: in fld_incomplete_type_of, at
ipa-free-lang-data.cc:257
  665 | }
  | ^
0x55f1b9e2de0f fld_incomplete_type_of
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:257
0x55f1bb41a2ad fld_simplified_type
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:344
0x55f1bb41a2ad free_lang_data_in_type
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:439
0x55f1bbaa5ad0 free_lang_data_in_cgraph
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:1072
0x55f1bbaa5ad0 free_lang_data
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:1109
0x55f1bbaa5ad0 execute
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

'gcc -c libcurl_la-curl_ntlm_core.i -O2 -flto' is enough to reproduce. I last
built curl fine on 30th March, apparently.

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0./work/gcc-14.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0. p,
commit 7bbfb01a32b73842f8908de028703510a0e12057' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240403 (experimental)
8455d6f6cd43b7b143ab9ee19437452fceba9cc9 (Gentoo 14.0. p, commit
7bbfb01a32b73842f8908de028703510a0e12057)
```

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
It can be reproduced with -O2 -funswitch-loops -fsplit-loops.

Loop splitting emits

   [local count: 14598063]:
  a.0_1 = a;
  _2 = a.0_1 + -1;
  a = _2;
  _24 = _2 <= 0;
  _10 = 2147483647 - _2;
  if (_10 <= 2)

and the 2147483647 - _2 expression then overflows, so that's definitely
wrong.  This is built here:

/* Build a condition that will skip the first loop when the
   guard condition won't ever be true (or false).  */
gimple_seq stmts2;
border = force_gimple_operand (border, , true, NULL_TREE);
if (stmts2)  

or rather in split_at_bb_p and put into '*border'