[Bug tree-optimization/102435] gcc 9: aarch64 -ftree-loop-vectorize results in wrong code

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail|9.4.1   |9.3.0
  Known to work||8.5.0, 9.4.0, 9.5.0

--- Comment #1 from Andrew Pinski  ---
So I can reproduce it with GCC 9.3.0 but not with GCC 9.4.0. It also works with
GCC 9.5.0

[Bug middle-end/99689] Initialized local variable becomes uninitialized after use

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Target Milestone|--- |9.4
 Resolution|--- |FIXED
   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=102435|a/show_bug.cgi?id=97236

--- Comment #8 from Andrew Pinski  ---
Fixed in GCC 9.4.0. Most likely a dup of bug 97236.

[Bug debug/78685] -Og generates too many ""s

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lukas.graetz@tu-darmstadt.d
   ||e

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

[Bug debug/114144] Variables optimized out by -Og

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Yep this is a dup of bug 78685.

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

[Bug tree-optimization/112325] Missed vectorization of reduction after unrolling

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

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

--- Comment #14 from Hongtao Liu  ---
(In reply to rguent...@suse.de from comment #13)
> On Tue, 27 Feb 2024, liuhongt at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
> > 
> > --- Comment #11 from Hongtao Liu  ---
> > 
> > >Loop body is likely going to simplify further, this is difficult
> > >to guess, we just decrease the result by 1/3.  */
> > > 
> > 
> > This is introduced by r0-68074-g91a01f21abfe19
> > 
> > /* Estimate number of insns of completely unrolled loop.  We assume
> > +   that the size of the unrolled loop is decreased in the
> > +   following way (the numbers of insns are based on what
> > +   estimate_num_insns returns for appropriate statements):
> > +
> > +   1) exit condition gets removed (2 insns)
> > +   2) increment of the control variable gets removed (2 insns)
> > +   3) All remaining statements are likely to get simplified
> > +  due to constant propagation.  Hard to estimate; just
> > +  as a heuristics we decrease the rest by 1/3.
> > +
> > +   NINSNS is the number of insns in the loop before unrolling.
> > +   NUNROLL is the number of times the loop is unrolled.  */
> > +
> > +static unsigned HOST_WIDE_INT
> > +estimated_unrolled_size (unsigned HOST_WIDE_INT ninsns,
> > +unsigned HOST_WIDE_INT nunroll)
> > +{
> > +  HOST_WIDE_INT unr_insns = 2 * ((HOST_WIDE_INT) ninsns - 4) / 3;
> > +  if (unr_insns <= 0)
> > +unr_insns = 1;
> > +  unr_insns *= (nunroll + 1);
> > +
> > +  return unr_insns;
> > +}
> > 
> > And r0-93444-g08f1af2ed022e0 try do it more accurately by marking
> > likely_eliminated stmt and minus that from total insns, But 2 / 3 is still
> > keeped.
> > 
> > +/* Estimate number of insns of completely unrolled loop.
> > +   It is (NUNROLL + 1) * size of loop body with taking into account
> > +   the fact that in last copy everything after exit conditional
> > +   is dead and that some instructions will be eliminated after
> > +   peeling.
> > 
> > -   NINSNS is the number of insns in the loop before unrolling.
> > -   NUNROLL is the number of times the loop is unrolled.  */
> > +   Loop body is likely going to simplify futher, this is difficult
> > +   to guess, we just decrease the result by 1/3.  */
> > 
> >  static unsigned HOST_WIDE_INT
> > -estimated_unrolled_size (unsigned HOST_WIDE_INT ninsns,
> > +estimated_unrolled_size (struct loop_size *size,
> >  unsigned HOST_WIDE_INT nunroll)
> >  {
> > -  HOST_WIDE_INT unr_insns = 2 * ((HOST_WIDE_INT) ninsns - 4) / 3;
> > +  HOST_WIDE_INT unr_insns = ((nunroll)
> > +* (HOST_WIDE_INT) (size->overall
> > +   -
> > size->eliminated_by_peeling));
> > +  if (!nunroll)
> > +unr_insns = 0;
> > +  unr_insns += size->last_iteration -
> > size->last_iteration_eliminated_by_peeling;
> > +
> > +  unr_insns = unr_insns * 2 / 3;
> >if (unr_insns <= 0)
> >  unr_insns = 1;
> > -  unr_insns *= (nunroll + 1);
> > 
> > It looks to me 1 / 3 overestimates the instructions that can be optimised 
> > away,
> > especially if we've subtracted eliminated_by_peeling
> 
> Yes, that 1/3 reduction is a bit odd - you could have the same effect
> by increasing the instruction limit by 1/3, but that means it doesn't
> really matter, does it?  It would be interesting to see if increasing
> the limit by 1/3 and removing the above is neutral on SPEC?

Remove 1/3 reduction get ~2% improvement for 525.x264_r on SPR with
-march=native -O3, no big impact on other integer benchmark.

The regression comes from below function, cunrolli unrolls the inner loop,
cunroll unrolls the outer loop, and causes lots of spills.

typedef unsigned long long uint64_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
uint64_t x264_pixel_var_8x8(uint8_t *pix, int i_stride )
{
uint32_t sum = 0, sqr = 0;
for( int y = 0; y < 8; y++ )
{
for( int x = 0; x < 8; x++ ) 
{
sum += pix[x]; 
sqr += pix[x] * pix[x]; 
}  
pix += i_stride;   
}   
return sum + ((uint64_t)sqr << 32);
}

[Bug middle-end/99689] Initialized local variable becomes uninitialized after use

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

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

--- Comment #7 from Andrew Pinski  ---
GCC 9.3.0 says:
/app/example.cpp:19:18: missed:   can't use a fully-masked loop because the
target doesn't have the appropriate masked load or store.
/app/example.cpp:19:18: note:   vect_model_load_cost: aligned.
/app/example.cpp:19:18: note:   vect_model_load_cost: inside_cost = 2,
prologue_cost = 0 .
/app/example.cpp:19:18: note:   ==> examining statement: _2 = (unsigned int)
_24;
/app/example.cpp:19:18: note:   vect_is_simple_use: operand # VUSE <.MEM_12>
MEM[(long unsigned intD.17 *)SR.139_80 + 8B], type of def: internal
...

But GCC 9.4.0 says:
/app/example.cpp:19:18: missed:   not falling back to elementwise accesses
/app/example.cpp:20:49: missed:   not vectorized: relevant stmt not supported:
_24 = MEM[(long unsigned int *)SR.139_80 + 8B];
/app/example.cpp:19:18: missed:  bad operation or unsupported loop bound.
/app/example.cpp:19:18: missed: couldn't vectorize loop
/app/example.cpp:20:49: missed: not vectorized: relevant stmt not supported:
_24 = MEM[(long unsigned int *)SR.139_80 + 8B];
/app/example.cpp:9:1: note: vectorized 0 loops in function.

[Bug debug/114144] New: Variables optimized out by -Og

[lukas.graetz--- via Gcc-bugs]

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

Bug ID: 114144
   Summary: Variables optimized out by -Og
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukas.gra...@tu-darmstadt.de
  Target Milestone: ---

-Og seems to  some variable values: On x86-64, function
parameters are lost after calling other functions, they were not saved (to the
stack). This could be undesired when debugging. Consider the following example:

= foo.c 
int foo (int i) {
return i + 1;
}

= caller.c =
extern int foo(int);
int main(int argc, char **argv) {
int i = foo(argc);
int v = foo(i);
return v;
}


   Compile on x86-64:

$ gcc -Og -g caller.c foo.c -o caller

   Debug with breakpoint after calling foo():

$ gdb caller

Reading symbols from caller...
(gdb) break caller.c:5
Breakpoint 1 at 0x401116: file caller.c, line 5.
(gdb) run
Starting program: /home/lukas/test/caller 

Breakpoint 1, main (argc=, argv=) at caller.c:5
5   return v;
(gdb) print argc
$1 = 
(gdb) print i
$2 = 
(gdb) print v
$3 = 3

---

For 32-bit x86 with "-m32 -Og -g" we would get argc and argv because the
calling conventions put them on the stack and not a caller-saved variable.
However, the variable i would still be  at the breakpoint.

---
EXPECTED RESULT by compiling the same with -O0:

$ gcc -O0 -g caller.c foo.c -o caller

$ gdb caller

(gdb) break caller.c:5
Breakpoint 1 at 0x40112f: file caller.c, line 5.
(gdb) run
Starting program: /home/lukas/test/caller

Breakpoint 1, main (argc=1, argv=0x7fffdc98) at caller.c:5
5   return 0;
(gdb) print argc
$1 = 1
(gdb) print i
$2 = 2
(gdb) print v
$3 = 3
---

This is not a problem of the debugger gdb: By looking at the DWARF debugging
info, it turns out that argc has indeed been optimised out:


$ objdump -W caller
[...]
 <2><6d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
<6e>   DW_AT_name: (indirect string, offset: 0x11): argc
<72>   DW_AT_decl_file   : 1
<72>   DW_AT_decl_line   : 2
<72>   DW_AT_decl_column : 14
<73>   DW_AT_type: <0x44>
<77>   DW_AT_location: 0x10 (location list)
<7b>   DW_AT_GNU_locviews: 0xc
[...]
Contents of the .debug_loclists section:
[...]
0010 v000 v000 views at 000c for:
 00401106 0040110e (DW_OP_reg5 (rdi))
0015 v000 v000 views at 000e for:
 0040110e 0040111b (DW_OP_entry_value: (DW_OP_reg5
(rdi)); DW_OP_stack_value)
001d 
[...]


Our breakpoint at location 0x401116 is inside the second range of the loclist.
However, we cannot compute "DW_OP_entry_value: (DW_OP_reg5 (rdi))" at 0x401116,
since it refers to a state at a previous location (the value of rdi at the
subprogram entry). Also, from the disasambly you can clearly see that
caller-saved registers %edi and %eax are not saved (neither to the stack nor to
callee-saved registers) before calling foo:

$ objdump -d caller
[...]
00401106 :
  401106:   48 83 ec 08 sub$0x8,%rsp
  40110a:   e8 0c 00 00 00  callq  40111b 
  40110f:   89 c7   mov%eax,%edi
  40:   e8 05 00 00 00  callq  40111b 
  401116:   48 83 c4 08 add$0x8,%rsp
  40111a:   c3  retq   
[...]


And if you don't like breakpoints, you could modify caller.c as follows to
automatically break by calling abort:

= caller2.c =
#include 
extern int foo(int);
int main(int argc, char **argv) {
int i = foo(argc);
int v = foo(i);
abort();
}
=

$ gcc -Og -g caller2.c foo.c -o caller2
$ gdb ./caller2
(gdb) run
Program received signal SIGABRT, Aborted.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77dcd859 in __GI_abort () at abort.c:79
#2  0x0040113b in main (argc=, argv=)
at caller2.c:6

Here, too, we have argc=.


--
According to the documentation of -Og:

"-Og should be the optimization level of choice for the standard
edit-compile-debug cycle, offering a reasonable level of optimization while
maintaining fast compilation and a good debugging experience."

"It is a better choice than -O0 for producing debuggable code because some
compiler passes that collect debug information are disabled at -O0."

But for many cases, -O0 currently seems to be the better choice. Because -O0
saves all values to the stack, they will not be . If -Og is
working 

[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/83226

--- Comment #16 from Andrew Pinski  ---
Filed it as https://github.com/llvm/llvm-project/issues/83226 .

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Iain Sandoe from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > Did the LLVM assembler get fixed?
> 
> not as of xcode 13.0 (I don't know if anyone filed a radar tho) - since the
> problem was fixed on the branch, I guess no-one was motivated.

and it is still a bug in the upstream LLVM too; just checked. Will file a bug
there soon.

[Bug target/114130] RISC-V: `__atomic_compare_exchange` does not use sign-extended value

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-28
 Target|riscv   |riscv64
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
foo(unsigned int*):
srlia5,a0,1
ld  a4,0(a0)
1:
lr.wa3,0(a0)
bne a3,a5,1f
sc.wa2,a4,0(a0)
bneza2,1b
1:
ret

foo:
ld  a4,0(a0)
srlia5,a0,1
 1: lr.w a3,0(a0); bne a3,a5,1f; sc.w a2,a4,0(a0); bnez a2,1b; 1:
ret

[Bug target/114143] New: Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

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

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

Bug ID: 114143
   Summary: Non-thumb arm32 code in thumb multilib for libgcc and
in -mthumb build
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
Target: arm-eabi

Building an arm-eabi newlib toolchain configured simply with --target arm-eabi,
I expect the simplest thumb1 library code in libraries linked in when I compile
and link the main code using e.g. -O2 -mcpu=cortex-m7+nofp -msoft-float.  To my
surprise, I get 32-bit ("arm32") code linked in.  Needless to say, it crashes
for this reason on the target Cortex-M7 system. On inspection the linked-in
thumb multilib is full of 32-bit code.  Ditto some of the newlib code for some
optimized functions implemented in assembly code (like strcmp), but that may be
a separate bug unless the preprocessor macros that newlib uses in the build,
are wrong for the same reason as in this PR.

While I can work around this by adding --with-arch=armv7e-m at configure-time,
I think a "plain" arm-eabi configuration being unusable for thumb-only builds
with -mthumb is a bug or at least a surprising caveat worth being documented.

Example code, for a tool-chain configured with --target arm-eabi as above:

a.c; compile with "-O2 -mthumb" to simulate other library code:
```
unsigned udivide(unsigned a, unsigned b)
{
  return a / b;
}'''

b.c; compile with "-msoft-float -mthumb -mcpu=cortex-m7+nofp -O2" simulating
code you care about:
```extern unsigned udivide(unsigned, unsigned);
int main()
{
  __builtin_exit (udivide(42, 6));
}'''

Link a.o and b.o producing ab using gcc with e.g. "-msoft-float -mthumb
-mcpu=cortex-m7+nofp" to make sure you get the right multilib.  Inspect ab
using arm-eabi-objdump -d.  Observe udivide calling  __udivsi3, with __udivsi3
containing arm32 code.

[Bug target/114134] [14 Regression] Extra mov instructions for simple function compared with GCC13

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Looks like the biggest issue is when expanding:
;; return D.26244;


Before:

(insn 34 33 35 (set (subreg:DI (reg:TI 107) 8)
(reg:DI 108)) "/app/example.cpp":14:47 discrim 1 -1
 (nil))

(insn 35 34 36 (set (reg:TI 98 [  ])
(reg:TI 107)) "/app/example.cpp":14:47 discrim 1 -1
 (nil))

After:
(insn 41 40 42 (set (reg:TI 130)
(ior:TI (and:TI (reg:TI 130)
(const_wide_int 0x0))
(ashift:TI (zero_extend:TI (reg:DI 131))
(const_int 64 [0x40] "/app/example.cpp":14:47 discrim 1 -1
 (nil))

(insn 42 41 43 (set (reg:TI 114 [  ])
(reg:TI 130)) "/app/example.cpp":14:47 discrim 1 -1
 (nil))

[Bug target/114134] [14 Regression] Extra mov instructions for simple function compared with GCC13

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|Extra mov instructions for  |[14 Regression] Extra mov
   |simple function compared|instructions for simple
   |with GCC13  |function compared with
   ||GCC13

[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform

[miladfarca at gmail dot com via Gcc-bugs]

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

--- Comment #12 from mfarca  ---
I've applied the above patch directly to
`/usr/include/c++/12/bits/stl_algobase.h` under my fedora 36 env with gcc
12.2.1 and it solved the problem.

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

--- Comment #2 from Jerry DeLisle  ---
It looks like the 'selector' in this case is an expr.

The expr must be a pointer object or a 'designator'

A designator must be:

R901
designator

object-name
array-element
array-section
coindexed-named-object
complex-part-designator
structure-component
substring

I am not seeing the expr in the example as one of these listed. ???

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
I see the fail here but I am not sure of the validity. I am going to read the
latest standard. I always thought of associate to refer associate complicated
data references to make code more readable. In this case it is referring to a
function which resolves to a constant.

Interestingly if I wrap the associate with parens one gets:

   associate (x => (log(cmplx(-1,0

$ gfc pr114141.f90 
pr114141.f90:6:14:

6 |   y = x%im
  |  1
Error: The RE or IM part_ref at (1) must be applied to a COMPLEX expression

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

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

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

--- Comment #14 from Andrew Pinski  ---
(In reply to g.peterhoff from comment #13)
> > The cppreference page is wrong.
> But then *all* of your implementations for fmin/fmax (float, double, long
> double, std::floatN_t) would be wrong, because they give exactly the results
> as described on cppreference.
> Is this really the case (which I don't believe)? And if so, that still
> doesn't solve the original problem: std::math-functions and
> quadmath-functions *must* of course return the same results - no matter
> which implementation is correct.

Again read what I mentioned, adding -fsignaling-nans changes the behavior of
std::fmin/fmax even for float/double,etc.
As I mentioned, it is about constant folding of fmin (inside the compiler) vs
what the function actually does.

> Is this really the case (which I don't believe)? 

You can test it yourself by changing const to volatile and you will see it is
different in the middle-end's constant folding vs libc's version.

libc (and libquadmath) version is correct based on those 2 sourceware issues.
The question becomes is the constant folding version correct without
-fsignaling-nans ?

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #13 from g.peterh...@t-online.de ---
> The cppreference page is wrong.
But then *all* of your implementations for fmin/fmax (float, double, long
double, std::floatN_t) would be wrong, because they give exactly the results as
described on cppreference.
Is this really the case (which I don't believe)? And if so, that still doesn't
solve the original problem: std::math-functions and quadmath-functions *must*
of course return the same results - no matter which implementation is correct.

[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Similar cases with "select type" instead :
> 
> $ cat z3.f90
> program p
>type t
>   integer, allocatable :: a(:)
>end type
>class(t) :: x[:]
>select type (y => x)
>end select
> end
> 
> $ cat z4.f90
> program p
>type t
>   integer, allocatable :: a(:)
>end type
>class(t) :: x[*]
>select type (y => x)
>end select
> end

These test still fail.

[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2024-02-28
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Follow-up of pr88357, affects versions down to at least r5.
> With a missing attribute allocatable or pointer :
> 
> $ cat z1.f90
> program p
>type t
>   integer, allocatable :: a(:)
>end type
>class(t) :: x[:]
>associate (y => x)
>end associate
> end

This now gives 

% gfcx -o z -fcoarray=single a.f90
a.f90:6:19:

6 |class(t) :: x[:]
  |   1
Error: Coarray variable 'x' at (1) shall not have codimensions with deferred
shape


> $ cat z2.f90
> program p
>type t
>   integer, allocatable :: a(:)
>end type
>class(t) :: x[*]
>associate (y => x)
>end associate
> end

This gives

% gfcx -o z -fcoarray=single a.f90
a.f90:6:19:

6 |class(t) :: x[*]
  |   1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=26045

--- Comment #12 from Andrew Pinski  ---
Specifically  https://sourceware.org/bugzilla/show_bug.cgi?id=26045#c4 :
(The ISO C convention that "NaN" means 
"quiet NaN" by default may not be the most helpful to readers.  We do 
refer to the fmax handling of signaling NaNs in the documentation of 
FE_SNANS_ALWAYS_SIGNAL.

So basically libquadmath is correct for signaling NaNs and maybe the constant
folding of GCC is incorrect though I am not 100% sure if -fsignaling-nans
should not make a difference or not.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

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

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

--- Comment #11 from Andrew Pinski  ---
And see https://sourceware.org/bugzilla/show_bug.cgi?id=26045 .

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to g.peterhoff from comment #7)
> I think there is a misunderstanding. The problem is that std::fmin/std::fmax
> and quadmath fminq/fmaxq give different results when only *one* argument is
> signaling_NaN.
> The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
> https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
> * If one of the two arguments is NaN, the value of the other argument is
> returned
> * Only if both arguments are NaN, NaN is returned
> 
> quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

The cppreference page is wrong.
See https://sourceware.org/bugzilla/show_bug.cgi?id=20947 for reference on why.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=20947

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> As I can show this is not just about quadmath either. glibc's fminf/fmaxf
> has the same behavior there.

https://sourceware.org/bugzilla/show_bug.cgi?id=20947

[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Caused build error:

libtool: compile:  /home/dave/gnu/gcc/objdir64/./gcc/xgcc -shared-libgcc
-B/home
/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-hp
-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/li
bstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++
-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/bin/
-B/opt/gnu6
4/gcc/gcc-14/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-14/hppa64-hp-h
pux11.11/include -isystem /opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/sys-include
-fno-checking -I/home/dave/gnu/gcc/gcc/libstdc++-v3/../libgcc 
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
 
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++20 
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections 
-fdata-sections -frandom-seed=tzdb.lo -fimplicit-templates -O2 -g -I. -c
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc  -DPIC 
-D_GLIBCXX_SHARED -o tzdb.o
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:654:9: error:
'atomic_signed_lock_free' does not name a type
   654 | atomic_signed_lock_free counter{0};
   | ^~~
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:706:18: error:
'atomic_signed_lock_free' was not declared in this scope; did you mean 
'atomic_is_lock_free'?
   706 | RulesCounter rules_counter;
   |  ^~~
   |  atomic_is_lock_free
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:706:41: error: template
argument 1 is invalid
   706 | RulesCounter rules_counter;
   | ^
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::increment()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:658:11: error: 'counter' was
not declared in this scope; did you mean 'count'?
   658 | { counter.fetch_add(1, memory_order::relaxed); }
   |   ^~~
   |   count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::decrement()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:668:17: error: 'counter' was
not declared in this scope; did you mean 'count'?
   668 |   if (++counter == 0)
   | ^~~
   | count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::lock()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:679:25: error: 'counter' was
not declared in this scope; did you mean 'count'?
   679 |   for (auto c = counter.load(memory_order::relaxed); c != 0;)
   | ^~~
   | count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function 'void
std::chrono::time_zone::_Impl::RulesCounter<_Tp>::unlock()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:697:24: error: 'counter' was
not declared in this scope; did you mean 'count'?
   697 |   if (auto c = counter.load(memory_order::relaxed); c < 0)
   |    ^~~
   |    count
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In member function
'std::chrono::sys_info 
std::chrono::time_zone::_M_get_sys_info(std::chrono::sys_seconds) const':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:969:32: error: request for
member 'decrement' in '((const 
std::chrono::time_zone*)this)->std::chrono::time_zone::_M_impl.std::unique_ptr::operator->()->std::chrono::time_zone::_Impl::rules_counter',
 
which is of non-class type 'int'
   969 | _M_impl->rules_counter.decrement();
   |    ^
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'const
std::chrono::tzdb& std::chrono::reload_tzdb()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:1488:38: error: request for
member 'increment' in 
'impl.std::chrono::time_zone::_Impl::rules_counter', which is of non-class type
'int'
  1488 |   impl.rules_counter.increment();
   |  ^
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/atomic_wait.h:51,
  from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/atomic_base.h:42,
  from

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to g.peterhoff from comment #7)
> I think there is a misunderstanding. The problem is that std::fmin/std::fmax
> and quadmath fminq/fmaxq give different results when only *one* argument is
> signaling_NaN.
> The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
> https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
> * If one of the two arguments is NaN, the value of the other argument is
> returned
> * Only if both arguments are NaN, NaN is returned
> 
> quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

As I can show this is not just about quadmath either. glibc's fminf/fmaxf has
the same behavior there.

[Bug middle-end/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #7 from g.peterh...@t-online.de ---
I think there is a misunderstanding. The problem is that std::fmin/std::fmax
and quadmath fminq/fmaxq give different results when only *one* argument is
signaling_NaN.
The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
* If one of the two arguments is NaN, the value of the other argument is
returned
* Only if both arguments are NaN, NaN is returned

quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

[Bug target/50597] printf_fp.o: relocation R_X86_64_PC32 against `hack_digit.6607' can not be used when making a shared object; recompile with -fPIC

[g.peterhoff--- via Gcc-bugs]

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

g.peterh...@t-online.de changed:

   What|Removed |Added

 CC||g.peterh...@t-online.de

--- Comment #2 from g.peterh...@t-online.de ---
I think there is a misunderstanding. The problem is that std::fmin/std::fmax
and quadmath fminq/fmaxq give different results when only *one* argument is
signaling_NaN.
The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
* If one of the two arguments is NaN, the value of the other argument is
returned
* Only if both arguments are NaN, NaN is returned

quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

thx
Gero

[Bug middle-end/87161] if -Werror appear after -Wmissing-prototypes the warning is not turn into error

[ferdnyc at gmail dot com via Gcc-bugs]

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

FeRD  changed:

   What|Removed |Added

 CC||ferdnyc at gmail dot com

--- Comment #7 from FeRD  ---
(In reply to Simon Marchi from comment #6)
> I also encountered this inconsistency when running g++ under ccache.  I
> can't tell if this is a ccache or a gcc problem.  

Any thoughts about gcc's argument handling (aka this bug) notwithstanding, the
fact that ccache reorders some command-line flags (including -Werror) in ways
that affect the compiler's execution is an acknowledged bug[1] in ccache,
hopefully slated to be addressed in the next release.

[1]: github.com/ccache/ccache/issues/738

[Bug c++/114013] [14 Regression] Specializations of var templates no longer emitted since r14-8987

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:615b62aada6cc42759e5c43e196dab6c524925d6

commit r14-9201-g615b62aada6cc42759e5c43e196dab6c524925d6
Author: Nathaniel Shead 
Date:   Wed Feb 28 11:20:53 2024 +1100

c++: Revert deferring emission of inline variables [PR114013]

This is a (partial) reversion of r14-8987-gdd9d14f7d53 to return to
eagerly emitting inline variables to the middle-end when they are
declared. 'import_export_decl' will still continue to accept them, as
allowing this is a pure extension and doesn't seem to cause issues with
modules, but otherwise deferring the emission of inline variables
appears to cause issues on some targets and prevents some code using
inline variable templates from correctly linking.

There might be a more targetted way to support this, but due to the
complexity of handling linkage and emission I'd prefer to wait till
GCC 15 to explore our options.

PR c++/113970
PR c++/114013

gcc/cp/ChangeLog:

* decl.cc (make_rtl_for_nonlocal_decl): Don't defer inline
variables.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/inline-var10.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:615b62aada6cc42759e5c43e196dab6c524925d6

commit r14-9201-g615b62aada6cc42759e5c43e196dab6c524925d6
Author: Nathaniel Shead 
Date:   Wed Feb 28 11:20:53 2024 +1100

c++: Revert deferring emission of inline variables [PR114013]

This is a (partial) reversion of r14-8987-gdd9d14f7d53 to return to
eagerly emitting inline variables to the middle-end when they are
declared. 'import_export_decl' will still continue to accept them, as
allowing this is a pure extension and doesn't seem to cause issues with
modules, but otherwise deferring the emission of inline variables
appears to cause issues on some targets and prevents some code using
inline variable templates from correctly linking.

There might be a more targetted way to support this, but due to the
complexity of handling linkage and emission I'd prefer to wait till
GCC 15 to explore our options.

PR c++/113970
PR c++/114013

gcc/cp/ChangeLog:

* decl.cc (make_rtl_for_nonlocal_decl): Don't defer inline
variables.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/inline-var10.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

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

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

--- Comment #6 from Lewis Hyatt  ---
(In reply to Sam James from comment #5)
> Thank you Lewis!
> 
> Would you mind pinging this again?
> 
> I've just started hitting this on glibc systems too as we added a wrapper to
> a libbsd header (which I'm probably going to have to drop for now).

Sure, I tried...
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646695.html. I think
reviewers are probably focused on other things for the GCC 14 release though, I
have 3 or 4 libcpp patches that have been waiting for months now, and they may
not make it into 14.0 if they aren't regressions. It may help if you chime in
on the gcc-patches thread as well?

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

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

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

--- Comment #39 from Tom Tromey  ---
(In reply to Lukas Grätz from comment #36)

> > #2  0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > d=, 
> > e=, f= > reading variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38
> 
> 
> I can confirm that. What bothers me, is the wording "d= out>" and not just "d=".

Could you file a gdb bug about this?  Preferably with some
kind of test case?

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

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

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

--- Comment #5 from Sam James  ---
Thank you Lewis!

Would you mind pinging this again?

I've just started hitting this on glibc systems too as we added a wrapper to a
libbsd header (which I'm probably going to have to drop for now).

[Bug c++/114142] [coroutines]: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have reference_type in lookup_base, at cp/search.cc:252

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

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

--- Comment #1 from Andrew Pinski  ---
>In 13.2 this is a rejects-valid.

It might be only ICEing when checking is turned on which it is for the trunk
(normally).

[Bug c++/114142] New: [coroutines]: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have reference_type in lookup_base, at cp/search.cc:252

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 114142
   Summary: [coroutines]: internal compiler error: tree check:
expected record_type or union_type or qual_union_type,
have reference_type in lookup_base, at
cp/search.cc:252
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

```
  #include 

  struct Bar {};

  struct Task
  {
  struct promise_type
  {
  promise_type(Bar&) {}
  std::suspend_never initial_suspend() { return {}; }
  std::suspend_never final_suspend() noexcept { return {}; }
  void return_void() {}
  void unhandled_exception() {}
  Task get_return_object() { return {}; }
  };
  };

  struct Foo : Bar {
  Task foo() {
  co_await std::suspend_always();
  co_return;
  }
  };

  int main()
  {
  Foo x;
  x.foo();
  }
```

When I try and return a Task from a Derived member function and set the
promise's first parameter to the Base& I see this ICE.

In 13.2 this is a rejects-valid.

Current live example https://godbolt.org/z/9EceW8boz.

[Bug middle-end/114140] fmin/fmax with signaling_NaN not work

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

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

--- Comment #6 from Andrew Pinski  ---
So with `-fsignaling-nans` we don't constant fold fmin*/fmax* any more.

[Bug middle-end/114140] fmin/fmax with signaling_NaN not work

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

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

--- Comment #5 from Jakub Jelinek  ---
At least on the godbolt link, if I add -fsignaling-nans option, it prints
inf/inf/nan/nan for both types.
So, in that case it looks like a non-bug to me.
fmaxq/fminq get the same behavior regardless of the option simply because
fmaxq/fminq aren't builtins and so aren't constant folded.

[Bug middle-end/114140] fmin/fmax with signaling_NaN not work

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|quadmath fminq/fmaxq with   |fmin/fmax with
   |signaling_NaN not work  |signaling_NaN not work

--- Comment #4 from Andrew Pinski  ---
With `-fsignaling-nans` added, then we get the :
inf
inf
nan
nan

so ...

Even using float instead also cause the same output:
```
#include 
#include 
#include 
#include 
#include 

int main()
{
{
using T = float;
using L = std::numeric_limits;
const T
a = L::infinity(),
b = L::quiet_NaN(),
c = L::signaling_NaN();

std::cout << "float\n";
std::cout << std::fmin(a, b) << std::endl;
std::cout << std::fmax(a, b) << std::endl;
std::cout << std::fmin(a, c) << std::endl;
std::cout << std::fmax(a, c) << std::endl;
}
}
```

So Looks like we convert sNaN to qNan if `-fsignaling-nans` is not supplied ...

[Bug middle-end/114140] quadmath fminq/fmaxq with signaling_NaN not work

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libquadmath |middle-end

--- Comment #3 from Andrew Pinski  ---
This has nothing to do quadmath But rather the builtins and constant folding.
As shown by:


```
_Float128 f1()
{

using T = _Float128;
//using L = std::numeric_limits;
const T
a = __builtin_huge_valf128(),
b = __builtin_nanf128(""),
c = __builtin_nansf128("");
  return __builtin_fminf128(a, b);
}
_Float128 f2()
{

   //using T = std::float128_t;
using T = _Float128;
 //   using L = std::numeric_limits;
const T
a = __builtin_huge_valf128(),
b = __builtin_nanf128(""),
c = __builtin_nansf128("");
  return __builtin_fmaxf128(a, b);
}
_Float128 f3()
{
   //using T = std::float128_t;
using T = _Float128;
  //  using L = std::numeric_limits;
const T
a = __builtin_huge_valf128(),
b = __builtin_nanf128(""),
c = __builtin_nansf128("");
  return __builtin_fminf128(a, c);
}
_Float128 f4()
{

   //using T = std::float128_t;
using T = _Float128;
 //   using L = std::numeric_limits;
const T
a = __builtin_huge_valf128(),
b = __builtin_nanf128(""),
c = __builtin_nansf128("");
  return __builtin_fmaxf128(a, c);
}
```

[Bug analyzer/111802] [14 Regression] New analyser diagram failures since commit b365e9d57ad4

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by the above patch; closing.  Please reopen if you still see
these issues.

[Bug analyzer/110483] [14 Regression] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by the above patch; closing.  Please reopen if you still see
these issues.

[Bug c++/66487] sanitizer/warnings for lifetime DSE

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

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

--- Comment #27 from Eric Gallager  ---
(In reply to Alexander Monakov from comment #26)
> RFC patch for detecting lifetime-dse issues via Valgrind (rather than MSan):
> https://inbox.sourceware.org/gcc-patches/20231024141124.210708-1-exactl...@ispras.ru/

So, if this bug is now specifically for the valgrind approach, is there a
separate one for MSan?

[Bug libquadmath/114140] quadmath fminq/fmaxq with signaling_NaN not work

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

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

--- Comment #2 from Joseph S. Myers  ---
Returning a quiet NaN when either argument is a signaling NaN is correct at
least for C (fmin/fmax correspond to IEEE 754-2008 operations, *not* the new
IEEE 754-2019 operations which are
fminimum/fmaximum/fminimum_num/fmaximum_num).

This is not a self-contained bug report ("not work" doesn't say what was
expected or why).  But the output reported from the godbolt link is

std::float128_t
inf
inf
inf
inf

__float128
inf
inf
nan
nan

which looks correct for __float128 and incorrect for float128_t (suggesting
that, in the float128_t case, something might have wrongly converted the
signaling NaN to a quiet NaN before calling the underlying function).

[Bug analyzer/111802] [14 Regression] New analyser diagram failures since commit b365e9d57ad4

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:939439a90f234f9e70d30240bf5c227eebe2b43f

commit r14-9199-g939439a90f234f9e70d30240bf5c227eebe2b43f
Author: David Malcolm 
Date:   Tue Feb 27 14:49:42 2024 -0500

analyzer: use correct format code for string literal indices
[PR110483,PR111802]

On e.g. gcc211 the use of "%li" with unsigned HOST_WIDE_INT led to this
warning:
../../src/gcc/analyzer/access-diagram.cc: In member function âvoid
ana::string_literal_spatial_item::add_column_for_byte(text_art::table&, const
ana::bit_to_table_map&, text_art::style_manager&, ana::byte_offset_t,
ana::byte_offset_t, int, int) constâ:
../../src/gcc/analyzer/access-diagram.cc:1909:40: warning: format â%liâ
expects argument of type âlong intâ, but argument 3 has type âlong long
unsigned intâ [-Wformat=]
  byte_idx_within_string.ulow ()));
^
and to all values being erroneously printed as "0".

Fixed thusly.

gcc/analyzer/ChangeLog:
PR analyzer/110483
PR analyzer/111802
* access-diagram.cc
(string_literal_spatial_item::add_column_for_byte): Use %wu for
printing unsigned HOST_WIDE_INT.

Signed-off-by: David Malcolm 

[Bug analyzer/110483] [14 Regression] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:939439a90f234f9e70d30240bf5c227eebe2b43f

commit r14-9199-g939439a90f234f9e70d30240bf5c227eebe2b43f
Author: David Malcolm 
Date:   Tue Feb 27 14:49:42 2024 -0500

analyzer: use correct format code for string literal indices
[PR110483,PR111802]

On e.g. gcc211 the use of "%li" with unsigned HOST_WIDE_INT led to this
warning:
../../src/gcc/analyzer/access-diagram.cc: In member function âvoid
ana::string_literal_spatial_item::add_column_for_byte(text_art::table&, const
ana::bit_to_table_map&, text_art::style_manager&, ana::byte_offset_t,
ana::byte_offset_t, int, int) constâ:
../../src/gcc/analyzer/access-diagram.cc:1909:40: warning: format â%liâ
expects argument of type âlong intâ, but argument 3 has type âlong long
unsigned intâ [-Wformat=]
  byte_idx_within_string.ulow ()));
^
and to all values being erroneously printed as "0".

Fixed thusly.

gcc/analyzer/ChangeLog:
PR analyzer/110483
PR analyzer/111802
* access-diagram.cc
(string_literal_spatial_item::add_column_for_byte): Use %wu for
printing unsigned HOST_WIDE_INT.

Signed-off-by: David Malcolm 

[Bug libquadmath/114140] quadmath fminq/fmaxq with signaling_NaN not work

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
>From what I can see, the libquadmath implementation is the same as glibc's,
which does return x + y; if either x or y is sNaN:
https://sourceware.org/git/?p=glibc.git;a=blob;f=math/s_fmax_template.c;h=01b92600c67f7774f370810a1eea456867212ce3;hb=refs/heads/master

[Bug fortran/114141] New: ASSOCIATE and complex part ref when associate target is a function

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

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

Bug ID: 114141
   Summary: ASSOCIATE and complex part ref when associate target
is a function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57556=edit
patch

gfortran rejects the following code with an invalid error message.
The problem is that the target is not resolved to have type 
COMPLEX. The attach patch rectifies the issue.  It has been regtested
on x86_64-*-freebsd.


! { dg-do run }
program foo
   implicit none
   real y
   associate (x => log(cmplx(-1,0)))
  y = x%im
  if (int(100*y)-314 /= 0) stop 1
   end associate
end program

gfortran13 -c a.f90
a.f90:6:13:

6 |   y = x%im
  | 1
Error: Symbol 'x' at (1) has no IMPLICIT type
troutmask:sgk[244]

[Bug libquadmath/114140] New: quadmath fminq/fmaxq with signaling_NaN not work

[g.peterhoff--- via Gcc-bugs]

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

Bug ID: 114140
   Summary: quadmath fminq/fmaxq with signaling_NaN not work
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.peterh...@t-online.de
  Target Milestone: ---

please see https://godbolt.org/z/T4W8Mejxz

Notes:
* std::numeric_limits<__float128> (from boost) does not work properly, so I
fall back to builtins.
* std::fmin/fmax for __float128 calls fminq/fmaxq (boost, this works)

thx
Gero

[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  ---
(In reply to Sam James from comment #4)
> I was quite surprised by this behaviour. It should really be documented if
> we're going to stick with it, but I don't think we should at all..

I have asked Jeevitha to prepare a patch to remove the -many assembler option
usage on --enable-checking=release builds.

It would be nice if we can get some distro help to do some practice distro
builds using the patch to verify whether there it causes any fallout on distro
builds to help decide whether we should push the patch or leave things as they
are.

[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Will test on hppa64-hp-hpux11.11 on my next build.

[Bug target/114139] New: ICE: RTL check: expected code 'const_int', have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438 with -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114139
   Summary: ICE: RTL check: expected code 'const_int', have 'reg'
in riscv_macro_fusion_pair_p, at
config/riscv/riscv.cc:8438 with -O2 -fpic
-mexplicit-relocs -mcpu=sifive-p450
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

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

This might need RTL checking enabled to reproduce.

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450
testcase.c
during RTL pass: sched2
testcase.c: In function 'foo':
testcase.c:15:1: internal compiler error: RTL check: expected code 'const_int',
have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438
   15 | }
  | ^
0xad7f4d rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:770
0xb8ccd4 riscv_macro_fusion_pair_p
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:8438
0x2b11634 sched_macro_fuse_insns
/repo/gcc-trunk/gcc/sched-deps.cc:2859
0x2b11634 sched_analyze_insn
/repo/gcc-trunk/gcc/sched-deps.cc:2898
0x2b12329 deps_analyze_insn(deps_desc*, rtx_insn*)
/repo/gcc-trunk/gcc/sched-deps.cc:3690
0x2b1541a sched_analyze(deps_desc*, rtx_insn*, rtx_insn*)
/repo/gcc-trunk/gcc/sched-deps.cc:3843
0x16b24a8 compute_block_dependences
/repo/gcc-trunk/gcc/sched-rgn.cc:2738
0x16b24a8 sched_rgn_compute_dependencies(int)
/repo/gcc-trunk/gcc/sched-rgn.cc:3367
0x16b4d48 schedule_region
/repo/gcc-trunk/gcc/sched-rgn.cc:3139
0x16b4d48 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3525
0x16b53ed schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3511
0x16b53ed rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.cc:3749
0x16b53ed execute
/repo/gcc-trunk/gcc/sched-rgn.cc:3888
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9189-20240227001746-g1e2a3b278d7-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9189-20240227001746-g1e2a3b278d7-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240227 (experimental) (GCC)

[Bug middle-end/94083] inefficient soft-float x!=Inf code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed. Also happens with _Float128 on x86_64 since that is a soft-float fp
type too.

[Bug middle-end/114131] std::isinf(std::float128_t) generates superfluous nan-checks

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Actually this is a fully a dup of bug 94083.

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

[Bug middle-end/94083] inefficient soft-float x!=Inf code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||g.peterh...@t-online.de

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

[Bug target/113742] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8416 with -O2 -finstrument-functions -mtune=sifive-p600-se

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #4 from Zdenek Sojka  ---
I can confirm the supplied testcase no longer fails.

[Bug c++/114138] [c++2b] ICE on valid code using `auto(expr)` DECAY-COPY

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-27
   Keywords||rejects-valid
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug middle-end/114131] std::isinf(std::float128_t) generates superfluous nan-checks

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I am almost positive this is due to GCC default of trapping math here.

Adding  -fno-trapping-math GCC no longer has a check against NaN.

I think test2 can cause an fp exception to happen so it is almost definitely
not valid transformation unless with -fno-trapping-math.

As far as transforming test1 to test3, well it depends on if there are no
instructions to do the comparison and you are doing "soft" float for that type.
Basically we have:
```
  _1 = ABS_EXPR ;
  _2 = _1 u<= 1.18973149535723176508575932662800701619646905264169404553e+4932;
  _4 = ~_2;
```

Which we could recognize in the middle-end to do the transformation if the FP
format is easy to handle (double double is one which is not).

[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics

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

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

Richard Sandiford  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #8 from Richard Sandiford  ---
The reason early_ra doesn't help with the original testcase is that early_ra
punts on any non-move instruction that has a hard register destination.  And it
does that because it can't cope well with cases where hard-coded destinations
force the wrong choice (unlike the proper allocators, which can change the
destination where necessary).  The restriction is needed to avoid regressing
SVE ACLE tests.

[Bug target/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)

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

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

--- Comment #5 from Sam James  ---
I also now believe I've seen this on sparc with ncurses with
-fharden-control-flow-redundancy...

[Bug target/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)

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

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

--- Comment #4 from Sam James  ---
I have another testcase where it works with -save-temps or the GC params.

bibtexu-3.71_p20210325:

```
# i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.   -DUNIX -DKPATHSEA
-DU_DISABLE_RENAMING=1 -I/usr/include  -DUTF_8  -Wimplicit -Wreturn-type -O3
-pipe -march=i686 -fdiagnostics-color=always -mfpmath=sse -msse -msse2
-fno-vect-cost-model -fharden-control-flow-redundancy -fpermissive -c -o
bibtexu-bibtex-4.o bibtex-4.c -fharden-control-flow-redundancy
during RTL pass: rtl pre
In file included from bibtex-4.c:130:
bibtex-4.c: In function ‘x_format_name’:
sysdep.h:210:37: internal compiler error: Segmentation fault
  210 | #define END }
  | ^
bibtex-4.c:1303:1: note: in expansion of macro ‘END’
 1303 | END
  | ^~~
0x579d3dc9 crash_signal
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/toplev.cc:319
0x586e7ff0 mark_used_flags
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3364
0x586e6638 mark_used_flags
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3416
0x586e6638 mark_used_flags
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3411
0x586e6638 mark_used_flags
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3411
0x586e6638 reset_used_flags(rtx_def*)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3428
0x586e6638 reset_insn_used_flags
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3094
0x586e6638 reset_all_used_flags
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3111
0x586e4737 verify_rtl_sharing()
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3147
0x5832756c execute_function_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2109
0x5832756c do_per_function
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687
0x5832756c execute_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142
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.
```

For both test cases, -fno-harden-control-flow-redundancy also suppresses the
ICE.

[Bug target/106146] a redundant movprfx insn compare to llvm

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

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

--- Comment #3 from Andrew Pinski  ---
So I see svadd_z directly emits the instruction, not leaving any way to
optimize away the _z part before hand.
I am not sure how to fix this though.

[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

stmt_simple_for_scop_p tests for INTEGRAL_TYPE_P (it used to test INTEGER_TYPE
some years ago), so I think we should do the same here too.

[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity

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

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

--- Comment #8 from Jakub Jelinek  ---
Ah, but
unsigned a[24], b[24];
enum E { E0 = 0, E1 = 1, E42 = 42, E56 = 56 };

__attribute__((noipa)) unsigned
foo (enum E x)
{
  for (int i = 0; i < 24; ++i)
a[i] = i;
  unsigned e;
  if (x >= E42)
e = __builtin_clz ((unsigned) x);
  else
e = 42;
  for (int i = 0; i < 24; ++i)
b[i] = i;
  return e;
}

int
main ()
{
  if (foo (E1) != 42 || foo (E56) != __SIZEOF_INT__ * __CHAR_BIT__ - 6)
__builtin_abort ();
}
fails as well.  So, dunno if it shouldn't be testing for INTEGRAL_TYPE_P,
or be dropped altogether (when the check was added in
r6-2239-g4bc4dd11ec8c7be528abcb75a1af715d715b4835, parameter_index_in_region
punted on anything but INTEGER_TYPE, but that is gone from there for years).

What about floating point compares, vector compares, etc.?
Although
unsigned a[24], b[24];

__attribute__((noipa)) unsigned
foo (float x)
{
  for (int i = 0; i < 24; ++i)
a[i] = i;
  unsigned e;
  if (x >= 42.0)
e = x;
  else
e = 15;
  for (int i = 0; i < 24; ++i)
b[i] = i;
  return e;
}

int
main ()
{
  if (foo (1.0f) != 15 || foo (45.0f) != 45)
__builtin_abort ();
}
doesn't fail.

[Bug target/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)

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

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

--- Comment #3 from Sam James  ---
==16482== Command: /usr/libexec/gcc/i686-pc-linux-gnu/14/cc1 -quiet -I . -I
./src -D PACKAGE_NAME="lua5.4" -D PACKAGE_TARNAME="lua" -D
PACKAGE_VERSION="5.4.6" -D PACKAGE_STRING="lua5.4\ 5.4.6" -D
PACKAGE_BUGREPORT="https://bugs.gentoo.org/; -D
PACKAGE_URL="http://www.lua.org; -D PACKAGE="lua" -D VERSION="5.4.6" -D
HAVE_STDIO_H=1 -D HAVE_STDLIB_H=1 -D HAVE_STRING_H=1 -D HAVE_INTTYPES_H=1 -D
HAVE_STDINT_H=1 -D HAVE_STRINGS_H=1 -D HAVE_SYS_STAT_H=1 -D HAVE_SYS_TYPES_H=1
-D HAVE_UNISTD_H=1 -D STDC_HEADERS=1 -D HAVE_DLFCN_H=1 -D LT_OBJDIR=".libs/" -D
LUA_USE_READLINE=1 -D LUA_USE_LINUX=1 -D LUA_COMPAT_5_3 -D PIC src/lvm.c -quiet
-dumpdir src/.libs/ -dumpbase lvm.c -dumpbase-ext .c -march=i686 -mfpmath=sse
-msse -msse2 -O3 -Wall -fdiagnostics-color=always -fvect-cost-model=unlimited
-fharden-control-flow-redundancy -fpermissive -fPIC -o -
==16482==
==16482== Conditional jump or move depends on uninitialised value(s)
==16482==at 0x232FE2A: UnknownInlinedFun (sparseset.h:146)
==16482==by 0x232FE2A: mark_pseudo_regno_live(int) (ira-lives.cc:327)
==16482==by 0x2324AE3: UnknownInlinedFun (ira-lives.cc:411)
==16482==by 0x2324AE3: UnknownInlinedFun (ira-lives.cc:425)
==16482==by 0x2324AE3: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.cc:1404)
==16482==by 0x2305DF9: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.cc:1809)
==16482==by 0x26CAB8B: ira_create_allocno_live_ranges() (ira-lives.cc:1818)
==16482==by 0x22FFD84: ira_build() (ira-build.cc:3491)
==16482==by 0x26AFBC9: UnknownInlinedFun (ira.cc:5793)
==16482==by 0x26AFBC9: (anonymous namespace)::pass_ira::execute(function*)
[clone .lto_priv.0] (ira.cc:6117)
==16482==by 0x1EA53B7: execute_one_pass(opt_pass*) (passes.cc:2646)
==16482==by 0x1F716AB: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==16482==by 0x1F716C8: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==16482==by 0x1F713E8: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==16482==by 0x25CC292: cgraph_node::expand() (cgraphunit.cc:1845)
==16482==by 0x1E9FF59: UnknownInlinedFun (cgraphunit.cc:2028)
==16482==by 0x1E9FF59: symbol_table::compile() (cgraphunit.cc:2402)
==16482==
==16482== Conditional jump or move depends on uninitialised value(s)
==16482==at 0x232FF24: UnknownInlinedFun (sparseset.h:146)
==16482==by 0x232FF24: UnknownInlinedFun (sparseset.h:165)
==16482==by 0x232FF24: UnknownInlinedFun (ira-lives.cc:127)
==16482==by 0x232FF24: mark_pseudo_regno_live(int) (ira-lives.cc:331)
==16482==by 0x2324AE3: UnknownInlinedFun (ira-lives.cc:411)
==16482==by 0x2324AE3: UnknownInlinedFun (ira-lives.cc:425)
==16482==by 0x2324AE3: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.cc:1404)
==16482==by 0x2305DF9: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.cc:1809)
==16482==by 0x26CAB8B: ira_create_allocno_live_ranges() (ira-lives.cc:1818)
==16482==by 0x22FFD84: ira_build() (ira-build.cc:3491)
==16482==by 0x26AFBC9: UnknownInlinedFun (ira.cc:5793)
==16482==by 0x26AFBC9: (anonymous namespace)::pass_ira::execute(function*)
[clone .lto_priv.0] (ira.cc:6117)
==16482==by 0x1EA53B7: execute_one_pass(opt_pass*) (passes.cc:2646)
==16482==by 0x1F716AB: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==16482==by 0x1F716C8: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==16482==by 0x1F713E8: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==16482==by 0x25CC292: cgraph_node::expand() (cgraphunit.cc:1845)
==16482==by 0x1E9FF59: UnknownInlinedFun (cgraphunit.cc:2028)
==16482==by 0x1E9FF59: symbol_table::compile() (cgraphunit.cc:2402)
[...]
==16482== Use of uninitialised value of size 4
==16482==at 0x238D41A: UnknownInlinedFun (sparseset.h:146)
==16482==by 0x238D41A: UnknownInlinedFun (sparseset.h:165)
==16482==by 0x238D41A: make_hard_regno_live(int) (lra-lives.cc:288)
==16482==by 0x23885B7: process_bb_lives(basic_block_def*, int&, bool)
(lra-lives.cc:960)
==16482==by 0x2386343: lra_create_live_ranges_1(bool, bool)
(lra-lives.cc:1416)
==16482==by 0x2385EF0: lra_create_live_ranges(bool, bool)
(lra-lives.cc:1486)
==16482==by 0x234E372: lra(_IO_FILE*, int) (lra.cc:2482)
==16482==by 0x26D1D2F: UnknownInlinedFun (ira.cc:5973)
==16482==by 0x26D1D2F: (anonymous
namespace)::pass_reload::execute(function*) [clone .lto_priv.0] (ira.cc:6161)
==16482==by 0x1EA53B7: execute_one_pass(opt_pass*) (passes.cc:2646)
==16482==by 0x1F716AB: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==16482==by 0x1F716C8: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==16482==by 0x1F713E8: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==16482==by 0x25CC292: cgraph_node::expand() 

[Bug target/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)

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

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

--- Comment #2 from Sam James  ---
The bug is very reproducible with the original command, but...

I can't reproduce it with the preprocessed source or with -save-temps on the
original command line, but pinskia suggested I try --param=ggc-min-expand=1
--param=ggc-min-heapsize=1 which fixes the original crash...

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #38 from Lukas Grätz  ---
(In reply to Jakub Jelinek from comment #37)
> Nowhere, just run and when it stops due to abort, just up several times
> until reaching the appropriate frame.


I see, this gives me:


(gdb) frame 4
#4  0x004012aa in qux () at bar-artificial.c:55
55baz (a, b, c, d, e, f, g, h);
(gdb) p a
$1 = 42
(gdb) p b
$2 = 43
(gdb) p c
$3 = 44
(gdb) p d
$4 = 
(gdb) p e
$5 = 
(gdb) p f
$6 = 
(gdb) p g
$7 = 
(gdb) p h
$8 = 
(gdb) p $r12
$9 = 


I checked the dwarf:


$ llvm-dwarfdump bar-artificial-mod
[...]
0x009f:   DW_TAG_subprogram
DW_AT_external  (true)
DW_AT_name  ("qux")
DW_AT_decl_line (42)
DW_AT_prototyped(true)
DW_AT_low_pc(0x004011d2)
DW_AT_high_pc   (0x004012db)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_call_all_calls(true)
DW_AT_sibling   (cu + 0x02f0)
[...]
0x00ee: DW_TAG_variable
  DW_AT_name("d")
  DW_AT_decl_line   (47)
  DW_AT_decl_column (0x07)
  DW_AT_type(cu + 0x0060 "int")
[...]
$ objdump -W bar-artificial-mod
[...]
 <2>: Abbrev Number: 2 (DW_TAG_variable)
   DW_AT_name: d
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 47
   DW_AT_decl_column : 7
   DW_AT_type: <0x60>
   DW_AT_location: 0x6e (location list)
   DW_AT_GNU_locviews: 0x6a
[...]
Contents of the .debug_loclists section:
[...]
006e v000 v000 views at 006a for:
 00401216 0040121f (DW_OP_reg0 (rax))
0075 v000 v000 views at 006c for:
 0040121f 004012d1 (DW_OP_reg3 (rbx))
007c 
[...]


The problem is that we are not within the loclist range. So in principle, we
cannot get the value of the variable, the variable is just not visible. But
since gdb is very clever, it searched whether either the value of rax or rbx
from within the loclist range remained somewhere. And apparently, for the
version without the patch, the value of rbx was saved. For the optimized
version with the patch, rbx was not saved, so the value could not been
reconstructed.

In my opinion, it is just fancy that gdb can do that.


Coming back to the "simple.c" example:


$ objdump -W simple
[...]
 <2>: Abbrev Number: 3 (DW_TAG_formal_parameter)
   DW_AT_name: (indirect string, offset: 0x85): argc
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 2
   DW_AT_decl_column : 14
   DW_AT_type: <0x35>
   DW_AT_location: 0x10 (location list)
   DW_AT_GNU_locviews: 0xc
[...]
Contents of the .debug_loclists section:
[...]
0010 v000 v000 views at 000c for:
 00401126 0040112e (DW_OP_reg5 (rdi))
0015 v000 v000 views at 000e for:
 0040112e 0040112f (DW_OP_entry_value: (DW_OP_reg5
(rdi)); DW_OP_stack_value)
001d 
[...]


And rdi was saved nowhere, regardless of the patch. So gdb could not
reconstruct the value of argc.

[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity

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

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

--- Comment #7 from Jakub Jelinek  ---
There is just INTEGER_TYPE test in all graphite*, so
2024-02-27  Jakub Jelinek  

PR tree-optimization/114041
* graphite-sese-to-poly.cc (add_conditions_to_domain): Handle
BITINT_TYPE like INTEGER_TYPE.

* gcc.dg/graphite/run-id-pr114041.c: New test.

--- gcc/graphite-sese-to-poly.cc.jj 2024-01-03 11:51:29.136764430 +0100
+++ gcc/graphite-sese-to-poly.cc2024-02-27 18:56:06.536686265 +0100
@@ -391,8 +391,11 @@ add_conditions_to_domain (poly_bb_p pbb)
   {
   case GIMPLE_COND:
  {
-/* Don't constrain on anything else than INTEGER_TYPE.  */
-   if (TREE_CODE (TREE_TYPE (gimple_cond_lhs (stmt))) != INTEGER_TYPE)
+/* Don't constrain on anything else than INTEGER_TYPE
+  or BITINT_TYPE.  */
+   tree cmp_type = TREE_TYPE (gimple_cond_lhs (stmt));
+   if (TREE_CODE (cmp_type) != INTEGER_TYPE
+   && TREE_CODE (cmp_type) != BITINT_TYPE)
   break;

gcond *cond_stmt = as_a  (stmt);
--- gcc/testsuite/gcc.dg/graphite/run-id-pr114041.c.jj  2024-02-27
18:42:26.864025806 +0100
+++ gcc/testsuite/gcc.dg/graphite/run-id-pr114041.c 2024-02-27
18:43:07.310466262 +0100
@@ -0,0 +1,23 @@
+/* PR tree-optimization/114041 */
+/* { dg-require-effective-target bitint } */
+/* { dg-options "-O -fgraphite-identity" } */
+
+unsigned a[24], b[24];
+
+__attribute__((noipa)) unsigned
+foo (unsigned _BitInt(8) x)
+{
+  for (int i = 0; i < 24; ++i)
+a[i] = i;
+  unsigned e = __builtin_stdc_bit_ceil (x);
+  for (int i = 0; i < 24; ++i)
+b[i] = i;
+  return e;
+}
+
+int
+main ()
+{
+  if (foo (0) != 1)
+__builtin_abort ();
+}

fixes it.

[Bug c++/114138] New: [c++2b] ICE on valid code using `auto(expr)` DECAY-COPY

[eric.niebler at gmail dot com via Gcc-bugs]

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

Bug ID: 114138
   Summary: [c++2b] ICE on valid code using `auto(expr)`
DECAY-COPY
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Compile the following with -c++=2b:


```
namespace std {
  template 
  T&& declval() noexcept requires true;

  template 
  void declval() noexcept;

  namespace detail {
struct none_such;
template 
using none_such_t = none_such;

template 
  extern const none_such_t _getter_for;

template 
using _decay_t = decltype(auto(declval()));

static_assert(__is_same_as(_decay_t, void));
  }

  template 
using _result_of_t = decltype(Fn(declval()...));

  template 
using tuple_element_t =
_result_of_t>, char(*)[I+1],
Tuple>;

  template 
  struct pair {
First first;
Second second;
  };

  template 
inline constexpr bool _is_pair = false;

  template 
inline constexpr bool _is_pair> = true;

  template 
concept Pair = _is_pair()))>;

  template 
requires (I <= 1)
  decltype(auto) get(P&& p) noexcept {
if constexpr (I == 0) {
  return (static_cast(p).first);
} else {
  return (static_cast(p).second);
}
  }

  namespace detail {
inline constexpr auto _pair_getter =
  [](char(*)[J], Pair&& p) noexcept ->
decltype(auto) {
return std::get(static_cast(p));
  };

template 
  inline constexpr auto _getter_for> = _pair_getter;
  }

}

int main() {

  static_assert(__is_same_as(int&, std::tuple_element_t<0, std::pair&>));
  static_assert(__is_same_as(float&&, std::tuple_element_t<1, std::pair&&>));
}
```


Result:

```
: In substitution of 'template using
std::tuple_element_t = std::_result_of_t<_getter_for()))>, char (*)[(I + 1)], Tuple> [with unsigned int I =
0; Tuple = std::pair&]':
:71:82:   required from here
   71 |   static_assert(__is_same_as(int&, std::tuple_element_t<0,
std::pair&>));
  |
 ^
:21:31: internal compiler error: in tsubst, at cp/pt.cc:16367
   21 | using _decay_t = decltype(auto(declval()));
  |   ^~
0x265412c internal_error(char const*, ...)
???:0
0xa548c3 fancy_abort(char const*, int, char const*)
???:0
0xc99307 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9f3c9 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9f3c9 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xc98a19 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc80873 instantiate_template(tree_node*, tree_node*, int)
???:0
0xc9a0fc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc973cc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0xcd370f finish_template_type(tree_node*, tree_node*, int)
???:0
0xc577da c_parse_file()
???:0
0xdaba19 c_common_parse_file()
???:0
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 returned: 1
```

See https://godbolt.org/z/r13Yff5bM

[Bug c++/114135] Diagnostic missing useful information for ranges code

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Huh, I'd expect an "a.k.a 'std:ranges::dangling'" there.

[Bug rtl-optimization/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)

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

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

--- Comment #1 from Sam James  ---
Created attachment 57553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57553=edit
lvm.i

[Bug rtl-optimization/114137] New: ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)

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

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

Bug ID: 114137
   Summary: ICE when building lua-5.4.6 with
-fharden-control-flow-redundancy on x86 (error:
invalid rtl sharing found in the insn)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

```
libtool: compile:  i686-pc-linux-gnu-gcc -DPACKAGE_NAME=\"lua5.4\"
-DPACKAGE_TARNAME=\"lua\" -DPACKAGE_VERSION=\"5.4.6\"
"-DPACKAGE_STRING=\"lua5.4 5.4.6\""
-DPACKAGE_BUGREPORT=\"https://bugs.gentoo.org/\;
-DPACKAGE_URL=\"http://www.lua.org\; -DPACKAGE=\"lua\" -DVERSION=\"5.4.6\"
-DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-DLUA_USE_READLINE=1 -DLUA_USE_LINUX=1 -I. -I./src -DLUA_COMPAT_5_3 -Wall -O3
-pipe -march=i686 -fdiagnostics-color=always -mfpmath=sse -msse -msse2
-fno-vect-cost-model -fharden-control-flow-redundancy -fpermissive -c src/lvm.c
 -fPIC -DPIC -o src/.libs/lvm.o
src/lvm.c: In function 'luaV_execute':
src/lvm.c:1899:1: error: invalid rtl sharing found in the insn
 1899 | }
  | ^
(insn 13766 3884 3886 347 (set (reg:SI 5300)
(reg:SI 7643)) "src/lvm.c":1432:9 discrim 3 -1
 (expr_list:REG_EQUAL (plus:SI (reg:SI 98)
(const:SI (unspec:SI [
(mem/c:BLK (plus:SI (reg/f:SI 19 frame)
(const_int -140 [0xff74])) [14
.cfrvisited.1003+0 S136 A32])
] UNSPEC_GOTOFF)))
(nil)))
src/lvm.c:1899:1: error: shared rtx
(mem/c:BLK (plus:SI (reg/f:SI 19 frame)
(const_int -140 [0xff74])) [14 .cfrvisited.1003+0 S136
A32])
during RTL pass: rtl pre
src/lvm.c:1899:1: internal compiler error: internal consistency failure
0x56ebaa07 verify_rtx_sharing
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3046
0x5873fc59 verify_rtx_sharing
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3079
0x5873fbac verify_rtx_sharing
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3061
0x5873fbac verify_rtx_sharing
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3061
0x5873fbac verify_rtx_sharing
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3061
0x5873bd69 verify_insn_sharing
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3132
0x5873bd69 verify_rtl_sharing()
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/emit-rtl.cc:3154
0x5837fa6c execute_function_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2109
0x5837fa6c do_per_function
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687
0x5837fa6c execute_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142
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.
make[1]: *** [Makefile:731: src/lvm.lo] Error 1
make[1]: Leaving directory '/var/tmp/portage/dev-lang/lua-5.4.6/work/lua-5.4.6'
make: *** [Makefile:484: all] Error 2
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/14/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0./work/gcc-14.0./configure
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/i686-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 e54a7fbca63053b5753fd9ba543c27ef392d3084' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --with-arch=i686 --enable-targets=all
--enable-libgomp --disable-libssp 

[Bug target/113871] psrlq is not used for PERM

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:15d1dae0d4d1be88d28ad7578a60fd3e36de36d8

commit r14-9198-g15d1dae0d4d1be88d28ad7578a60fd3e36de36d8
Author: Uros Bizjak 
Date:   Tue Feb 27 18:41:24 2024 +0100

i386: psrlq is not used for PERM [PR113871]

Also handle V2BF mode.

PR target/113871

gcc/ChangeLog:

* config/i386/mmx.md (V248FI): Add V2BF mode.
(V24FI_32): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr113871-5a.c: New test.
* gcc.target/i386/pr113871-5b.c: New test.

[Bug modula2/113768] gm2/extensions/run/pass/vararg2.mod FAILs

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Thanks this is a duplicate of Bug 114133 (or visa versa).

[Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||testsuite-fail

--- Comment #1 from Andrew Pinski  ---
The following testcases fail because of this:

FAIL: gcc.dg/c23-stdarg-4.c execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -O0  execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -O1  execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -O2  execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -O3 -g  execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c   -Os  execution test

[Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

[Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm

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

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

Bug ID: 114136
   Summary: wrong code for c23 fully anonymous arg lists on arm
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
  Target Milestone: ---
Target: arm

On arm, a fully anonymous c23-style function is called incorrectly.  All
arguments are passed on the stack while the receiving function expects r0-r3 to
be used for the initial arguments.

For example,

void f (...);

void g()
{
f (1, 2, 3, 4);
}

With gcc compiles to:

g:
push{lr}
movsr0, #1
movsr1, #2
sub sp, sp, #20
movsr2, #3
movsr3, #4
stm sp, {r0, r1, r2, r3}  // Arguments pushed to stack (wrong)
bl  f
add sp, sp, #20
ldr pc, [sp], #4

When the correct code (eg, as produced by clang) is something like

g:
mov r0, #1
mov r1, #2
mov r2, #3
mov r3, #4
b   f

compile with, eg 

arm-non-eabi-gcc -O2 -c23

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

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

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

--- Comment #37 from Jakub Jelinek  ---
Nowhere, just run and when it stops due to abort, just up several times until
reaching the appropriate frame.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #36 from Lukas Grätz  ---
(In reply to Jakub Jelinek from comment #35)
> If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
> + .cfi_undefined 3
> + .cfi_undefined 12
> + .cfi_undefined 13
> + .cfi_undefined 14
> + .cfi_undefined 15
> then bt in gdb shows
> #2  0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> d=, 
> e=, f= reading variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38


I can confirm that. What bothers me, is the wording "d=" and not just "d=".


(gdb) run
Starting program: bar-artificial-mod 

Program received signal SIGABRT, Aborted.

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77dcd859 in __GI_abort () at abort.c:79
#2  0x004011b1 in bar () at bar-artificial.c:30
#3  0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
d=,
e=,
f=,
g=48, h=49) at bar-artificial.c:38
#4  0x004012aa in qux () at bar-artificial.c:55
#5  0x004012e4 in main () at bar-artificial.c:62

(gdb) p a
No symbol "a" in current context.
(gdb) p b
No symbol "b" in current context.


> and everything in qux live across the call is  as well,
> (gdb) p $r12
> $10 = 
> etc. while without that
> (gdb) p a
> $1 = 
> (gdb) p b
> $2 = 
> (gdb) p c
> $3 = 
> (gdb) p d
> $4 = -559038737
> (gdb) p e
> $5 = -559038737
> (gdb) p f
> $6 = -559038737
> (gdb) p g
> $7 = -559038737
> (gdb) p h
> $8 = -559038737
> (gdb) p $r12
> $9 = 3735928559


Where did you set the breakpoint? When I set it somewhere in qux (after
a,b,c,... were initialized), I get conclusive results:


(gdb) break bar-artificial.c:52
Breakpoint 1 at 0x40124a: file bar-artificial.c, line 52.
(gdb) run
Breakpoint 1, qux () at bar-artificial.c:52
52corge (__builtin_alloca (foo (52)));
(gdb) p a
$1 = 42
(gdb) p b
$2 = 43
(gdb) p c
$3 = 44
(gdb) p d
$4 = 45
(gdb) p e 
$5 = 46
(gdb) p f
$6 = 47
(gdb) p g
$7 = 48
(gdb) p h
$8 = 49
(gdb) p $r12
$9 = 46

[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity

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

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

--- Comment #6 from Jakub Jelinek  ---
unsigned a[24], b[24];

__attribute__((noipa)) unsigned
foo (unsigned char x)
{
  for (int i = 0; i < 24; ++i)
a[i] = i;
  unsigned e = __builtin_stdc_bit_ceil (x);
  for (int i = 0; i < 24; ++i)
b[i] = i;
  return e;
}

int
main ()
{
  if (foo (0) != 1)
__builtin_abort ();
}

works right, but s/unsigned char/unsigned _BitInt(8)/ does not, so it must be
something in graphite that handles INTEGER_TYPE and not all integral types.

[Bug c++/114135] New: Diagnostic missing useful information for ranges code

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 114135
   Summary: Diagnostic missing useful information for ranges code
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This is an example using Ranges:

#include 
#include 
using namespace std;

int main() {
auto rng = views::iota(0, 3);
const auto [a, b] = * ranges::min_element(views::cartesian_product(rng,
rng));
return 0;
}

This is an ill-formed program, the error given by gcc trunk is:

:7:25: error: no match for 'operator*' (operand type is
'std::ranges::borrowed_iterator_t, std::ranges::iota_view > >')
7 | const auto [a, b] = *
ranges::min_element(views::cartesian_product(rng, rng));
  |
^

This is all correct. However, it would be more helpful in this case for the
reader to also note that the type
std::ranges::borrowed_iterator_t is actually the type
std::ranges::dangling. Seeing "dangling" in the error message makes it a lot
easier to understand what the issue here actually is.

[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity

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

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

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase:

unsigned a[24], b[24];

__attribute__((noipa)) unsigned
foo (unsigned _BitInt(4) x)
{
  for (int i = 0; i < 24; ++i)
a[i] = i;
  unsigned e = __builtin_stdc_bit_ceil (x);
  for (int i = 0; i < 24; ++i)
b[i] = i;
  return e;
}

int
main ()
{
  if (foo (0) != 1)
__builtin_abort ();
}

I have to confirm Andrew's comment, before the graphite dump there was
  if (x_14(D) > 1)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 17609365]:
  goto ; [100.00%]

   [local count: 25340307]:
  _2 = x_14(D) + 15;
  _3 = (unsigned int) _2;
  _4 = __builtin_clz (_3);
  _5 = 31 - _4;
  _6 = 2 << _5;
  iftmp.1_15 = (unsigned int) _6;

   [local count: 42949672]:
  # iftmp.1_10 = PHI 
This isn't part of any kind of loop, it is in between 2 different loops.
Graphite hoists some of the statements to bb 2 where it is unconditional:
  _32 = x_14(D) + 15;
  _33 = (unsigned int) _32;
the rest of it remains after the first loop, but is now unconditional:
   [count: 0]:
  _47 = 1;
  _31 = __builtin_clz (_33);
  _34 = 31 - _31;
  _35 = 2 << _34;
  iftmp.1_36 = (unsigned int) _35;
  _48 = iftmp.1_36;
  iftmp.1_37 = _48;
In the testcase x is 0, so __builtin_stdc_bit_ceil returns 1, but when we take
the > 1
path, it is 2 << (31 - 24) instead.
The above feels like what ifcvt would do, if that _47 in there stands for one
of the phi arguments and _48 for the other.  Except __builtin_clz invokes UB
when run on 0 (which is one of the reasons why it was guarded) and there is no
conditional merging at the end.

[Bug c++/114013] [14 Regression] Specializations of var templates no longer emitted since r14-8987

[enrico.seiler+gccbugs at outlook dot com via Gcc-bugs]

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

--- Comment #3 from Enrico Seiler  ---
For -O0 and -O1, this also does not link:

template  int value;
template <> inline int value<1>;
void bar(int) { bar(value<1>); }

https://godbolt.org/z/Wxv7PE8ob

[Bug c++/101443] [9/10 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519

[rawiener at amazon dot com via Gcc-bugs]

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

Rafi Wiener  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #14 from Rafi Wiener  ---
thanks

[Bug modula2/114133] problem passing a string pointer to a C function on solaris 32 bit and 64 bit

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

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

--- Comment #3 from Gaius Mulley  ---
At a guess the problem was the ZTyped constant (1 and 5).  Now the gimple IR
shows these constants as integers:

$ cat callingc10.mod.095i.comdats
PROC _M2_callingc10_init (INTEGER argc, PROC * argv, PROC * envp)
{
  INTEGER D.676;
  INTEGER D.675;
  INTEGER D.674;
  INTEGER _T35.0_1;
  PROC * _T36.1_2;
  INTEGER _T34.2_3;
  INTEGER _4;
  INTEGER _T37.3_5;
  INTEGER _T39.4_6;
  PROC * _T40.5_7;
  INTEGER _T38.6_8;
  INTEGER _9;
  INTEGER _T41.7_10;
  INTEGER _T43.8_11;
  PROC * _T44.9_12;
  INTEGER _T42.10_13;
  INTEGER _14;
  INTEGER _20;
  INTEGER _26;
  INTEGER _32;

   :
  _T34 = 1;
  _T35 = 5;
  _T36 = "hello";
  _T35.0_1 = _T35;
  _T36.1_2 = _T36;
  _T34.2_3 = _T34;
  _20 = funcptr (_T34.2_3, _T36.1_2, _T35.0_1);
  _4 = _20;
  _T37 = _4;
  _T37.3_5 = _T37;

[Bug c++/114134] New: Extra mov instructions for simple function compared with GCC13

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 114134
   Summary: Extra mov instructions for simple function compared
with GCC13
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

In the example below, the function `Key` has some extra (useless?) mov
instructions that are not generated with GCC 13.

$ cat borrar.cpp 

#include 

struct TVec3D { double x, y, z; };

struct TKey { int i, j, k; };

extern double const BinSize;

inline int Index(double const x)
  { return static_cast(std::floor(static_cast(x / BinSize + 1.0) -
1.0f)); };

TKey Key(TVec3D const )
  { return {Index(r.x), Index(r.y), Index(r.z)}; }


$ ./gcc-13/bin/g++ -O3 -march=skylake -fno-trapping-math -S borrar.cpp -o-
.file   "borrar.cpp"
.text
.p2align 4
.globl  _Z3KeyRK6TVec3D
.type   _Z3KeyRK6TVec3D, @function
_Z3KeyRK6TVec3D:
.LFB993:
.cfi_startproc
vmovsd  BinSize(%rip), %xmm1
vmovupd (%rdi), %xmm3
vmovddup.LC1(%rip), %xmm2
vmovddup%xmm1, %xmm0
vdivpd  %xmm0, %xmm3, %xmm0
vaddpd  %xmm2, %xmm0, %xmm0
vmovq   .LC2(%rip), %xmm2
vcvtpd2psx  %xmm0, %xmm0
vaddps  %xmm2, %xmm0, %xmm0
vroundps$9, %xmm0, %xmm0
vcvttps2dq  %xmm0, %xmm4
vmovsd  16(%rdi), %xmm0
vmovq   %xmm4, %rax
vdivsd  %xmm1, %xmm0, %xmm0
vaddsd  .LC1(%rip), %xmm0, %xmm0
vcvtsd2ss   %xmm0, %xmm0, %xmm0
vsubss  .LC3(%rip), %xmm0, %xmm0
vroundss$9, %xmm0, %xmm0, %xmm0
vcvttss2sil %xmm0, %edx
movl%edx, %edx
ret
.cfi_endproc
.LFE993:
.size   _Z3KeyRK6TVec3D, .-_Z3KeyRK6TVec3D
.section.rodata.cst8,"aM",@progbits,8
.align 8
.LC1:
.long   0
.long   1072693248
.align 8
.LC2:
.long   -1082130432
.long   -1082130432
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC3:
.long   1065353216
.ident  "GCC: (GNU) 13.1.0"
.section.note.GNU-stack,"",@progbits


$ ./gcc-14/bin/g++ -O3 -march=skylake -fno-trapping-math -S borrar.cpp -o-
.file   "borrar.cpp"
.text
.p2align 4
.globl  _Z3KeyRK6TVec3D
.type   _Z3KeyRK6TVec3D, @function
_Z3KeyRK6TVec3D:
.LFB1032:
.cfi_startproc
vmovsd  BinSize(%rip), %xmm2
vmovupd (%rdi), %xmm0
vmovddup%xmm2, %xmm1
vdivpd  %xmm1, %xmm0, %xmm0
vmovddup.LC1(%rip), %xmm1
vaddpd  %xmm1, %xmm0, %xmm0
vmovq   .LC2(%rip), %xmm1
vcvtpd2psx  %xmm0, %xmm0
vaddps  %xmm1, %xmm0, %xmm0
vroundps$9, %xmm0, %xmm0
vcvttps2dq  %xmm0, %xmm0
vmovq   %xmm0, %rdx
vmovsd  16(%rdi), %xmm0
vdivsd  %xmm2, %xmm0, %xmm0
vaddsd  .LC1(%rip), %xmm0, %xmm0
vcvtsd2ss   %xmm0, %xmm0, %xmm0
vsubss  .LC3(%rip), %xmm0, %xmm0
vroundss$9, %xmm0, %xmm0, %xmm0
vcvttss2sil %xmm0, %eax
movl%eax, %eax
movq%rax, %rdi
movq%rdx, %rax
movq%rdi, %rdx
ret
.cfi_endproc
.LFE1032:
.size   _Z3KeyRK6TVec3D, .-_Z3KeyRK6TVec3D
.section.rodata.cst8,"aM",@progbits,8
.align 8
.LC1:
.long   0
.long   1072693248
.align 8
.LC2:
.long   -1082130432
.long   -1082130432
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC3:
.long   1065353216
.ident  "GCC: (GNU) 14.0.0 20240112 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug modula2/114133] problem passing a string pointer to a C function on solaris 32 bit and 64 bit

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

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

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

Does this patch fix the problem?

[Bug tree-optimization/114121] wrong code with _BitInt() arithmetics at -O2

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

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

--- Comment #14 from Jakub Jelinek  ---
Tried 
__attribute__((noipa)) unsigned long
foo (unsigned long x)
{
  unsigned long y[128], z = 0, w = 0;
  y[127] = x;
  __builtin_memset (, 0, 127 * sizeof (long));
  for (unsigned long i = 0; i < 128; i += 2)
{
  unsigned long a = y[i], b, c, d;
  b = __builtin_subcl (0, a, z, );
  z = c;
  if (i >= 64)
{
  if (i == 64)
w = c != 0;
  else
w = (c != 0) | w;
}
  d = i + 1;
  a = y[d];
  b = __builtin_subcl (0, a, z, );
  z = c;
  if (d > 64)
w = (c != 0) | w;
}
  return w;
}
but that doesn't reproduce it unfortunately.

[Bug modula2/114133] problem passing a string pointer to a C function on solaris 32 bit and 64 bit

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
The gimple IR looks correct, given the input code:

MODULE callingc10 ;

FROM cvararg IMPORT funcptr ;
FROM SYSTEM IMPORT ADR ;

BEGIN
   IF funcptr (1, "hello", 5) = 1
   THEN
   END ;
   IF funcptr (1, "hello" + " ", 6) = 1
   THEN
   END ;
   IF funcptr (1, "hello" + " " + "world", 11) = 1
   THEN
   END
END callingc10.

$ gm2 -g callingc10.mod -c -fdump-ipa-all
$ cat callingc10.mod.095i.comdats
...
PROC _M2_callingc10_init (INTEGER argc, PROC * argv, PROC * envp)
{
  INTEGER D.670;
  INTEGER D.669;
  INTEGER D.668;
  PROC * _T34.0_1;
  INTEGER _2;
  INTEGER _T35.1_3;
  PROC * _T36.2_4;
  INTEGER _5;
  INTEGER _T37.3_6;
  PROC * _T38.4_7;
  INTEGER _8;
  INTEGER _12;
  INTEGER _16;
  INTEGER _20;

   :
  _T34 = "hello";
  _T34.0_1 = _T34;
  _12 = funcptr (1, _T34.0_1, 5);
  _2 = _12;
  _T35 = _2;
  _T35.1_3 = _T35;

...

[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

--- Comment #31 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #30)
> Either tree parmdef = ssa_default_def (cfun, parm) is NULL, or has_zero_uses
> (parmdef).
> Not sure if has_zero_uses will work properly after some bbs are converted
> from GIMPLE to RTL, but maybe it will, I think the expansion generally
> doesn't gsi_remove statements it expands nor calls update_stmt on them.  One
> could always also just compute in generic code at the start of expansion the
> number of unused DECL_HIDDEN_STRING_LENGTH PARM_DECLs at the end of the
> argument list, save that as a flag in struct function or where and let the
> backends use it from there.

Ok, I think that gives us some idea what needs to be done.  I'll look for
someone in the team to have a look at implementing this workaround.  Thanks.

[Bug target/110411] ICE on simple memcpy test case when allowing generation of vector pair load/store insns

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

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

Jeevitha  changed:

   What|Removed |Added

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

--- Comment #8 from Jeevitha  ---
Fixed

[Bug target/110320] ELFv2 pc-rel ABI extension allows using r2 as a volatile register

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

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

Jeevitha  changed:

   What|Removed |Added

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

--- Comment #3 from Jeevitha  ---
Fixed

[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?

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

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

Jeevitha  changed:

   What|Removed |Added

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

--- Comment #11 from Jeevitha  ---
Fixed

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

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

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

Bug 106907 Summary: gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907

   What|Removed |Added

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

[Bug modula2/114026] incorrect location during for loop type check

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #6 from Gaius Mulley  ---
ah I'll open up a new PR as this is now a bug relating to passing a pointer
string to a C function.

For clarity and future searching the new PR follow on is:

Bug 114133 - problem passing a string pointer to a C function on solaris 32 bit
and 64 bit

marking the original FOR loop issue as resolved.

[Bug modula2/114133] New: problem passing a string pointer to a C function on solaris 32 bit and 64 bit

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

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

Bug ID: 114133
   Summary: problem passing a string pointer to a C function on
solaris 32 bit and 64 bit
   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: ---

This is a follow on from:

Bug 114026 - incorrect location during for loop type check

which occurred when I added a new testcase and was reported as failing:


Two of the new tests FAIL on 32 and 64-bit Solaris/SPARC:

+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O -g 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O3
-fomit-frame-point
er 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O3
-fomit-frame-point
er -finline-functions 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -Os 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -g 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O -g 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O3
-fomit-frame-pointer 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O3
-fomit-frame-pointer -finline-functions 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -Os 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -g 

The failure mode is the same for both:

parameter is hello and length 0
executed
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/gm2/callingc10.x0 with
result fail

[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform

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

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

--- Comment #11 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -1824,11 +1824,14 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 }

 #if __cpp_lib_three_way_comparison
-  // Iter points to a contiguous range of unsigned narrow character type
-  // or std::byte, suitable for comparison by memcmp.
-  template
-concept __is_byte_iter = contiguous_iterator<_Iter>
-  && __is_memcmp_ordered>::__value;
+  // Both iterators refer to contiguous ranges of unsigned narrow characters,
+  // or std::byte, or big-endian unsigned integers, suitable for comparison
+  // using memcmp.
+  template
+concept __memcmp_ordered_with
+  = (__is_memcmp_ordered_with,
+ iter_value_t<_Iter2>>::__value)
+ && contiguous_iterator<_Iter1> && contiguous_iterator<_Iter2>;

   // Return a struct with two members, initialized to the smaller of x and y
   // (or x if they compare equal) and the result of the comparison x <=> y.
@@ -1878,20 +1881,20 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   if (!std::__is_constant_evaluated())
if constexpr (same_as<_Comp, __detail::_Synth3way>
  || same_as<_Comp, compare_three_way>)
- if constexpr (__is_byte_iter<_InputIter1>)
-   if constexpr (__is_byte_iter<_InputIter2>)
- {
-   const auto [__len, __lencmp] = _GLIBCXX_STD_A::
- __min_cmp(__last1 - __first1, __last2 - __first2);
-   if (__len)
- {
-   const auto __c
- = __builtin_memcmp(&*__first1, &*__first2, __len) <=> 0;
-   if (__c != 0)
- return __c;
- }
-   return __lencmp;
- }
+ if constexpr (__memcmp_ordered_with<_InputIter1, _InputIter2>)
+   {
+ const auto [__len, __lencmp] = _GLIBCXX_STD_A::
+   __min_cmp(__last1 - __first1, __last2 - __first2);
+ if (__len)
+   {
+ const auto __blen = __len * sizeof(*__first1);
+ const auto __c
+   = __builtin_memcmp(&*__first1, &*__first2, __blen) <=> 0;
+ if (__c != 0)
+   return __c;
+   }
+ return __lencmp;
+   }

   while (__first1 != __last1)
{

[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform

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

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

--- Comment #10 from Jonathan Wakely  ---
Oh I already defined a __is_memcmp_ordered_with trait, which does the same-size
check. I think that's what should be used here.

[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #9 from Stefan Schulze Frielinghaus  
---
(In reply to Jonathan Wakely from comment #7)
> We can't use memcmp if the sizes are different. We don't want to use the
> min, we want to guard that code with the sizes being the same, then we can
> just use len*sizeof(*first1) because we know it's the same as
> sizeof(*first2).

Hehe I was about to add another comment.  I just confused myself with taking
the minimum but we rather need to ensure that we are walking over same sized
integers.

LGTM