[Bug fortran/80235] ICE: coarrays, submodule

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/117172] FAIL: gcc.target/i386/pr111820-2.c and gcc.target/i386/pr111820-3.c with forced SLP

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I'll look at this next.

[Bug middle-end/116510] [15 Regression] ice in decompose, at wide-int.h:1049

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Biener  ---
Fixed.

A bug in gcc-13.2.0-llvm-17.0.5-mingw-w64ucrt-11.0.1-r3 with the -O3 option

[Сергей via Gcc-bugs]

Hello All,
 
 I found a bug in gcc-13.2.0-llvm-17.0.5-mingw-w64ucrt-11.0.1-r3 for Windows.
This bug occurs when translating the file "bug.c" with the -O3 option. There is 
no error when translating it with the -O2 option.
To check this bug, download bug.c file and other files from Google disk:
https://drive.google.com/file/d/1Ii0HGuVFhC6iuNM1ArnVNcAspVi_W79T/view?usp=drive_link
 
--
Regards,
 Serge

[Bug target/117185] Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> (In reply to Richard Biener from comment #2)
> > I would suggest to change reload_in_progress || lra_in_progress back to
> > just reload_in_progress for resolve_reload_operand - this code can't work
> > for LRA.
> 
> OK, I'll give it a try.

It fails in get_unaligned_address() now:

during RTL pass: reload
../../../libgomp/target.c: In function 'gomp_map_vars_existing':
checking for unistd.h... ../../../libgomp/target.c:661:1: internal compiler
error: in get_unaligned_address, at config/alpha/alpha.cc:1577
  661 | }
  | ^
yes
mv -f .deps/oacc-mem.Tpo .deps/oacc-mem.Plo
checking for dlfcn.h... 0x1232b5033 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x1232676d7 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1533
0x121f528bf get_unaligned_address(rtx_def*)
../../gcc/config/alpha/alpha.cc:1577
0x121f55e03 alpha_expand_mov_nobwx(machine_mode, rtx_def**)
../../gcc/config/alpha/alpha.cc:2346
0x122c4f6c3 gen_movqi(rtx_def*, rtx_def*)
../../gcc/config/alpha/alpha.md:4241
0x120bd8057 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
../../gcc/recog.h:442
0x120eb866f emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.cc:4577
0x120eb9747 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.cc:4747
0x12137c6bb lra_emit_move(rtx_def*, rtx_def*)
../../gcc/lra.cc:509
0x1213a523b curr_insn_transform
../../gcc/lra-constraints.cc:4750
0x1213a8ed7 lra_constraints(bool)
../../gcc/lra-constraints.cc:5496
0x121384443 lra(_IO_FILE*, int)
../../gcc/lra.cc:2445
0x1212fa08f do_reload
../../gcc/ira.cc:5977
0x1212fa9a7 execute
../../gcc/ira.cc:6165
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.

Is that another case which should be reload-only?

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #12 from Alejandro Colomar  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Alejandro Colomar from comment #9)
> > 
> > I think it's simpler to have -Wc++-compat warn about any uses of
> > [[gnu::nonstring]] at all, since C++ does not want such thing.  That would
> > cover all cases of unterminated initializations, so would keep Andrew happy,
> > I think.  Does it, Andrew?
> 
> No because nonstring is still useful for C++ as it has nothing to do with
> string literals. You just want to connect the two ideas because in C string
> literals either can be with or without the nul terminating character (which
> is unlike C++ where it is always with the nul terminating character).

So, in C++ you are happy to have nonstring char*, but don't want to initialize
them from string literals.  I don't see why you would want to forbid that. 
Anyway, I think C shouldn't be bothered by C++'s design choices.  Maybe
-Wc++-compat could be the trigger for warning about those cases.  Or maybe you
could add -Wunterminated-string-initialization-c++ that is more noisy than the
usual one.

Or you could add an attribute for a string literal, but that would probably be
complex.  Are there any attributes that can be applied to lvalues?

[Bug target/116590] unrecognized opcode th.vmv8r.v th.vfrec7.v when compiling for risc-v xtheadvector

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

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

Christoph Müllner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |cooper.qu at linux dot 
alibaba.com
 Ever confirmed|0   |1
   Last reconfirmed|2024-09-04 00:00:00 |2024-10-17

[Bug target/116591] internal compiler error: in extract_insn when compiling for risc-v xtheadvector

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

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

Christoph Müllner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
   Last reconfirmed||2024-10-17
   Assignee|unassigned at gcc dot gnu.org  |cooper.qu at linux dot 
alibaba.com
 Ever confirmed|0   |1

[Bug target/116593] internal compiler error: in get_attr_type, at config/riscv/riscv.md:28048 with -O2 -O3 when compiling for risc-v xtheadvector

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

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

Christoph Müllner  changed:

   What|Removed |Added

 Target|Riscv   |riscv
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |cooper.qu at linux dot 
alibaba.com
   Last reconfirmed||2024-10-17

[Bug target/117184] New: m2 fails with "terminate called after throwing an instance of 'unsigned int'" with LRA on alpha

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 117184
   Summary: m2 fails with "terminate called after throwing an
instance of 'unsigned int'" with LRA on alpha
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: macro at orcam dot me.uk, mcree at orcon dot net.nz,
ubizjak at gmail dot com
  Target Milestone: ---
  Host: alpha-*-*

Trying to bootstrap GCC with LRA enabled on alpha with --with-cpu=ev56 fails
while building m2 with:

m2/pge -k -l ../../gcc/m2/gm2-compiler/P2Build.bnf -o
m2/gm2-compiler-boot/P2Build.mod
m2/pge -k -l ../../gcc/m2/gm2-compiler/P3Build.bnf -o
m2/gm2-compiler-boot/P3Build.mod
m2/pge -k -l ../../gcc/m2/gm2-compiler/PHBuild.bnf -o
m2/gm2-compiler-boot/PHBuild.mod
m2/pge -k -l ../../gcc/m2/gm2-compiler/PCBuild.bnf -o
m2/gm2-compiler-boot/PCBuild.mod
m2/pge -k -l ../../gcc/m2/gm2-compiler/P1Build.bnf -o
m2/gm2-compiler-boot/P1Build.mod
m2/pge -k -l ../../gcc/m2/gm2-compiler/P0SyntaxCheck.bnf -o
m2/gm2-compiler-boot/P0SyntaxCheck.mod
terminate called after throwing an instance of 'unsigned int'
make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P2Build.mod]
Aborted
make[3]: *** Deleting file 'm2/gm2-compiler-boot/P2Build.mod'
make[3]: *** Waiting for unfinished jobs
terminate called after throwing an instance of 'unsigned int'
make[3]: *** [../../gcc/m2/Make-lang.in:1778:
m2/gm2-compiler-boot/P0SyntaxCheck.mod] Aborted
make[3]: *** Deleting file 'm2/gm2-compiler-boot/P0SyntaxCheck.mod'
terminate called after throwing an instance of 'unsigned int'
make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P1Build.mod]
Aborted
make[3]: *** Deleting file 'm2/gm2-compiler-boot/P1Build.mod'
terminate called after throwing an instance of 'unsigned int'
make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P3Build.mod]
Aborted
make[3]: *** Deleting file 'm2/gm2-compiler-boot/P3Build.mod'
terminate called after throwing an instance of 'unsigned int'
make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PHBuild.mod]
Aborted
make[3]: *** Deleting file 'm2/gm2-compiler-boot/PHBuild.mod'
terminate called after throwing an instance of 'unsigned int'
make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PCBuild.mod]
Aborted
make[3]: *** Deleting file 'm2/gm2-compiler-boot/PCBuild.mod'
rm gfdl.pod gcc.pod gfortran.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod
gpl.pod cpp.pod gcov.pod lto-dump.pod
make[3]: Leaving directory '/home/glaubitz/gcc.git/build/gcc'
make[2]: *** [Makefile:5100: all-stage2-gcc] Error 2
make[2]: Leaving directory '/home/glaubitz/gcc.git/build'
make[1]: *** [Makefile:26844: stage2-bubble] Error 2
make[1]: Leaving directory '/home/glaubitz/gcc.git/build'
make: *** [Makefile:1105: all] Error 2

Disabling m2 makes the bootstrap build succeed with LRA enabled.

[Bug target/117185] New: Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 117185
   Summary: Bootstrap fails with ICE: in operator[], at vec.h:910
with LRA on non-BWX alpha
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: macro at orcam dot me.uk, mcree at orcon dot net.nz,
sjames at gcc dot gnu.org, ubizjak at gmail dot com
  Target Milestone: ---
  Host: alpha-*-*

When trying to bootstrap GCC with the default baseline (non-BWX) on alpha with
LRA enabled, the build fails with:

during RTL pass: reload
../../../libgomp/team.c: In function 'gomp_team_start':
mv -f .deps/bar.Tpo .deps/bar.Plo
../../../libgomp/team.c:940:1: internal compiler error: in operator[], at
vec.h:910
  940 | }
  | ^
yes
checking for /home/glaubitz/gcc.git/build/./gcc/xgcc
-B/home/glaubitz/gcc.git/build/./gcc/ -B/usr/local/alpha-unknown-linux-gnu/bin/
-B/usr/local/alpha-unknown-linux-gnu/lib/ -isystem
/usr/local/alpha-unknown-linux-gnu/include -isystem
/usr/local/alpha-unknown-linux-gnu/sys-include   -fno-checking option to accept
ISO C89... libtool: compile:  /home/glaubitz/gcc.git/build/./gcc/xgcc
-B/home/glaubitz/gcc.git/build/./gcc/ -B/usr/local/alpha-unknown-linux-gnu/bin/
-B/usr/local/alpha-unknown-linux-gnu/lib/ -isystem
/usr/local/alpha-unknown-linux-gnu/include -isystem
/usr/local/alpha-unknown-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H
-I. -I../../../libgomp -I../../../libgomp/config/linux/alpha
-I../../../libgomp/config/linux -I../../../libgomp/config/posix
-I../../../libgomp -I../../../libgomp/../include -Wall -ftls-model=initial-exec
-pthread -DUSING_INITIAL_EXEC_TLS -g -O2 -mieee -MT oacc-init.lo -MD -MP -MF
.deps/oacc-init.Tpo -c ../../../libgomp/oacc-init.c -o oacc-init.o >/dev/null
2>&1
libtool: compile:  /home/glaubitz/gcc.git/build/./gcc/xgcc
-B/home/glaubitz/gcc.git/build/./gcc/ -B/usr/local/alpha-unknown-linux-gnu/bin/
-B/usr/local/alpha-unknown-linux-gnu/lib/ -isystem
/usr/local/alpha-unknown-linux-gnu/include -isystem
/usr/local/alpha-unknown-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H
-I. -I../../../libgomp -I../../../libgomp/config/linux/alpha
-I../../../libgomp/config/linux -I../../../libgomp/config/posix
-I../../../libgomp -I../../../libgomp/../include -Wall -ftls-model=initial-exec
-pthread -DUSING_INITIAL_EXEC_TLS -g -O2 -mieee -MT ordered.lo -MD -MP -MF
.deps/ordered.Tpo -c ../../../libgomp/ordered.c -o ordered.o >/dev/null 2>&1
libtool: compile:  /home/glaubitz/gcc.git/build/./gcc/xgcc
-B/home/glaubitz/gcc.git/build/./gcc/ -B/usr/local/alpha-unknown-linux-gnu/bin/
-B/usr/local/alpha-unknown-linux-gnu/lib/ -isystem
/usr/local/alpha-unknown-linux-gnu/include -isystem
/usr/local/alpha-unknown-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H
-I. -I../../../libgomp -I../../../libgomp/config/linux/alpha
-I../../../libgomp/config/linux -I../../../libgomp/config/posix
-I../../../libgomp -I../../../libgomp/../include -Wall -ftls-model=initial-exec
-pthread -DUSING_INITIAL_EXEC_TLS -g -O2 -mieee -MT loop_ull.lo -MD -MP -MF
.deps/loop_ull.Tpo -c ../../../libgomp/loop_ull.c -o loop_ull.o >/dev/null 2>&1
0x1232b5047 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x1232676eb fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1533
0x120be06f3 vec::operator[](unsigned int)
../../gcc/vec.h:910
0x121f4eb57 resolve_reload_operand(rtx_def*)
../../gcc/config/alpha/alpha.cc:684
0x122c6bd43 aligned_memory_operand(rtx_def*, machine_mode)
../../gcc/config/alpha/predicates.md:428
0x121f55a0b alpha_expand_mov_nobwx(machine_mode, rtx_def**)
../../gcc/config/alpha/alpha.cc:2294
0x122c4f6d7 gen_movqi(rtx_def*, rtx_def*)
../../gcc/config/alpha/alpha.md:4241
0x120bd8057 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
../../gcc/recog.h:442
0x120eb866f emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.cc:4577
0x120eb9747 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.cc:4747
0x12137c6bb lra_emit_move(rtx_def*, rtx_def*)
../../gcc/lra.cc:509
none needed
checking whether /home/glaubitz/gcc.git/build/./gcc/xgcc
-B/home/glaubitz/gcc.git/build/./gcc/ -B/usr/local/alpha-unknown-linux-gnu/bin/
-B/usr/local/alpha-unknown-linux-gnu/lib/ -isystem
/usr/local/alpha-unknown-linux-gnu/include -isystem
/usr/local/alpha-unknown-linux-gnu/sys-include   -fno-checking understands -c
and -o together... 0x1213a523b curr_insn_transform
../../gcc/lra-constraints.cc:4750
0x1213a8ed7 lra_constraints(bool)
../../gcc/lra-constraints.cc:5496
0x121384443 lra(_IO_FILE*, int)
../../gcc/lra.cc:2445
0x1212fa08f do_reload
../../gcc/ira.cc:5977
0x1212fa9a7 execute
../../gc

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #68 from Julian Waters  ---
I don't know why but apparently using force_reg and copy_to_mode_reg to load
into registers instead of using gen_rtx_SET and emit_insn fixes the garbage
movabsq instructions. I was going to ask why, but I suspect the reason is
buried so deeply in gcc's source code and is such an edge case that others
probably don't know why this is happening either

[Bug preprocessor/117166] [15 regression] ICE when building lxml-5.3.0 with LTO (linemap_line_start, at libcpp/line-map.cc:949)

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

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

--- Comment #4 from Richard Biener  ---
maybe changing

  if (line_delta < 0 
  || (line_delta > 10
  && line_delta * map->m_column_and_range_bits > 1000)

to

  if (line_delta < 0
  || line_delta > INT_MAX / map->m_column_and_range_bits
  || (line_delta > 10
  && line_delta * map->m_column_and_range_bits > 1000)

or performing the multiplication in int64_t fixes it?  The compare could
also just be line_delta > 1000, I don't think m_column_and_range_bits
is ever so big that a smaller line_delta overflows the multiplication.

[Bug tree-optimization/117176] [15 regression] ICE when building netpbm-11.8.0

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #4 from Tamar Christina  ---
(In reply to Richard Biener from comment #3)
> Confirmed.  SLP early-exit vect related.
> 
> (gdb) p operand
> $1 = 1
> (gdb) p debug (slp_node)
> t.c:9:5: note: node 0x4e46ac0 (max_nunits=4, refcnt=1) vector(4)
> 
> t.c:9:5: note: op template: _3 = ~_2;
> t.c:9:5: note:  [l] stmt 0 _3 = ~_2;
> t.c:9:5: note:  children 0x4e46b50
> 
> for some reason vectorizable_comparison_1 is called on this stmt.  ISTR
> we expect a comparison here, not a BIT_NOT - SLP discovery should probably
> reject this case (for now).

I think this is a failure of boolean lowering.  The vectorizer doesn't handle
mask inversions through bitwise NOT and instead expects vect_recog_bool_pattern
to lower this to a BIT_XOR_EXPR instead.

The problem here is that the comparison that uses the BIT_NOT_EXPR is hidden
inside the gcond so vect_recog_gcond_pattern doesn't find it.

Think the proper solution is to have vect_recog_gcond_pattern do the lowering
since patterns can't be seeds of other patterns atm.  That's why the condition
split off from vect_recog_gcond_pattern doesn't trigger
vect_recog_bool_pattern.

So Mine.

[Bug target/117185] Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha

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

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

--- Comment #2 from Richard Biener  ---
I would suggest to change reload_in_progress || lra_in_progress back to
just reload_in_progress for resolve_reload_operand - this code can't work for
LRA.

[Bug c++/117174] [12/13/14/15 Regression] Compiler seems to incorrectly cache SFINAE condition evaluation results

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/117177] [15 regression] RISC-V: Error when building glibc from source since r15-4377-gf9bac238840

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

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

--- Comment #7 from Sergei Trofimovich  ---
The change fixed python-3.12.7 build failure for me. Thank you!

[Bug tree-optimization/117176] [15 regression] ICE when building netpbm-11.8.0

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #3 from Richard Biener  ---
Confirmed.  SLP early-exit vect related.

(gdb) p operand
$1 = 1
(gdb) p debug (slp_node)
t.c:9:5: note: node 0x4e46ac0 (max_nunits=4, refcnt=1) vector(4)

t.c:9:5: note: op template: _3 = ~_2;
t.c:9:5: note:  [l] stmt 0 _3 = ~_2;
t.c:9:5: note:  children 0x4e46b50

for some reason vectorizable_comparison_1 is called on this stmt.  ISTR
we expect a comparison here, not a BIT_NOT - SLP discovery should probably
reject this case (for now).

[Bug preprocessor/117166] [15 regression] ICE when building lxml-5.3.0 with LTO (linemap_line_start, at libcpp/line-map.cc:949)

[schwab--- via Gcc-bugs]

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

--- Comment #5 from Andreas Schwab  ---
line_delta > 1000 / map->m_column_and_range_bits

[Bug target/116347] [13/14/15 only] RISC-V: Duplicate entries for -mtune in --target-help

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

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

Christoph Müllner  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-17
 CC||cmuellner at gcc dot gnu.org

--- Comment #1 from Christoph Müllner  ---
Currently, the string "thead-c906" is used as an identifier for a CPU
(RISCV_CORE) and a tuning (RISCV_TUNE). The help message lists under "valid
arguments for -mtune= option" all tuning identifiers followed by all CPU
identifiers.

I don't think changing the identifier is the right thing to do, as it would
break people's build scripts.

Instead, I think it would be better to make the help-string-generator aware of
such cases.

Looking into the code, this should not be too hard:
riscv_get_valid_option_values() in gcc/common/config/riscv/riscv-common.cc
needs to be adjusted (in case OPT_mtune_) to avoid adding duplicates to the
result vector. The function vec_safe_iterate() should help to iterate over
existing entries. The duplication check needs to use strcmp() as the vector
elements are const-char-pointers.

[Bug target/116720] [13/14/15 Regression] RISC-V: Unrecognizable insn with xtheadmemidx on rv32

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

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

Christoph Müllner  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-17
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |cmuellner at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

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

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

--- Comment #12 from Filip Kastl  ---
(In reply to Andi Kleen from comment #9)
> Yes I guess we should keep better switches at -O1 because machine generated
> code may have lot of switches.
> 
> I don't think we need perfect clustering? Perhaps there is some heuristic
> that is good enough. Maybe just kmeans or something like that.
> 
> The deep recursion I saw was for balance_case_nodes

Yeah, maybe there exists some heuristic that we could use.  I believe that
kmeans solves a different problem that just happens to also be called
clustering.

So I think we should do this
1) Turn off the current bit test and jump table clustering algorithms on -O0
(Andi already submitted this patch)
2) Turn off the current algorithms for switches bigger than some constant (not
sure how big it should be)
3) Try to come up with a clustering algorithm which doesn't guarantee optimal
results but runs fast. Use it when the current algorithms are switched off

BTW For (2) maybe this limit could be dynamic and proportionate to the square
root of the size of the whole program? That way O(n^2) algs would still be
linear in the size of the whole compiler input.

[Bug target/111565] ICE: in riscv_expand_strcmp_scalar, at config/riscv/riscv-string.cc:382 with -mcpu=thead-c906 -minline-strncmp

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

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

Christoph Müllner  changed:

   What|Removed |Added

 CC||cmuellner at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |cmuellner at gcc dot 
gnu.org
   Last reconfirmed||2024-10-17
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Christoph Müllner  ---
GCC 14 (I just reproduced on GCC 14.1 and 14.2) is affected. Master (GCC 15)
does not have any issues.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #20 from GCC Commits  ---
The master branch has been updated by Denis Chertykov :

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

commit r15-4406-ge7393cbb5f2cae50b42713e71984064073aa378a
Author: Denis Chertykov 
Date:   Thu Oct 17 11:12:38 2024 +0400

The detailed explanation from PR116550:

Test file: udivmoddi.c
problem insn: 484

Before LRA pass we have:
(insn 484 483 485 72 (parallel [
(set (reg/v:SI 143 [ __q1 ])
(plus:SI (reg/v:SI 143 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (scratch:QI))
]) "udivmoddi.c":163:405 discrim 5 186 {addsi3}
 (nil))

LRA substitute all scratches with new pseudos, so we have:
(insn 484 483 485 72 (parallel [
(set (reg/v:SI 143 [ __q1 ])
(plus:SI (reg/v:SI 143 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (reg:QI 619))
]) "/mnt/d/avr-lra/udivmoddi.c":163:405 discrim 5 186 {addsi3}
 (expr_list:REG_UNUSED (reg:QI 619)
(nil)))

Pseudo 619 is a special scratch register generated by LRA which is marked
in `scratch_bitmap' and can be tested by call `ira_former_scratch_p(regno)'.

In dump file (udivmoddi.c.317r.reload) we have:
  Creating newreg=619
Removing SCRATCH to p619 in insn #484 (nop 3)
rescanning insn with uid = 484.

After that LRA tries to spill (reg:QI 619)
It's a bug because (reg:QI 619) is an output scratch register which is
already something like spill register.

Fragment from udivmoddi.c.317r.reload:
  Choosing alt 2 in insn 484:  (0) r  (1) 0  (2) nYnn  (3) &d {addsi3}
  Creating newreg=728 from oldreg=619, assigning class LD_REGS to r728

IMHO: the bug is in lra-constraints.cc in function `get_reload_reg'
fragment of `get_reload_reg':
  if (type == OP_OUT)
{
  /* Output reload registers tend to start out with a conservative
 choice of register class.  Usually this is ALL_REGS, although
 a target might narrow it (for performance reasons) through
 targetm.preferred_reload_class.  It's therefore quite common
 for a reload instruction to require a more restrictive class
 than the class that was originally assigned to the reload
register.

 In these situations, it's more efficient to refine the choice
 of register class rather than create a second reload register.
 This also helps to avoid cycling for registers that are only
 used by reload instructions.  */
  if (REG_P (original)
  && (int) REGNO (original) >= new_regno_start
  && INSN_UID (curr_insn) >= new_insn_uid_start
__^^
  && in_class_p (original, rclass, &new_class, true))
{
  unsigned int regno = REGNO (original);
  if (lra_dump_file != NULL)
{
  fprintf (lra_dump_file, "  Reuse r%d for output ", regno);
  dump_value_slim (lra_dump_file, original, 1);
}

This condition incorrectly limits register reuse to ONLY newly generated
instructions.
i.e. LRA can reuse registers only from insns generated by himself.

IMHO:It's wrong.
Scratch registers generated by LRA also have to be reused.

The patch is very simple.
On x86_64, it bootstraps+regtests fine.

gcc/
PR target/116550
* lra-constraints.cc (get_reload_reg): Reuse scratch registers
generated by LRA.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #402 from Kazumoto Kojima  ---
I've opened PR 117182 for a wrong fldi0/1 issue.  Looks target + RA issue.

FYI, with the patches in PR 116932, PR 117111 and PR 117182 on top of
devel/sh-lra, c/c++ testsuite shows only one regression against trunk -mno-lra:

FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2

OTOH, the following FAILs on trunk -mno-lra are solved:

FAIL: gcc.c-torture/compile/pr55921.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr55921.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr55921.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/compile/pr55921.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none 
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -Os 
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O3 -g  execution test

These may be simply accidental with the perturbations of generated code,
though.

[Bug target/117185] Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #2)
> I would suggest to change reload_in_progress || lra_in_progress back to
> just reload_in_progress for resolve_reload_operand - this code can't work
> for LRA.

OK, I'll give it a try.

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

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

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

Bug 80235 Summary: ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug target/117185] Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Please see PR57032, from Comment #8 and #9.

[Bug libstdc++/117151] _GLIBCXX_USE_C99_COMPLEX_ARC and _GLIBCXX_USE_C99_COMPLEX are not defined in a consistent way

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #2 from vincenzo Innocente  ---
fine.

I was trying to understand (reverse-engineering)  what cuda and hip were using
in device and host code...

In case anybody is interested I think that cuda/nvcc uses their own
implementation (in their own cuda::std namespace) on host and device
(of course if one on host uses std namespace gcc libstd will be used)
while hipcc seems to use gcc libstd on both host and device (on device the
inline code is used)

I used acosh on the negative axis to black-box test it as gcc libstd is the
only one which implements the "kahan" formula (for which I haven't found any
other reference)

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #21 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r15-4410-ge74d25cd00629e001038cf6ff83e48d7ca6f4873
Author: Georg-Johann Lay 
Date:   Thu Oct 17 13:19:51 2024 +0200

rtl-optimization/116550 - Add test cases.

PR rtl-optimization/116550
gcc/testsuite/
* gcc.target/avr/torture/lra-pr116550-1.c: New file.
* gcc.target/avr/torture/lra-pr116550-2.c: New file.

[Bug rtl-optimization/113533] Code generation regression after change for pr111267

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

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

--- Comment #22 from GCC Commits  ---
The master branch has been updated by Oleg Endo :

https://gcc.gnu.org/g:2390cbad85cbd122d4e58c94f7891d7c5fde49b3

commit r15-4411-g2390cbad85cbd122d4e58c94f7891d7c5fde49b3
Author: Oleg Endo 
Date:   Thu Oct 17 21:40:14 2024 +0900

SH: Fix typo of commit b717c462b96e

gcc/ChangeLog:
PR target/113533
* config/sh/sh.cc (sh_rtx_costs): Delete wrong semicolon.

Re: A bug in gcc-13.2.0-llvm-17.0.5-mingw-w64ucrt-11.0.1-r3 with the -O3 option

[Jonathan Wakely via Gcc-bugs]

On 17/10/24 12:16 +0300, Сергей wrote:


Hello All,
 
 I found a bug in gcc-13.2.0-llvm-17.0.5-mingw-w64ucrt-11.0.1-r3 for Windows.
This bug occurs when translating the file "bug.c" with the -O3 option. There is 
no error when translating it with the -O2 option.
To check this bug, download bug.c file and other files from Google disk:
https://drive.google.com/file/d/1Ii0HGuVFhC6iuNM1ArnVNcAspVi_W79T/view?usp=drive_link


This mailing list is for automated emails from our bug tracking
database, it is not for reporting bugs.

To report a bug, please see https://gcc.gnu.org/bugs/

[Bug libstdc++/117187] New: __niter_base overloads need to be declare before use

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

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

Bug ID: 117187
   Summary: __niter_base overloads need to be declare before use
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This fails to compile:

#include 
#include 
#include 

struct S { };

int main()
{
  std::vector v;
  std::vector out;
  std::copy(v.begin(), v.end(), std::make_move_iterator(vout.begin()));
}

The problem is that the __niter_wrap function calls std::__niter_base on the
move_iterator but the __niter_base(move_iterator) overload has not been
declared at that point.

[Bug libstdc++/117187] __niter_base overloads need to be declare before use

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Actually this is due to an unpushed change in my tree, so I just need to fix it
there.

[Bug target/117186] New: aarch64 wrong code for (a < b) < (b < a)

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

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

Bug ID: 117186
   Summary: aarch64 wrong code for (a < b) < (b < a)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The aarch64 compiler compiles the function

int
lx (int oi, int mb)
{
  return (oi < mb) < (mb < oi);
}

to

lx:
cmp w0, w1
csetw0, hi
ret

with -O1 or higher optimization level.  This is wrong. For example, lx(-1, 0)
returns an incorrect result.

[Bug c++/116424] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:904 creating static object from other static objects

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:420e17e642e0b1e9ebf1502613ea1c0acfa8a0e1

commit r14-10798-g420e17e642e0b1e9ebf1502613ea1c0acfa8a0e1
Author: Marek Polacek 
Date:   Tue Aug 27 18:25:17 2024 -0400

c++: ICE with ()-init and TARGET_EXPR eliding [PR116424]

Here we crash on a cp_gimplify_expr/TARGET_EXPR assert:

  gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p)
   || !TREE_ADDRESSABLE (TREE_TYPE (*expr_p)));

We cannot elide the TARGET_EXPR because we're taking its address.

It is set as eliding in massage_init_elt.  I've tried to not set
TARGET_EXPR_ELIDING_P when the context is not direct-initialization.
That didn't work: even when it's not direct-initialization now, it
can become one later, for instance, after split_nonconstant_init.
One problem is that replace_placeholders_for_class_temp_r will replace
placeholders in non-eliding TARGET_EXPRs with the slot, but if we then
elide the TARGET_EXPR, we end up with a "stray" VAR_DECL and crash.
(Only some TARGET_EXPRs are handled by replace_decl.)

I thought I'd have to go back to
 but
then I realized that this problem occurrs only with ()-init but not
{}-init.  With {}-init, there is no problem, because we are clearing
TARGET_EXPR_ELIDING_P in process_init_constructor_record:

   /* We can't actually elide the temporary when initializing a
  potentially-overlapping field from a function that returns by
  value.  */
   if (ce->index
   && TREE_CODE (next) == TARGET_EXPR
   && unsafe_copy_elision_p (ce->index, next))
 TARGET_EXPR_ELIDING_P (next) = false;

But that does not happen for ()-init because we have no ce->index.
()-init doesn't allow brace elision so we don't really reshape them.

But I can just move the clearing a few lines down and then it handles
both ()-init and {}-init.

PR c++/116424

gcc/cp/ChangeLog:

* typeck2.cc (process_init_constructor_record): Move the clearing
of
TARGET_EXPR_ELIDING_P down.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/paren-init38.C: New test.

(cherry picked from commit 15f857af2943a4aa282d04ff71f860352ad3291b)

[Bug c++/116476] [14 Regression] error: binding reference of type 'int&&' to 'const int' discards qualifiers for std::vector> f{2}; (OK under Clang and GCC<=13)

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:0784e8934e96187e17c1b02dce1e0ed35d2229dd

commit r14-10799-g0784e8934e96187e17c1b02dce1e0ed35d2229dd
Author: Marek Polacek 
Date:   Wed Aug 28 15:45:49 2024 -0400

c++: wrong error due to std::initializer_list opt [PR116476]

Here maybe_init_list_as_array gets elttype=field, init={NON_LVALUE_EXPR
<2>}
and it tries to convert the init's element type (int) to field
using implicit_conversion, which works, so overall maybe_init_list_as_array
is successful.

But it constifies init_elttype so we end up with "const int".  Later,
when we actually perform the conversion and invoke field::field(T&&),
we end up with this error:

  error: binding reference of type 'int&&' to 'const int' discards
qualifiers

So I think maybe_init_list_as_array should try to perform the conversion,
like it does below with fc.

PR c++/116476

gcc/cp/ChangeLog:

* call.cc (maybe_init_list_as_array): Try convert_like and see if
it
worked.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-opt2.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 9f79c7ddff5f1b004803931406ad17eaba095fff)

[Bug c++/116534] [14 regression] internal compiler error with comparison of pointers calculated with array offset

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:36de56d3d643e7b8131fa6671b9e85258a1d1ca1

commit r14-10800-g36de56d3d643e7b8131fa6671b9e85258a1d1ca1
Author: Marek Polacek 
Date:   Thu Aug 29 10:40:50 2024 -0400

c++: ICE with -Wtautological-compare in template [PR116534]

Pre r14-4793, we'd call warn_tautological_cmp -> operand_equal_p
with operands wrapped in NON_DEPENDENT_EXPR, which works, since
o_e_p bails for codes it doesn't know.  But now we pass operands
not encapsulated in NON_DEPENDENT_EXPR, and crash, because the
template tree for &a[x] has null DECL_FIELD_OFFSET.

This patch extends r12-7797 to cover the case when DECL_FIELD_OFFSET
is null.

PR c++/116534

gcc/ChangeLog:

* fold-const.cc (operand_compare::operand_equal_p): If either
field's DECL_FIELD_OFFSET is null, compare the fields with ==.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wtautological-compare4.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 7ca486889b1b1c7e7bcbbca3b6caa103294ec07d)

[Bug c++/116476] [14 Regression] error: binding reference of type 'int&&' to 'const int' discards qualifiers for std::vector> f{2}; (OK under Clang and GCC<=13)

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/116534] [14 regression] internal compiler error with comparison of pointers calculated with array offset

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #25 from Georg-Johann Lay  ---
(In reply to denisc from comment #24)
> Johann do you think that it is better to open a new bug for lra-pr116550-2.c
Yes, seems to be a different issue.

[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences

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

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

Bug 117172 Summary: FAIL: gcc.target/i386/pr111820-2.c and 
gcc.target/i386/pr111820-3.c with forced SLP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117172

   What|Removed |Added

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

[Bug tree-optimization/117172] FAIL: gcc.target/i386/pr111820-2.c and gcc.target/i386/pr111820-3.c with forced SLP

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 17 Oct 2024, pheeck at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
> 
> --- Comment #12 from Filip Kastl  ---
> (In reply to Andi Kleen from comment #9)
> > Yes I guess we should keep better switches at -O1 because machine generated
> > code may have lot of switches.
> > 
> > I don't think we need perfect clustering? Perhaps there is some heuristic
> > that is good enough. Maybe just kmeans or something like that.
> > 
> > The deep recursion I saw was for balance_case_nodes
> 
> Yeah, maybe there exists some heuristic that we could use.  I believe that
> kmeans solves a different problem that just happens to also be called
> clustering.
> 
> So I think we should do this
> 1) Turn off the current bit test and jump table clustering algorithms on -O0
> (Andi already submitted this patch)
> 2) Turn off the current algorithms for switches bigger than some constant (not
> sure how big it should be)
> 3) Try to come up with a clustering algorithm which doesn't guarantee optimal
> results but runs fast. Use it when the current algorithms are switched off
> 
> BTW For (2) maybe this limit could be dynamic and proportionate to the square
> root of the size of the whole program? That way O(n^2) algs would still be
> linear in the size of the whole compiler input.

I think we should simply add an upper bound static number and make
it a new --param.  We can also possibly divide the switch into
two (with an if) and thus go to two times half N - finding interesting
subdivisions (rather than "half") might be possible.  The new --param
would then apply to the part size we stop dividing the switch up.

[Bug tree-optimization/117172] FAIL: gcc.target/i386/pr111820-2.c and gcc.target/i386/pr111820-3.c with forced SLP

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

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

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

https://gcc.gnu.org/g:1081f4cb34ea22e6ba07ddcb88cada3ec60bc9c4

commit r15-4408-g1081f4cb34ea22e6ba07ddcb88cada3ec60bc9c4
Author: Richard Biener 
Date:   Thu Oct 17 10:27:58 2024 +0200

tree-optimization/117172 - single lane SLP for non-linear inductions

The following adds single-lane SLP support for vectorizing non-linear
inductions.

This fixes a bunch of i386 specific testcases with --param
vect-force-slp=1.

PR tree-optimization/117172
* tree-vect-loop.cc (vectorizable_nonlinear_induction): Add
single-lane SLP support.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #22 from Georg-Johann Lay  ---
I allowed me to add some test cases.  Unfortunatels, one of them is failing
with the patch and -mlra, whereas is passes with -mno-lra.

In $builddir/gcc:

$ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
--tool_opts='-mlra' avr-torture.exp=lra-pr116550-2.c"
[...]
Running
/home/john/xgnu/source/gcc-master/gcc/testsuite/gcc.target/avr/torture/avr-torture.exp
...
FAIL: gcc.target/avr/torture/lra-pr116550-2.c   -O1  execution test

=== gcc Summary ===

# of expected passes21
# of unexpected failures1

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #23 from Georg-Johann Lay  ---
(In reply to Georg-Johann Lay from comment #22)
> Unfortunately, one of them [lra-pr116550-2.c} is failing
> with the patch and -mlra, whereas is passes with -mno-lra.

Ok, I messed that one up.  That test also fails with -mlra and without the
patch.

Closing this one as fixed.

[Bug target/113934] Switch avr to LRA

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

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

Bug 116550 Summary: [lra][avr] internal compiler error: in final_scan_insn_1, 
at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550

   What|Removed |Added

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

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

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

Bug 116550 Summary: [lra][avr] internal compiler error: in final_scan_insn_1, 
at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550

   What|Removed |Added

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

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #24 from denisc at gcc dot gnu.org ---
(In reply to Georg-Johann Lay from comment #23)
> (In reply to Georg-Johann Lay from comment #22)
> > Unfortunately, one of them [lra-pr116550-2.c} is failing
> > with the patch and -mlra, whereas is passes with -mno-lra.
> 
> Ok, I messed that one up.  That test also fails with -mlra and without the
> patch.
> 
> Closing this one as fixed.

I'm in the process of analyzing lra-pr116550-2.c (or simd-r.c as I call it
first).
The real wrong things happened in dse2 pass.
The dse2 pass made a wrong elimination of a few store insns.

Right now I can't say if it is the lra derived bug or a clean dse2 bug.

Johann do you think that it is better to open a new bug for lra-pr116550-2.c ?

[Bug middle-end/117123] [14/15 regression] Generated code at -Os on trunk is larger than GCC 14.4 since r14-6536-gcd794c39610177 (sccopy)

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

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

--- Comment #9 from Filip Kastl  ---
Btw, here is a reduced testcase:

-
struct Potato {
  bool isMashed;
};
void dont_be_here();
int patatino_a;
void patatino() {
  if (patatino_a && patatino_a % 2 == 0 && patatino_a != 10)
;
  else {
Potato spud;
int spud_0 = patatino_a;
spud.isMashed = false;
for (int k = 0; patatino_a == 0 && spud_0 > 1000; k++)
  for (int l = 0; l < 5; l++)
spud_0 += l * k;
for (; spud_0;)
  dont_be_here();
  }
}
-

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

[andi at firstfloor dot org via Gcc-bugs]

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

--- Comment #15 from andi at firstfloor dot org ---
An upper limit has the problem that very large switches may never get 
the bitmasks or the jump clusters. Would be good to have a heuristic 
that still works for them.

Bit clustering always works on words so you have a fallback that just 
looks at aligned regions in value space without trying to find optimal 
clusters. I guess jump clustering could do something similar although it 
doesn't have natural alignment.

Also there must be a better data structure for the search. Some kind of 
augmented tree perhaps. That would be a lot more effort though

And the code has a lot of hard coded constants. Some params are probably 
a good idea.

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

[andi at firstfloor dot org via Gcc-bugs]

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

--- Comment #14 from andi at firstfloor dot org ---
On 2024-10-17 05:59, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
> 
> --- Comment #13 from rguenther at suse dot de  de> ---
> On Thu, 17 Oct 2024, pheeck at gcc dot gnu.org wrote:
> 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
>> 
>> --- Comment #12 from Filip Kastl  ---
>> (In reply to Andi Kleen from comment #9)
>> > Yes I guess we should keep better switches at -O1 because machine generated
>> > code may have lot of switches.
>> >
>> > I don't think we need perfect clustering? Perhaps there is some heuristic
>> > that is good enough. Maybe just kmeans or something like that.
>> >
>> > The deep recursion I saw was for balance_case_nodes
>> 
>> Yeah, maybe there exists some heuristic that we could use.  I believe 
>> that
>> kmeans solves a different problem that just happens to also be called
>> clustering.
>> 
>> So I think we should do this
>> 1) Turn off the current bit test and jump table clustering algorithms 
>> on -O0
>> (Andi already submitted this patch)
>> 2) Turn off the current algorithms for switches bigger than some 
>> constant (not
>> sure how big it should be)
>> 3) Try to come up with a clustering algorithm which doesn't guarantee 
>> optimal
>> results but runs fast. Use it when the current algorithms are switched 
>> off
>> 
>> BTW For (2) maybe this limit could be dynamic and proportionate to the 
>> square
>> root of the size of the whole program? That way O(n^2) algs would 
>> still be
>> linear in the size of the whole compiler input.
> 
> I think we should simply add an upper bound static number and make
> it a new --param.  We can also possibly divide the switch into
> two (with an if) and thus go to two times half N - finding interesting
> subdivisions (rather than "half") might be possible.  The new --param
> would then apply to the part size we stop dividing the switch up.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

--- Comment #6 from Andrew Pinski  ---
before is before r15-4397-g70f59d2a1c51bd

--- before.s2024-10-17 20:17:06.172435278 +
+++ after.s 2024-10-17 20:15:24.703424849 +
@@ -15,21 +15,21 @@ main:
movlc(%rip), %eax
movla(%rip), %esi
movl$6, d(%rip)
-   movq16(%rsp), %xmm2
+   movq16(%rsp), %xmm1
testl   %eax, %eax
sete%dl
cmpl$5, b(%rip)
jg  .L3
movzbl  %dl, %eax
-   pxor%xmm1, %xmm1
+   pxor%xmm2, %xmm2
movl$6, b(%rip)
negl%eax
movd%eax, %xmm3
pshufd  $0xe0, %xmm3, %xmm0
-   pcmpeqd %xmm1, %xmm0
-   pcmpeqd %xmm1, %xmm0
-   pandn   %xmm2, %xmm0
-   pshufd  $0xe5, %xmm0, %xmm4
+   pcmpeqd %xmm2, %xmm0
+   pcmpeqd %xmm2, %xmm0
+   pandn   %xmm0, %xmm1
+   pshufd  $0xe5, %xmm1, %xmm4
movd%xmm4, %esi
movd%xmm4, a(%rip)
 .L3:


The andn is swapped.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

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

Patch in testing.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 Regression] wrong code  |[15 Regression] wrong code
   |at -O3 with |at -O3 with
   |"-fno-unswitch-loops" on|"-fno-unswitch-loops" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r15-4397-g70f59d2a1c51bd

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I am thinking r15-4397-g70f59d2a1c51bd .

Confirmed it is that. Note since aarch64 produces the same IR even with the
andn, I am thinking some latent bug in the andn handling. 

But looking at the .optimized we have:
  vect__ifc__49.29_73 = MEM  [(int *)&e + 16B];


But e is not initialized 

[Bug tree-optimization/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization

--- Comment #4 from Andrew Pinski  ---
The bug I think is ifcvt:

  _ifc__30 = e[d.3_23];
  _ifc__37 = _24 ? 0 : _ifc__30;
  e[d.3_23] = _ifc__37;

It was a bug before r15-4397-g70f59d2a1c51bd but it didn't get exposed
beforehand in the instructions; even though it was there.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #5 from Andrew Pinski  ---
So in .optimize we have:

  _24 = c.0_1 == 0; // 1 because c is 0
  _27 = (unsigned int) _24;
  patt_36 = -_27; // -1
  _68 = {patt_36, patt_36}; // {-1, -1}
  mask_patt_42.26_69 = _68 != { 0, 0 }; // {-1,-1}
  _22 = VIEW_CONVERT_EXPR(mask_patt_42.26_69);
  vect_patt_43.30_74 = .BIT_ANDN (vect__ifc__49.29_73, _22); //
  _79 = BIT_FIELD_REF ; // 0



cmpl$1, %eax
pxor%xmm2, %xmm2 // 0
movl$6, b(%rip)
sbbl%eax, %eax // 0
movd%eax, %xmm0 // 0
pshufd  $0xe0, %xmm0, %xmm0 // {0,0}
pcmpeqd %xmm2, %xmm0 // xmm0 = {-1,-1}
pcmpeqd %xmm2, %xmm0 // xmm0 = {0,0}
pandn   %xmm0, %xmm1 // xmm1 = xmm0 & ~xmm1 -> 0 & ??? -> 0
pshufd  $0xe5, %xmm1, %xmm3 //extract 0
movd%xmm3, %eax 
movd%xmm3, a(%rip)

But we are getting -1 ...

[Bug target/117194] New: [15 Regression] Wrong code on highway-1.2.0

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

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

Bug ID: 117194
   Summary: [15 Regression] Wrong code on highway-1.2.0
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed on current gcc-master from r15-4419-g6604a05fa27bc2 (did not bisect to
precise commit) `highway-1.2.0` testsuite fails as:

   > The following tests FAILED:
   >740 - HwyIfTestGroup/HwyIfTest.TestAllIfNegative/EMU128  #
GetParam() = 2305843009213693952 (Subprocess aborted)

Extracted the self-contained example as:

// $ cat /tmp/a.cc
#include 
#include 

namespace {

struct v8 {
  v8() = default;
  v8(const v8&) = default;
  v8& operator=(const v8&) = default;

  int8_t raw[16] = {};
};

v8 Zero_() { v8 v; return v; }

v8 Iota_(int8_t first) {
  v8 v;
  for (int8_t i = 0; i < 16; ++i) {
v.raw[i] = first + i;
  }
  return v;
}

v8 Set_(const int8_t t) {
  v8 v;
  for (size_t i = 0; i < 8; ++i) {
v.raw[i] = t;
  }
  return v;
}

v8 SignBit_() { return Set_(int8_t{-128}); }

v8 Or_(v8 a, v8 b) {
  v8 r;
  for (size_t i = 0; i < 16; ++i) {
r.raw[i] = a.raw[i] | b.raw[i];
  }
  return r;
}

v8 IfNegativeThenElse(v8 v, v8 yes, v8 no) {
  v8 r;

  for (size_t i = 0; i < 8; ++i) {
r.raw[i] = v.raw[i] < 0 ? yes.raw[i] : no.raw[i];
  }
  return r;
}

void TestAllIfNegative() {
const v8 v0 = Zero_();
const auto vp = Iota_(1);
const auto vsignbit = SignBit_();
const auto vn = Or_(vp, vsignbit);
const auto r = IfNegativeThenElse(vn, v0, vp);

if (__builtin_memcmp(v0.raw, r.raw, 8) != 0)
__builtin_trap();
}

} // namespace

int main() {
TestAllIfNegative();
}

Crashing:

# ok
$ g++ a.cc -O1 -o bug && ./bug
# bad
$ g++ a.cc -O2 -o bug && ./bug
Illegal instruction (core dumped)

$ g++ -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xg++
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241016 (experimental) (GCC)

[Bug rtl-optimization/115879] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 6 with -O -fnon-call-exceptions -finstrument-functions and invalid memory access

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Zdenek Sojka from comment #2)
> _BitInt() is not needed, this can be also triggered at least by memset() and
> memcpy() with the memory operand having negative offset to address to a
> variable.

Do you have an  example since I can't find one?

[Bug fortran/117188] ICE when OUT variable dimension is defined by a IN variable member

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
No ICE here with all tested versions >= 7.5.0.
(Example 2 does crash ifx, however.)

The code is invalid as explained by Steve.
Compiling with -g -fsanitize=undefined,address, I get:

pr117188-z1.f90:13:23: runtime error: member access within null pointer of type
'struct base_type'

[Bug target/113934] Switch avr to LRA

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

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

Bug 116779 Summary: [lra][avr] internal compiler error: in patch_jump_insn, at 
cfgrtl.cc:1303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116779

   What|Removed |Added

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

[Bug rtl-optimization/116779] [lra][avr] internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #1 from Georg-Johann Lay  ---
Seems the ICE with -mno-lra has gone.

With -mlra wrong code is being generated, see PR117191.

$ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
--tool_opts='-mlra' execute.exp=simd-*.c"
[...]
Running $srcdir/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/simd-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/simd-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/simd-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/simd-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/simd-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/simd-2.c   -O2  execution test
FAIL: gcc.c-torture/execute/simd-2.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/simd-2.c   -Os  execution test

=== gcc Summary ===

# of expected passes62
# of unexpected failures8

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

[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination

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

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

--- Comment #3 from Georg-Johann Lay  ---
*** Bug 116779 has been marked as a duplicate of this bug. ***

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

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

Bug 116779 Summary: [lra][avr] internal compiler error: in patch_jump_insn, at 
cfgrtl.cc:1303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116779

   What|Removed |Added

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

[Bug middle-end/117195] Invalid IR after vectorization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation,
   ||internal-improvement

--- Comment #1 from Andrew Pinski  ---
so it means a = b w+ c; means a = b + c[0] + c[1]
where c[0] is one half and c[1] is the other half

This is not exactly documented though. But it should be.

[Bug middle-end/117195] Invalid IR after vectorization

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

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

--- Comment #2 from Andrew Pinski  ---
The tree code represents the following obtab:
@cindex @code{widen_ssum@var{m}3} instruction pattern
@cindex @code{widen_usum@var{m}3} instruction pattern
@item @samp{widen_ssum@var{m}3}
@itemx @samp{widen_usum@var{m}3}
Operands 0 and 2 are of the same mode, which is wider than the mode of
operand 1. Add operand 1 to operand 2 and place the widened result in
operand 0. (This is used express accumulation of elements into an accumulator
of a wider mode.)
@var{m} is the mode of operand 1.


But it does not mention what happens if operand 1 has 2x the number of
elements.

[Bug middle-end/117195] WIDEN_SUM_EXPR documentation is weak when the second oeprand is 2x the number of elements than other operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|WIDEN_SUM_EXPR  |WIDEN_SUM_EXPR
   |documentation is weak when  |documentation is weak when
   |the second argument is 2x   |the second oeprand is 2x
   |the number of elements than |the number of elements than
   |other operand   |other operand
   Last reconfirmed||2024-10-17

--- Comment #3 from Andrew Pinski  ---
Confirmed at for the documentation issue since yes it is not clear at all.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Andrew Pinski from comment #6)
> 
> > The andn is swapped.
> Indeed:
> 
> +(define_expand "andn3"
> +  [(set (match_operand:MMXMODEI 0 "register_operand")
> +(and:MMXMODEI
> +  (not:MMXMODEI (match_operand:MMXMODEI 1 "register_operand"))
> +  (match_operand:MMXMODEI 2 "register_operand")))]
> +  "TARGET_SSE2")
> 
> +(define_expand "andn3"
> +  [(set (match_operand:VI 0 "register_operand")
> +   (and:VI
> + (not:VI (match_operand:VI 2 "register_operand"))
> + (match_operand:VI 1 "register_operand")))]
> +  "TARGET_SSE2")
> 
> Which operand order is correct?


The correct one is operand 2 with the not.
>From https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html :
‘andnm3’
Like andm3, but it uses bitwise-complement of operand 2 rather than operand 2
itself.

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #20 from Jerry DeLisle  ---
Closing as fixed for now.

[Bug fortran/20585] [meta-bug] Fortran 2003 support

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

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

Bug 105361 Summary: Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361

   What|Removed |Added

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

[Bug target/117194] [15 Regression] Wrong code on highway-1.2.0

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

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

--- Comment #2 from Andrew Pinski  ---
;; vect_iftmp.29_100 = .BIT_ANDN ({ 1, 2, 3, 4, 5, 6, 7, 8 }, _68);

(insn 33 32 34 (set (reg:V8QI 128)
(mem/u/c:V8QI (symbol_ref/u:DI ("*.LC2") [flags 0x2]) [0  S8 A64])) -1
 (expr_list:REG_EQUAL (const_vector:V8QI [
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
(const_int 8 [0x8])
])
(nil)))

(insn 34 33 0 (set (reg:V8QI 101 [ vect_iftmp.29 ])
(and:V8QI (not:V8QI (reg:V8QI 128))
(reg:V8QI 99 [ _68 ]))) -1
 (nil))

The operands of andn are swapped.

[Bug target/117194] [15 Regression] Wrong code on highway-1.2.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup. That is fixed with the patch attached for PR 117192.

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

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

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

[Bug fortran/104827] [12/13/14/15 Regression] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.cc:8329 since r12-4409-g724ee5a0093da443

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #5 from kargls at comcast dot net ---
This appears to be fixed in that the ICE no longer occurs.

% cat z1.f90
program p
   !$omp declare variant(a) match(implementation={f([1])})
end
% gfcx -o z -fopenmp z1.f90
z1.f90:2:53:

2 |!$omp declare variant(a) match(implementation={f([1])})
  | 1
Error: Expected trait-property-extension at (1)

Have no idea if the error message is correct.


Note, z2.f90 now compiles with a warning.

% gfcx -o z -fopenmp z2.f90
z2.f90:2:52:

2 |!$omp declare variant(a) match(implementation={f(1)})
  |1
Warning: unknown selector 'f' for context selector set 'implementation' at (1)
-Wopenmp]

[Bug middle-end/117195] New: Invalid IR after vectorization

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

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

Bug ID: 117195
   Summary: Invalid IR after vectorization
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vectorizer creates IR that I believe is invalid for the function:

```
void
zz (int x9, short int gt)
{
  if (0)
{
  while (gt < 1)
{
  int pz;

k6:
  for (pz = 0; pz < 3; ++pz)
x9 += gt;
  ++gt;
}
}

  if (x9 != 0)
goto k6;
```

when compiled for AArch64 as
  aarch64-elf-gcc -O3 -S bug.c

The issue here is that we get WIDEN_SUM_EXPR instructions where the arguments
are vectors with a different number of elements. You can find them right after
the k6 label:

```
k6:
  vect_patt_33.14_106 = vect_vec_iv_.10_76 w+ vect_x9_4.13_100;
  vect_patt_33.14_107 = vect_vec_iv_.11_84 w+ vect_x9_4.13_101;
  vect_patt_33.14_108 = vect_vec_iv_.12_92 w+ vect_x9_4.13_102;
```

where the variables are declared as:
  vector(4) int vect_patt_33.14;
  vector(8) short int vect_vec_iv_.12;
  vector(8) short int vect_vec_iv_.11;
  vector(8) short int vect_vec_iv_.10;
  vector(4) int vect_x9_4.13;

[Bug fortran/104826] [12/13/14/15 Regression] ICE in gimple_range_global, at value-query.cc:424 – with deferred-length character variable

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #7 from kargls at comcast dot net ---
Both z1.f90 and z2.f90 compile without an ICE.  Seems to be fixed.

[Bug sanitizer/117196] New: Should no_sanitize_address turn off hwaddress too?

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

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

Bug ID: 117196
   Summary: Should no_sanitize_address turn off hwaddress too?
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

The kernel folks think it should:
https://lore.kernel.org/all/ZvFGwKfoC4yVjN_X@J2N7QTR9R3/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7aed6a2c51ffc97a126e0ea0c270fab7af97ae18

[Bug sanitizer/117196] Should no_sanitize_address attribute turn off hwaddress too?

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

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

--- Comment #1 from Andrew Pinski  ---
"I believe this is a compiler bug, as there doesn't seem to be a
separate attribute to prevent instrumentation in this mode.
"
At least the above is not true.
`__attribute__((no_sanitize("hwaddress")))` and
`__attribute__((no_sanitize("kernel-hwaddress")))`

Turns off hwasan for the function.

[Bug sanitizer/117196] Should no_sanitize_address attribute turn off hwaddress too?

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

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

--- Comment #2 from Andrew Pinski  ---
The documentation for GCC's no_sanitize_address attribute is at least clear
that it does not disable it for hwasan:
"when compiling with the -fsanitize=address option."

https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Function-Attributes.html#index-no_005fsanitize_005faddress-function-attribute


clang's documentation is ambiguous on what it does:
https://clang.llvm.org/docs/AttributeReference.html#no-sanitize-address-no-address-safety-analysis

```
Use __attribute__((no_sanitize_address)) on a function or a global variable
declaration to specify that address safety instrumentation (e.g.
AddressSanitizer) should not be applied.

```

So this is at least also a clang bug for not having a clear definition of this
attribute too.

[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085

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

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

--- Comment #3 from Jakub Jelinek  ---
Another option would be to revert r15-4402 and r15-4377 and reapply once this
fix is tested and approved.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #6)

> The andn is swapped.
Indeed:

+(define_expand "andn3"
+  [(set (match_operand:MMXMODEI 0 "register_operand")
+(and:MMXMODEI
+  (not:MMXMODEI (match_operand:MMXMODEI 1 "register_operand"))
+  (match_operand:MMXMODEI 2 "register_operand")))]
+  "TARGET_SSE2")

+(define_expand "andn3"
+  [(set (match_operand:VI 0 "register_operand")
+   (and:VI
+ (not:VI (match_operand:VI 2 "register_operand"))
+ (match_operand:VI 1 "register_operand")))]
+  "TARGET_SSE2")

Which operand order is correct?

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

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

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

--- Comment #19 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

https://gcc.gnu.org/g:6604a05fa27bc21c3409e767552daca3fcf43964

commit r15-4419-g6604a05fa27bc21c3409e767552daca3fcf43964
Author: Jerry DeLisle 
Date:   Thu Oct 17 13:39:09 2024 -0700

Fortran: Add tolerance to real value comparisons.

gcc/testsuite/ChangeLog:

PR fortran/105361
* gfortran.dg/pr105361.f90: In the comparisons of
real values after a read, use a tolerance so that
subtle differences in results between different
architectures do not fail.

[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 59372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59372&action=edit
gcc15-pr117190.patch

Untested fix.
As the ICE shows, I think we need to use bitsize_int instead of size_int (or if
index actually can be different types then build_int_cst (TREE_TYPE (index),
...),
but I hope it is always bitsize).
Except that when that is fixed, there is another ICE, the problem is that while
the PR117177 fix checked to ensure that there is INTEGER_CST for most of the
flex array cases, for length 65 it actually didn't if there is redundant
trailing comma.
And now that I look at PR117177 again, I was wrong that it peeks 4 token, the
code was peeking just 3 tokens and so can peek one more (the
c_parser_peek_nth_token numbers are 1 based, not 0, so argument 4 is fine).
So, I think we can revert PR117177 except for the test, do it differently, add
another check and testcase.

Unfortunately, I can't fully test this easily until Monday.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #6)
> before is before r15-4397-g70f59d2a1c51bd
> -   movq16(%rsp), %xmm2
> +   movq16(%rsp), %xmm1

Isn't this reading from uninitialized stack slot?

movq16(%rsp), %xmm2 # MEM  [(int *)&e + 16B],
vect__ifc__49.29

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > before is before r15-4397-g70f59d2a1c51bd
> > -   movq16(%rsp), %xmm2
> > +   movq16(%rsp), %xmm1
> 
> Isn't this reading from uninitialized stack slot?
> 
> movq16(%rsp), %xmm2 # MEM  [(int *)&e + 16B],
> vect__ifc__49.29

Yes but in this case the mask will 0 forcing it all to 0 . But the mask is
swapping around to -1 for some reason.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu since r15-4397-g70f59d2a1c51bd

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> Yes but in this case the mask will 0 forcing it all to 0 . But the mask is
> swapping around to -1 for some reason.

Also if you are worried about that, you can do:
```
int a, b, c, d;
static int e[6]={0,0,0,0,0,0};
int main() {
  for (d = 0; d < 6; d++)
if (!c)
  e[d] = 0;
  for (; b < 6; b++)
a = e[b];
  if (a != 0)
__builtin_abort();
  return 0;
}

```
And compile with `-O3 -fno-unswitch-loops -fallow-store-data-races` to have the
same issue.

[Bug target/117192] [15 Regression] wrong code at -O3 with "-fno-unswitch-loops" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed. Works on  aarch64 with `-O3 -fno-unswitch-loops
-fno-vect-cost-model` which produces the same gimple IR .

[Bug c++/116506] [15 Regression] Destructors of temporary awaitables are executed too early

[daklishch at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Dan Klishch  ---
SerenityOS's on-host tests seem to work fine with the patch attached here (this
was the original reproducer) and one from PR116914. Without the later, I hit
ICE similar to one outlined in the gimplify_var_or_parm_decl report.

[Bug middle-end/117195] WIDEN_SUM_EXPR/widen_[us]sum documentation is weak when the second oeprand is 2x the number of elements than other operand

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

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

--- Comment #4 from Richard Biener  ---
Note this tree code (and optab) is useful only for reductions since it is left
unspecified which of the 2x number of input lanes are accumulated to which
output lane (even accumulating _all_ input lanes to only a single of the output
lanes would be OK).

Similar for DOT_PROD_EXPR and SAD_EXPR (lane_reducing_op_p).

I do hope that at some point we kill those off in favor of optabs specifying
how lanes are accumulated (even/odd, hi/lo).  Investigation how the different
ISAs behave here is required.

[Bug c/117197] ICE: 'verify_gimple' failed with vector_size

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
doing

void d() { struct b e; e.a = 2;}

shows

t.c: In function ‘d’:
t.c:5:30: error: incompatible types when assigning to type ‘__vector(1) int’
from type ‘int’
5 | void d() { struct b e; e.a = 2;}
  |  ^

so I'm not sure if the initializer should be considered valid.

If valid I would have expected 'c' to fully initialize the vector and
.a = 2 as well?  But it seems the C frontend interprets e.a as "aggregate".
If that's intended this should be probably documented in the documentation
of the vector extension.

I'll note that

struct b {
  _Complex int a;
};
int c;
void d() { struct b e = {c, .a = 2}; }

results in

  struct b e = {.a=__complex__ (2, 0)};

so there's an (undiagnosed) duplicate initialization of e.a here and .a = 2
fully initializes the _Complex int.

I would have expected the vector int case to behave the same
as the _Complex int case here (but I have no idea whether _Complex handling
is correctly following the standard).

[Bug c/117197] New: ICE: 'verify_gimple' failed with vector_size

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

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

Bug ID: 117197
   Summary: ICE: 'verify_gimple' failed with vector_size
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC) 

***
Program:
$ cat mutant.c
struct b {
  __attribute__((vector_size(4))) int a;
};
int c;
void d() { struct b e = {c, .a = 2}; }

***
Command Lines:
$ gcc mutant.c
mutant.c: In function 'd':
mutant.c:5:6: error: incorrect number of vector 'constructor' elements
5 | void d() { struct b e = {c, .a = 2}; }
  |  ^
{c.0_1, 2}

_2 = {c.0_1, 2};
mutant.c:5:6: internal compiler error: 'verify_gimple' failed
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x1f8b6ad verify_gimple_in_seq(gimple*, bool)
???:0
0x17310df gimplify_body(tree_node*, bool)
???:0
0x17319cc gimplify_function_tree(tree_node*)
???:0
0x124b024 cgraph_node::analyze()
???:0
0x125521b symbol_table::finalize_compilation_unit()
???: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.

It can be compiled normally without vector_size attribute.
Clang does not encounter crash.
Also ICE on trunk.
Compiler Explorer: https://godbolt.org/z/WsrdrqWhY

[Bug target/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')

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

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

--- Comment #8 from Andrew Pinski  ---
;; MEM  [(void *)&reversal] = *.LC1;

(insn 35 34 36 (set (reg:DI 667)
(symbol_ref/f:DI ("*.LC11") [flags 0x2]  ))
"/var/tmp/portage/dev-libs/libgcrypt-1.11.0-r1/work/libgcrypt-1.11.0/cipher/mceliece6688128f.c":2641:22
-1
 (nil))
...

It is hard to debug since it depends on not doing -save-temps ... But LC11 is
not emitted in the object file in the end.

[Bug middle-end/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')

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

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

--- Comment #9 from Andrew Pinski  ---
```
/home/apinski/upstream-gcc/bin/gcc -O3 -shared -fPIC -Wl,--whole-archive
mceliece6688128f.i -Wl,--no-whole-archive -flto=auto -mtls-dialect=gnu2
-march=znver2 -fno-semantic-interposition
```

Is enough.

[Bug middle-end/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
  Component|target  |middle-end

[Bug middle-end/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 59379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59379&action=edit
Reduced testcase

`-O3 -flto -shared -fPIC -march=znver2` reproduces it with this testcase.

[Bug middle-end/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #59379|0   |1
is obsolete||

--- Comment #12 from Andrew Pinski  ---
Created attachment 59380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59380&action=edit
Slightly more reduced

[Bug middle-end/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Note reversal in both functions is the same.

[Bug c/117198] Why are there differences using -Wredundant-decls, is bug or not?

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

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

--- Comment #3 from Andrew Pinski  ---
alias changes the name underneath and is not redundant .

[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085

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

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

Sam James  changed:

   What|Removed |Added

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