[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)

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

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

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

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

commit r16-271-gd1cada7481420a23fbec525548ef5bdf64839a34
Author: H.J. Lu 
Date:   Fri Nov 29 18:22:14 2024 +0800

x86: Add a pass to remove redundant all 0s/1s vector load

For all different modes of all 0s/1s vectors, we can use the single widest
all 0s/1s vector register for all 0s/1s vector uses in the whole function.
Add a pass to generate a single widest all 0s/1s vector set instruction at
entry of the nearest common dominator for basic blocks with all 0s/1s
vector uses.  On Linux/x86-64, in cc1plus, this patch reduces the number
of vector xor instructions from 4803 to 4714 and pcmpeq instructions from
144 to 142.

NB: PR target/92080 and PR target/117839 aren't same.  PR target/117839
is for vectors of all 0s and all 1s with different sizes and different
components.  PR target/92080 is for broadcast of the same component to
different vector sizes.  This patch covers only all 0s and all 1s cases
of PR target/92080.

gcc/

PR target/92080
PR target/117839
* config/i386/i386-features.cc (ix86_place_single_vector_set):
New function.
(remove_partial_avx_dependency): Use it.
(ix86_get_vector_load_mode): New function.
(replace_vector_const): Likewise.
(remove_redundant_vector_load): Likewise.
(pass_data_remove_redundant_vector_load): Likewise.
(pass_remove_redundant_vector_load): Likewise.
(make_pass_remove_redundant_vector_load): Likewise.
* config/i386/i386-passes.def: Add
pass_remove_redundant_vector_load after
pass_remove_partial_avx_dependency.
* config/i386/i386-protos.h
(make_pass_remove_redundant_vector_load): New.
* config/i386/i386.cc (ix86_modes_tieable_p): Return true for
narrower non-scalar-integer modes in SSE registers.

gcc/testsuite/

PR target/92080
PR target/117839
* gcc.target/i386/pr117839-1a.c: New test.
* gcc.target/i386/pr117839-1b.c: Likewise.
* gcc.target/i386/pr117839-2.c: Likewise.
* gcc.target/i386/pr92080-1.c: Likewise.
* gcc.target/i386/pr92080-2.c: Likewise.
* gcc.target/i386/pr92080-3.c: Likewise.

Signed-off-by: H.J. Lu 

[Bug target/117839] Redundant vector XOR instructions

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

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

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

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

commit r16-271-gd1cada7481420a23fbec525548ef5bdf64839a34
Author: H.J. Lu 
Date:   Fri Nov 29 18:22:14 2024 +0800

x86: Add a pass to remove redundant all 0s/1s vector load

For all different modes of all 0s/1s vectors, we can use the single widest
all 0s/1s vector register for all 0s/1s vector uses in the whole function.
Add a pass to generate a single widest all 0s/1s vector set instruction at
entry of the nearest common dominator for basic blocks with all 0s/1s
vector uses.  On Linux/x86-64, in cc1plus, this patch reduces the number
of vector xor instructions from 4803 to 4714 and pcmpeq instructions from
144 to 142.

NB: PR target/92080 and PR target/117839 aren't same.  PR target/117839
is for vectors of all 0s and all 1s with different sizes and different
components.  PR target/92080 is for broadcast of the same component to
different vector sizes.  This patch covers only all 0s and all 1s cases
of PR target/92080.

gcc/

PR target/92080
PR target/117839
* config/i386/i386-features.cc (ix86_place_single_vector_set):
New function.
(remove_partial_avx_dependency): Use it.
(ix86_get_vector_load_mode): New function.
(replace_vector_const): Likewise.
(remove_redundant_vector_load): Likewise.
(pass_data_remove_redundant_vector_load): Likewise.
(pass_remove_redundant_vector_load): Likewise.
(make_pass_remove_redundant_vector_load): Likewise.
* config/i386/i386-passes.def: Add
pass_remove_redundant_vector_load after
pass_remove_partial_avx_dependency.
* config/i386/i386-protos.h
(make_pass_remove_redundant_vector_load): New.
* config/i386/i386.cc (ix86_modes_tieable_p): Return true for
narrower non-scalar-integer modes in SSE registers.

gcc/testsuite/

PR target/92080
PR target/117839
* gcc.target/i386/pr117839-1a.c: New test.
* gcc.target/i386/pr117839-1b.c: Likewise.
* gcc.target/i386/pr117839-2.c: Likewise.
* gcc.target/i386/pr92080-1.c: Likewise.
* gcc.target/i386/pr92080-2.c: Likewise.
* gcc.target/i386/pr92080-3.c: Likewise.

Signed-off-by: H.J. Lu 

[Bug target/117839] Redundant vector XOR instructions

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 16.

[Bug target/117547] FAIL: gcc.target/i386/*-pr93673.c without TARGET_PROMOTE_PROTOTYPES

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 16.

[Ada] incorrectly specified array of record aggregates in protected object causes bug box in GNAT 12.2.0

[babiak via Gcc-bugs]

(Sorry if I included too much information, this is my first time making 
a manual bug report by email.)


I ran into this error when I forgot to specify all the elements in an 
array aggregate, but instead of a compiler error or warning, I got a bug 
box. To be specific: Inside a protected object, I have an array of 
records. Instead of specifying it with a full list of elements, I forgot 
to say "others =>" before the record aggregate I intended to use for all 
elements. That is, `variable: array_type:= [[record_element=>Value]];`. 
This triggered a bug box, saying the error was detected at the beginning 
of the protected object's spec.


The minimal example I came up with is attached.

The bug appears for both discriminated and non-discriminated records, 
but only if the variable definition is inside a protected object. Or at 
least, I haven't found any other ways to trigger it. The output of 
gnatmake, complete with bug box is below:


=== BEGIN ===
$ gnatmake bug -gnat2022
x86_64-linux-gnu-gcc-12 -c -gnat2022 bug.adb
+===GNAT BUG DETECTED==+
| 12.2.0 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous 
memory access|

| Error detected at bug.adb:11:5   |
| Compiling bug.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

bug.adb

bug.adb:13:35: warning: too few elements for type "struct_array" defined 
at line 9 [enabled by default]
bug.adb:13:35: warning: expected 2 elements; found 1 element [enabled by 
default]

compilation abandoned
gnatmake: "bug.adb" compilation error
=== END ===

As can be seen, the exact command line passed to GCC was 
"x86_64-linux-gnu-gcc-12 -c -gnat2022 bug.adb". I have compiled this 
code with various other flags, and it persists (the gnat2022 flag is 
needed for the aggregate syntax I'm using).


I am running a Devuan linux machine (debian-based, without Systemd), 
with `uname -a` saying "Linux hostname 6.1.0-32-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64 GNU/Linux"


The output of `gcc -v` is below:

=== BEGIN ===
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr 
--enable-offload-defaulted --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)
=== END ===

I would expect to either have the "too few elements for type" warning to 
cause an error, or the compiler to compile normally and fail at runtime 
with a constraint_error: range check failed.
Or maybe fail with some other error, such as about how the protected 
object doesn't have a body (it can have a body, it's just not needed for 
the bug to appear).

Instead, I get the bug box, as included above.

Sorry again if I included the wrong information, or formatted the email 
wrong or anything like that. It's my first time using a gnu mailing list.-- compile with gnatmake -gnat2022
procedure bug is
type index is range 1..

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

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

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

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

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

commit r16-276-gaa29654b1128a572c97fcaba94095f493662a0db
Author: Uros Bizjak 
Date:   Tue Apr 29 10:25:45 2025 +0200

i386: Allow string instructions from non-default address space [PR111657]

MOVS instructions allow segment override of their source operand, e.g.:

rep movsq %gs:(%rsi), (%rdi)

where %rsi is the address of the source location (with %gs segment
override)
and %rdi is the address of the destination location.

The testcase improves from (-O2 -mno-sse -mtune=generic):

xorl%eax, %eax
.L2:
movl%eax, %edx
addl$8, %eax
movq%gs:m(%rdx), %rcx
movq%rcx, (%rdi,%rdx)
cmpl$240, %eax
jb  .L2
ret

to:
movl$m, %esi
movl$30, %ecx
rep movsq %gs:(%rsi), (%rdi)
ret

PR target/111657

gcc/ChangeLog:

* config/i386/i386-expand.cc (alg_usable_p): Remove have_as bool
argument and add dst_as and src_as address space arguments.  Reject
libcall algorithm with dst_as and src_as in the non-default address
spaces.  Reject rep_prefix_{1,4,8}_byte algorithms with dst_as in
the non-default address space.
(decide_alg): Remove have_as bool argument and add dst_as and
src_as
address space arguments.  Update calls to alg_usable_p.
(ix86_expand_set_or_cpymem): Update call to decide_alg.
* config/i386/i386.md (strmov): Do not fail if operand[3] (source)
is in the non-default address space.  Expand with
gen_strmov_singleop
only when operand[1] (destination) is in the default address space.
(*strmovdi_rex_1): Determine memory operands from insn pattern.
Allow only when destination is in the default address space.
Rewrite asm template to use explicit operands.
(*strmovsi_1): Ditto.
(*strmovhi_1): DItto.
(*strmovqi_1): Ditto.
(*rep_movdi_rex64): Ditto.
(*rep_movsi): Ditto.
(*rep_movqi): Ditto.
(*strsetdi_rex_1): Determine memory operands from insn pattern.
Allow only when destination is in the default address space.
(*strsetsi_1): Ditto.
(*strsethi_1): Ditto.
(*strsetqi_1): Ditto.
(*rep_stosdi_rex64): Ditto.
(*rep_stossi): Ditto.
(*rep_stosqi): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr111657-1.c: New test.

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #13 from Uroš Bizjak  ---
Fully implemented for gcc-16.

[Bug tree-optimization/119960] [15/16 Regression] vectorizer seems not to do as much any more since r15-5863

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

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

--- Comment #7 from Richard Biener  ---
So I do have a patch amending the r15-5863 revision to allow vectorizing the
cases again but it regresses gcc.dg/vect/pr116352.c (the testcase the code
was added for) since we run into a similar issue in SLP scheduling then,
which tries to order "unordered" SSA defs with code like

/* We are emitting all vectorized stmts in the same place and
   the last one is the last.
   ???  Unless we have a load permutation applied and that
   figures to re-use an earlier generated load.  */
unsigned j;
tree vdef;
FOR_EACH_VEC_ELT (SLP_TREE_VEC_DEFS (child), j, vdef)
  {
gimple *vstmt = SSA_NAME_DEF_STMT (vdef);
if (!last_stmt
|| vect_stmt_dominates_stmt_p (last_stmt, vstmt))
  last_stmt = vstmt;
  }

where the main issue is that we do not verify we actually _can_ schedule
the SLP graph onto the existing CFG.  Without inserting PHIs, specifically
LC PHIs, where necessary when for example instead trying to insert at the
hopefully single block of the dominance frontier.

So for now we have to accept the regression and eventually get to the TODO
to actually implement a scheduling feasability check (since we already
fail to ensure trivial schedulability given vectors eventually are combined
from defs from different parts of the CFG).

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Unrolling the infinite loop is what happens.

Anyways as mentioned the infinite loop is expected so closing as invalid.

[Bug c/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

[Chris.Bazley at arm dot com via Gcc-bugs]

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

--- Comment #5 from Chris Bazley  ---
Patch has been emailed to gcc-patc...@gcc.gnu.org for review.

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Without -fpic/-fPIC, the code gcc outputs will never be always position
independent. So using a constant pool for the address is correct.

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

[gcc--- via Gcc-bugs]

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

Thomas Weißschuh  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Thomas Weißschuh  ---
(In reply to Andrew Pinski from comment #1)
> Without -fpic/-fPIC, the code gcc outputs will never be always position
> independent.

With -fpic/-fPIC the same thing happens.

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vincenzo Romano  ---
Id the double amoor op intentional?

If so, why?

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #4 from Jonathan Wakely  ---
It stopped aborting with r14-2709-g65ff4a45b11b5ab13ef849bd5721ab28ff316202

Author: Jan Hubicka
AuthorDate: Fri Jul 21 13:54:23 2023

loop-ch improvements, part 5

Currently loop-ch skips all do-while loops.  But when loop is not do-while
in addition to original goal of turining it to do-while it can do
additional
things:
 1) move out loop invariant computations
 2) duplicate loop invariant conditionals and eliminate them in loop body.
 3) prove that some exits are always true in first iteration
and can be skipped

Most of time 1 can be done by lim (exception is when the invariant
computation
is conditional). For 2 we however don't really have other place doing it
except
for loop unswitching that is more expensive (it will duplicate the loop and
then optimize out one path to non-loop).
3 can be done by loop peeling but it is also more expensive by duplicating
full
loop body.

This patch improves heuristics by not giving up on do-while loops and
trying
to find sequence of BBs to duplicate to obtain one of goals:
 - turn loop to do-while
 - eliminate invariant conditional in loop body
 - do partial "peeling" as long as code optimizes enough so this does not
   increase code size.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #6 from Jonathan Wakely  ---
Using -fno-finite-loops prevents the assertion from failing:


-ffinite-loops

  Assume that a loop with an exit will eventually take the exit and not loop
indefinitely.
  This allows the compiler to remove loops that otherwise have no side-effects,
not
  considering eventual endless looping as such.

  This option is enabled by default at -O2 for C++ with -std=c++11 or higher.


I think GCC is behaving as expected (although I'm not sure why r14-2709 changed
it).

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #7 from Jonathan Wakely  ---
N.B. with -O3 we just exit without aborting or looping, even after r14-2709.
That's OK, because the behaviour is undefined. It would be nice if we inserted
an unreachable or a trap that -fsanitize=undefined could diagnose.

Use -fno-finite-loops to make GCC accept the code as valid.

[Bug target/113484] Add support for _Float16 type on PowerPC

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from John Platts  ---
(In reply to Segher Boessenkool from comment #4)
> Ah, this was about *actual* half-precision float, which indeed is 3.0
> (Power9).
> 
> But all the same holds: it needs to be added to the ABI before we can have a
> type for it, and it still won't be terribly useful (it will make for *slowe
> code*, not using fewer resources either).

There were plans to add support for the _Float16 and __vector _Float16 types to
the POWER 64-bit ELF V2 ABI according to Version 1.4 of that specification that
can be found at https://files.openpower.foundation/s/aqwWeS3qmoaDyos.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #5 from Jonathan Wakely  ---
It started aborting with r272234 aka r10-1052-gc29c92c789d938

Author: Feng Xue
AuthorDate: Thu Jun 13 05:17:42 2019

PR tree-optimization/89713 - Assume loop with an exit is finite

gcc/ChangeLog:

* doc/invoke.texi (-ffinite-loops): Document new option.
* common.opt (-ffinite-loops): New option.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Mark
IFN_GOACC_LOOP calls as necessary.
* tree-ssa-loop-niter.c (finite_loop_p): Assume loop with an exit
is finite.
* omp-offload.c (oacc_xform_loop): Skip lowering if return value of
IFN_GOACC_LOOP call is not used.
* opts.c (default_options_table): Enable -ffinite-loops at -O2+.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #8 from Jonathan Wakely  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html changed
the rules (voted into C++26 and as a DR against previous standards). But it
only affects certain syntactic forms of loop, and this goto loop doesn't count.

[Bug c++/119806] OpenACC, OpenMP 'target' offloading vs. C++ 'typeinfo' parts

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

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

--- Comment #2 from Thomas Schwinge  ---
Similarly (I suppose, but have not checked the details), OpenMP_VV
'tests/5.0/application_kernels/declare_target_base_and_derived_class.cpp':

GCN:

ld: error: undefined symbol: vtable for S1
>>> referenced by /tmp/ccWZSCBY.o:(.data.rel.ro.local+0x0)
>>> the vtable symbol may be undefined because the class is missing its key
function (see https://lld.llvm.org/missingkeyfunction)
collect2: error: ld returned 1 exit status
gcn mkoffload: fatal error:
$T/install/bin/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 exit
status

nvptx:

ptxas /tmp/cci1PjSv.o, line 397; error   : Unknown symbol '_ZTV2S1'
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
nvptx mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status

$ c++filt _ZTV2S1
vtable for S1

[Bug c++/119844] Incomplete types are displayed after the import module

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||nshead at gcc dot gnu.org

--- Comment #2 from Nathaniel Shead  ---
I haven't attempted to fully reproduce, but it appears to me you have something
like the following:

  // user.cpp
  export module User;
  export struct User {
int value;
  };

  // main.cpp
  struct User;
  struct MainWindow {
User* u;
  };
  import User;
  int foo(MainWindow m) {
return m.u->value;
  }

$ g++-15 -fmodules -S user.cpp main.cpp
main.cpp: In function ‘int foo(MainWindow)’:
main.cpp:7:13: error: invalid use of incomplete type ‘struct User’
7 |   return m.u->value;
  | ^~
main.cpp:1:8: note: forward declaration of ‘struct User’
1 | struct User;
  |^~~~

This error is expected (though the diagnostic could definitely be improved!):
'User' (in main.cpp) and 'User@User' (in user.cpp) are unrelated, distinct
types; the former belonging to the global module, and the latter attached to
the module 'User'.  You can see this by comparing e.g.:

  // main.cpp
  struct User;
  import User;
  User u;

$ g++-15 -fmodules -S user.cpp main.cpp
main.cpp:3:1: error: reference to ‘User’ is ambiguous
3 | User u;
  | ^~~~
In module User, imported at main.cpp:2:
user.cpp:2:15: note: candidates are: ‘struct User@User’
2 | export struct User {
  |   ^~~~
main.cpp:1:8: note: ‘struct User’
1 | struct User;
  |^~~~

To fix the issue, you could defined user.cpp as something like this:

  // user.cpp
  export module User;
  export extern "C++" struct User {
int value;
  };

The 'extern "C++"' ensures that 'User' is declared attached to the global
module.

I'll leave this PR open for now for the diagnostic issue, however, as I imagine
this to be a common mistake, and we should be able to detect this and emit some
kind of note pointing to the conflicting type.

[Bug middle-end/120003] New: Missed Optimisation / Regression

[phdiv at fastmail dot fm via Gcc-bugs]

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

Bug ID: 120003
   Summary: Missed Optimisation / Regression
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phdiv at fastmail dot fm
  Target Milestone: ---

Consider the following code:

  extern bool g(int);

  bool f(){
bool retval = false;
for(int i=0; i<1'000'000; ++i)
retval = retval || g(i);
return retval;
  }

Up until GCC 11, it was recognised that the loop can be exited as soon
as the first call to  g  returns true. Since GCC 12, and present up to 15,
the loop keeps on incrementing needlessly.

https://godbolt.org/z/q5qKbcoMG

[Bug target/119235] Argument pointer survives LRA with -m31 -mzarch

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Stefan Schulze Frielinghaus
:

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

commit r12-11075-gd41ce9f7c392d5110a63d61c4c85fb7a5f2f
Author: Stefan Schulze Frielinghaus 
Date:   Fri Mar 21 10:29:19 2025 +0100

s390: Accept only Pmode for registers AP/FP/RA [PR119235]

gcc/ChangeLog:

PR target/119235
* config/s390/s390.cc (s390_hard_regno_mode_ok): Accept only
Pmode for registers AP/FP/RA.

(cherry picked from commit 2b383ae2a6e5fc0530bfd8b86ad0e6b27e760bd2)

[Bug c/120001] New: On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

Bug ID: 120001
   Summary: On RISC-V with -O2 and -O3 __sync_or_and_fetch in a
loop renders as an endless loop and multiple amoor
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.romano at gmail dot com
  Target Milestone: ---

This code:

#define LOCK_BIT ((unsigned long)(1ul<<(8*sizeof(long)-1)))

void lock_hold(long* lock) {
  while(__sync_or_and_fetch(lock,LOCK_BIT) < 0);
  __sync_synchronize();
}


with -O2 and -O3 renders as:

lock_hold:
li  a5,-1
sllia5,a5,63
.L2:
amoor.d.aqrla4,a5,0(a0)
amoor.d.aqrla4,a5,0(a0)
j   .L2

(Please also note the double amoor instruction).
Similarly, with -Os it renders as:

lock_hold:
li  a5,-1
sllia5,a5,63
.L2:
amoor.d.aqrla4,a5,0(a0)
j   .L2

(Please also note the single amoor instruction).

Instead, with -O1 I get more reasonably:

lock_hold:
li  a5,-1
sllia5,a5,63
.L2:
amoor.d.aqrla4,a5,0(a0)
or  a5,a5,a4
blt a5,zero,.L2
fence   rw,rw
ret

With -O0 I get something similar to the code generated with -O1.

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #15 from Thomas Schwinge  ---
*** Bug 110800 has been marked as a duplicate of this bug. ***

[Bug target/119235] Argument pointer survives LRA with -m31 -mzarch

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Fixed.

gcc-bugs@gcc.gnu.org

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

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

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

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

commit r16-281-gfc62834533f357125b9c1934f80c2ba249adbf9e
Author: Richard Biener 
Date:   Tue Apr 29 11:06:36 2025 +0200

tree-optimization/119997 - &ptr->field no longer subject to PRE

The following makes PRE handle &ptr->field the same as VN by
treating it as a POINTER_PLUS_EXPR when possible and thus as
'nary'.  To facilitate this the patch splits out vn_pp_nary_for_addr
and adds const overloads for vec::last.  The patch also avoids
handling an effective zero offset as POINTER_PLUS_EXPR.

PR tree-optimization/119997
* vec.h (vec::last): Provide const overload.
(vec::last): Likewise.
* tree-ssa-sccvn.h (vn_pp_nary_for_addr): Declare.
* tree-ssa-sccvn.cc (vn_pp_nary_for_addr): Split out from ...
(vn_reference_lookup): ... here.
(vn_reference_insert): ... and duplicate here.  Do not handle
zero offset as POINTER_PLUS_EXPR.
* tree-ssa-pre.cc (compute_avail): Implement
ADDR_EXPR-as-POINTER_PLUS_EXPR special casing.

* gcc.dg/tree-ssa/ssa-pre-35.c: New testcase.

gcc-bugs@gcc.gnu.org

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||13.1.0, 15.1.0
Summary|[13/14/15/16 Regression]|[13/14/15 Regression] PRE
   |PRE no longer hoists|no longer hoists
   |&ptr->field |&ptr->field
  Known to work||12.4.0, 16.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk, I don't think backporting is worthwhile.

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.3

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

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

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

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

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

commit r16-282-gaa93272cfd2233858da0792761387cc27f4d5ff3
Author: Patrick Palka 
Date:   Tue Apr 29 08:21:35 2025 -0400

libstdc++: Fix availability of std::erase_if(std::flat_foo) [PR119427]

These std::erase_if overloads were wrongly implemented as hidden
friends, visible only via ADL, so erase_if(x) would work but not
std::erase_if(x).

PR libstdc++/119427

libstdc++-v3/ChangeLog:

* include/std/flat_map (_Flat_map_impl::erase_if): Replace
this hidden friend with ...
(_Flat_map_impl::_M_erase_if): ... this member function.
(flat_map): Export _Flat_map_impl::_M_erase_if.
(erase_if(flat_map)): Define.
(flat_multimap): Export _Flat_map_impl::_M_erase_if.
(erase_if(flat_multimap)): Define.
* include/std/flat_set (_Flat_set_impl::erase_if): Replace
with ...
(_Flat_set_impl::_M_erase_if): ... this member function.
(flat_set): Export _Flat_set_impl::_M_erase_if.
(erase_if(flat_set)): Define.
(flat_multiset): Export _Flat_set_impl::_M_erase_if.
(erase_if(flat_multiset)): Define.
* testsuite/23_containers/flat_map/1.cc (test07): New test.
* testsuite/23_containers/flat_multimap/1.cc (test07): New test.
* testsuite/23_containers/flat_multiset/1.cc (test09): New test.
* testsuite/23_containers/flat_set/1.cc (test09): New test.

Reviewed-by: Jonathan Wakely 

[Bug c++/104734] -isystem hides -Woverloaded-virtual warning

[eugene.shalygin at gmail dot com via Gcc-bugs]

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

Eugene Shalygin  changed:

   What|Removed |Added

 CC||eugene.shalygin at gmail dot 
com

--- Comment #6 from Eugene Shalygin  ---
Moreover, if the inherited class is not in the system header, to silence the
warning one has to put the diagnostic ignoring pragma before the function in
the base class, and not at the point when the mistake is made:
https://godbolt.org/z/984qfzzcf

[Bug target/119900] [16 regression] imagick slowdown with -Ofast -march=native -fprofile-use since r16-39-gf6859fb621179e (interaction of rpad and late-combine)

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
Summary|[16 regression] imagick |[16 regression] imagick
   |slowdown with -Ofast|slowdown with -Ofast
   |-march=native -fprofile-use |-march=native -fprofile-use
   |since   |since
   |r16-39-gf6859fb621179e  |r16-39-gf6859fb621179e
   ||(interaction of rpad and
   ||late-combine)
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-29

--- Comment #4 from Jan Hubicka  ---
The problem is interaction of the size_costs change. Either this patch
reverting this change:

diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index cddcf617304..a2512c7209a 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -121,17 +121,17 @@ struct processor_costs ix86_size_cost = {/* costs for
tuning for size */
   COSTS_N_BYTES (2),   /* cost of FCHS instruction.  */
   COSTS_N_BYTES (2),   /* cost of FSQRT instruction.  */

-  COSTS_N_BYTES (4),   /* cost of cheap SSE instruction.  */
-  COSTS_N_BYTES (4),   /* cost of ADDSS/SD SUBSS/SD insns.  */
-  COSTS_N_BYTES (4),   /* cost of MULSS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of MULSD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of FMA SS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of FMA SD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of DIVSS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of DIVSD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of SQRTSS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of SQRTSD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of CVTSS2SD etc.  */
+  COSTS_N_BYTES (2),   /* cost of cheap SSE instruction.  */
+  COSTS_N_BYTES (2),   /* cost of ADDSS/SD SUBSS/SD insns.  */
+  COSTS_N_BYTES (2),   /* cost of MULSS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of MULSD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of FMA SS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of FMA SD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of DIVSS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of DIVSD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of SQRTSS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of SQRTSD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of CVTSS2SD etc.  */
   COSTS_N_BYTES (4),   /* cost of 256bit VCVTPS2PD etc.  */
   COSTS_N_BYTES (6),   /* cost of 512bit VCVTPS2PD etc.  */
   1, 1, 1, 1,  /* reassoc int, fp, vec_int, vec_fp. 
*/

or -fno-late-combine-instructions avoids the performance regression.

The internal loop of imagick is considered cold with FDO since train run does
not train it at all.  We end up changing:

@@ -1156,9 +1156,8 @@
callParseGeometry
vmovsd  16(%rsp), %xmm7
vmovsd  .LC30(%rip), %xmm4
-   vxorps  %xmm3, %xmm3, %xmm3
-   testb   $4, %al
vmovsd  %xmm7, 8(%rsp)
+   testb   $4, %al
jne .L210
 .L166: 
vmovapd %xmm4, %xmm2



jne .L211
 .L167: 
vmovsd  .LC31(%rip), %xmm5
-   vcvtusi2sdq %r13, %xmm3, %xmm1
+   vcvtusi2sdq %r13, %xmm1, %xmm1
vmulsd  %xmm5, %xmm1, %xmm0

So previously we clared xmm3 and used it in integer->fp conversions while after
the patch we don't do this resulting in false dependency on xmm1.
The clear is introduced by the i386 specific rpad pass that is disabling itself
for functions optimized for size, but in this case the function contains hold
and cold region, so it inserts xors also into cold part of the program.

bool
ix86_rpad_gate ()
{   
  return (TARGET_AVX
  && TARGET_SSE_PARTIAL_REG_DEPENDENCY
  && TARGET_SSE_MATH
  && optimize
  && optimize_function_for_speed_p (cfun));
}  

I suppose it would make sense to disable RPAD for cold regions of the program
(which would make situation worse for imagick though).

This is now undone by late combine pass:

trying to combine definition of r24 in:
  388: xmm4:V2DF=vec_merge(vec_duplicate(uns_float(r14:DI)),xmm3:V2DF,0x1)
into:
  486: xmm4

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #3 from Andrew Pinski  ---
.LC0:
.xword  hidden_symbol+65537

Is still valid for all shared libraries.

The problem is you want a DSO with no dynamic relocations but that won't work
here.

If you want that you should do the similar thing as what the 32bit compat does
for a similar reasons:
```
static __always_inline const struct vdso_time_data
*__arch_get_vdso_u_time_data(void)
{
const struct vdso_time_data *ret;

/*
 * This simply puts &_vdso_time_data into ret. The reason why we don't
use
 * `ret = _vdso_time_data` is that the compiler tends to optimise this
in a
 * very suboptimal way: instead of keeping &_vdso_time_data in a
register,
 * it goes through a relocation almost every time _vdso_time_data must
be
 * accessed (even in subfunctions). This is both time and space
 * consuming: each relocation uses a word in the code section, and it
 * has to be loaded at runtime.
 *
 * This trick hides the assignment from the compiler. Since it cannot
 * track where the pointer comes from, it will only use one relocation
 * where __aarch64_get_vdso_u_time_data() is called, and then keep the
 * result in a register.
 */
asm volatile("mov %0, %1" : "=r"(ret) : "r"(&vdso_u_time_data));

return ret;
}
```

[Bug c++/119964] [15/16 regression] GCC 15 does not delete explicitly-defaulted move constructor with (const T&&) parameter

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Mine then.

[Bug c/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

[gandalf at winds dot org via Gcc-bugs]

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

--- Comment #6 from Byron Stanoszek  ---
I confirm that Chris's patch does indeed fix the compile issue.

Thanks!

[Bug middle-end/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

--- Comment #1 from Andrew Pinski  ---
Maybe r12-3453-g01b5038718056b024b370b74a874fbd92c5bbab3 .

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

[gcc--- via Gcc-bugs]

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

Thomas Weißschuh  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Thomas Weißschuh  ---
(In reply to Andrew Pinski from comment #3)
> .LC0:
> .xword  hidden_symbol+65537
> 
> Is still valid for all shared libraries.
>
> The problem is you want a DSO with no dynamic relocations but that won't
> work here.

Is there another way to prevent GCC from emitting absolute relocations?
Similar to how this code works with clang or -mcmodel=small?

> If you want that you should do the similar thing as what the 32bit compat
> does for a similar reasons.

This is what I am doing for now:
https://lore.kernel.org/lkml/20250429-vdso-absolute-reloc-v1-1-987a0afd1...@linutronix.de/
Unfortunately this only fixes one single location. New ones may crop up at any
time.

It doesn't seem to me that the reasons are similar.
The compat code does it for efficiency while the non-compat code now needs it
for correctness.

If this behavior is expected then it could also affect all other architectures,
no?

[Bug tree-optimization/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
  Component|middle-end  |tree-optimization
 CC||amacleod at redhat dot com

[Bug middle-end/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

--- Comment #2 from Richard Biener  ---
I bet it's caused by some jump threading changes for FSM threading
opportunities.

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Vincenzo Romano from comment #4)
> Id the double amoor op intentional?
> 
> If so, why?

I said why:
Unrolling the infinite loop is what happens.

We copy the inner basic block of the loop to "unroll" it during bb reordering.
It happens on many targets but it is due to the infinite loop.

[Bug target/110800] [gcn] ICE (segfault) 'during RTL pass: jump' in delete_trivially_dead_insns -> count_reg_usage when C++ exceptions are enabled + used

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |15.0

--- Comment #3 from Thomas Schwinge  ---
Resolved via commit r15-9470-gfe283dba774be57b705a7a871b000d2894d2e553 "GCN,
nvptx: Support '-mfake-exceptions', and use it for offloading compilation
[PR118794]", and for nvptx offloading additionally commit
r15-8719-g65b31b3fff2fced015ded1026733605f34053796 "nvptx: In offloading
compilation, special-case certain host-setup symbol aliases [PR101544]".

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

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Vincenzo Romano  ---
Please, mark this bug as INVALID.
At least for the endless loop part.
I am not sure about the double amoor instruction, though.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

  Attachment #61234|0   |1
is obsolete||

--- Comment #28 from LIU Hao  ---
Created attachment 61236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61236&action=edit
proposed patch #2

It might not be safe to decrease the preferred stack boundary, so let's keep it
as 16, but initialize `ix86_default_incoming_stack_boundary` to 4 bytes
instead.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

  Attachment #61236|0   |1
is obsolete||

--- Comment #29 from LIU Hao  ---
Created attachment 61237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61237&action=edit
proposed patch #3

[Bug c/120002] New: R_AARCH64_ABS64 emitted against hidden symbol

[gcc--- via Gcc-bugs]

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

Bug ID: 120002
   Summary: R_AARCH64_ABS64 emitted against hidden symbol
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@t-8ch.de
  Target Milestone: ---

Relocations against involving hidden symbols should be PC-relative.
However on aarch64 with -mcmodel=tiny an absolute relocation may be emitted if
the offset to the symbol exceeds 64KiB.

Reproducer:

$ cat test.c
extern char hidden_symbol[] __attribute__((visibility("hidden")));

void *function(void)
{
void *ptr;

ptr = &hidden_symbol;
/* Works until 64 * 1024 */
ptr += 64 * 1024 + 1;

return ptr;
}

$ aarch64-linux-gnu-gcc test.c -c -o test.o -mcmodel=tiny -O2
$ aarch64-linux-gnu-objdump --section .text --disassemble-all
--disassemble-zeroes --reloc test.o

test.o: file format elf64-littleaarch64


Disassembly of section .text:

 :
   0:   5840ldr x0, 8 
   4:   d65f03c0ret
   8:   udf #0
8: R_AARCH64_ABS64  hidden_symbol+0x10001
   c:   udf #0



Background:

This setup is used in the Linux vDSO to achieve completely position independent
code. Some recent refactors triggered this bug.
https://lore.kernel.org/lkml/aApGPAoctq_eoE2g@t14ultra/

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vincenzo Romano  ---
If I put __sync_fetch_and_or instead of __sync_or_and_fetch I objously get the
expected behavior as fas as the endless loop is concerned.

[Bug tree-optimization/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/119980] wrong aliasing decision with structure acces

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-29
  Component|rtl-optimization|target
 Target||x86_64-*-*
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
Version|unknown |16.0

--- Comment #3 from Richard Biener  ---
Yes, it looks very very similar.

In peephole2 the redundant load/store pair keeping the = 2 store data
dependent on the later load vanishes (with -fdisable-rtl-combine, otherwise
combine deletes it, see PR101641).  Then sched2 comes along and
breaks things.

So, -fdisable-rtl-combine -fdisable-rtl-peephole2 fixes this.  Let's keep
this instance of the bug for the peephole2 bug.  These kind of peepholes
might not apply before scheduling at least - in reality after such
patterns -fno-strict-aliasing should be enforced.

;; Attempt to optimize away memory stores of values the memory already
;; has.  See PR79593.
(define_peephole2
  [(set (match_operand 0 "register_operand")
(match_operand 1 "memory_operand"))
   (set (match_operand 2 "memory_operand") (match_dup 0))]
  "!MEM_VOLATILE_P (operands[1])
   && !MEM_VOLATILE_P (operands[2])
   && rtx_equal_p (operands[1], operands[2])
   && !reg_overlap_mentioned_p (operands[0], operands[2])"
  [(set (match_dup 0) (match_dup 1))])

[Bug target/117547] FAIL: gcc.target/i386/*-pr93673.c without TARGET_PROMOTE_PROTOTYPES

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

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

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

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

commit r16-270-ga0a64aa5da0af5ecb022675cdb9140ccfa098ce3
Author: H.J. Lu 
Date:   Tue Nov 12 09:03:31 2024 +0800

i386: Add ix86_expand_unsigned_small_int_cst_argument

When passing 0xff as an unsigned char function argument with the C frontend
promotion, expand_normal used to get

 constant
255>

and returned the rtx value using the sign-extended representation:

(const_int 255 [0xff])

But after

commit a670ebde3995481225ec62b29686ec07a21e5c10
Author: H.J. Lu 
Date:   Thu Nov 21 07:54:35 2024 +0800

Drop targetm.promote_prototypes from C, C++ and Ada frontends

expand_normal now gets

 constant 255>

and returns

 (const_int -1 [0x])

which doesn't work with the predicates nor the instruction templates which
expect the unsigned expanded value.  Extract the unsigned char and short
integer constants to return

(const_int 255 [0xff])

so that the expanded value is always unsigned, without the C frontend
promotion.

PR target/117547
* config/i386/i386-expand.cc
(ix86_expand_unsigned_small_int_cst_argument):
New function.
(ix86_expand_args_builtin): Call
ix86_expand_unsigned_small_int_cst_argument to expand the argument
before calling fixup_modeless_constant.
(ix86_expand_round_builtin): Likewise.
(ix86_expand_special_args_builtin): Likewise.
(ix86_expand_builtin): Likewise.

Signed-off-by: H.J. Lu 

[Bug target/119980] wrong aliasing decision with structure acces

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> Yes, it looks very very similar.
> 
> In peephole2 the redundant load/store pair keeping the = 2 store data
> dependent on the later load vanishes (with -fdisable-rtl-combine, otherwise
> combine deletes it, see PR101641).  Then sched2 comes along and
> breaks things.
> 
> So, -fdisable-rtl-combine -fdisable-rtl-peephole2 fixes this.  Let's keep
> this instance of the bug for the peephole2 bug.  These kind of peepholes
> might not apply before scheduling at least - in reality after such
> patterns -fno-strict-aliasing should be enforced.
> 
> ;; Attempt to optimize away memory stores of values the memory already
> ;; has.  See PR79593.
> (define_peephole2
>   [(set (match_operand 0 "register_operand")
> (match_operand 1 "memory_operand"))
>(set (match_operand 2 "memory_operand") (match_dup 0))]
>   "!MEM_VOLATILE_P (operands[1])
>&& !MEM_VOLATILE_P (operands[2])
>&& rtx_equal_p (operands[1], operands[2])
>&& !reg_overlap_mentioned_p (operands[0], operands[2])"
>   [(set (match_dup 0) (match_dup 1))])

Possibly the following would fix it (not sure where to place the required
#include of alias.h)

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e170da3b0e6..3cfb54abbd0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -28489,6 +28489,7 @@
   "!MEM_VOLATILE_P (operands[1])
&& !MEM_VOLATILE_P (operands[2])
&& rtx_equal_p (operands[1], operands[2])
+   && mems_same_for_tbaa_p (operands[1], operands[2])
&& !reg_overlap_mentioned_p (operands[0], operands[2])"
   [(set (match_dup 0) (match_dup 1))])

[Bug c++/119999] New: Wrong Pointer Comparison in GCC 10/11/12/13 with -Os/-Oz Flags

[bouncy12578 at gmail dot com via Gcc-bugs]

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

Bug ID: 11
   Summary: Wrong Pointer Comparison  in GCC 10/11/12/13 with
-Os/-Oz Flags
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bouncy12578 at gmail dot com
  Target Milestone: ---

***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.1.0-8ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada
,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-l
inker-build-id --libexecdir=/usr/libexec --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap
--enable-clocale=gnu --e
nable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-defaul
t-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --
with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-IvzKaI/gcc
-13-13.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-IvzKaI/gcc-13-13.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04)

***
Program:
$ cat a.cpp
#include 
int a = 0;
static int b = 1;

void f(int * p){ 
l:
assert (p == &a);
if (b)
goto l;
}
int * g(){
return &a;
}

int main(int argc, char* argv[]){
f(g());
return 0;
}

***
Command Lines:
$ gcc a.cpp -o a.out -Os && ./a.out
a.out: a.cpp:7: void f(int*): Assertion `p == &a' failed.
Aborted

fail in gcc 10/11/12/13 with -Os/-Oz

[Bug c++/119998] New: ICE (segfault) on missing constraint in redeclaration.

[luc.grosheintz at gmail dot com via Gcc-bugs]

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

Bug ID: 119998
   Summary: ICE (segfault) on missing constraint in redeclaration.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luc.grosheintz at gmail dot com
  Target Milestone: ---

Created attachment 61235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61235&action=edit
Preprocessed sources and compilation command.

The reproducer has also been setup on Godbolt:
https://godbolt.org/z/o8Y6rGWfq

The following invalid code causes a segfault in GCC trunk (e.g. commit
`1c0cbc1b300e08df5ebfce00a7195890d78f2064`):

```
struct A {
  template 
  struct B;
};

template 
requires true
struct A::B
{
  template
B(U u);
};

template
template
A::B::B(U u) {}
```
(the requires clause differs in the redeclaration.)

The error message is:
```
Segmentation fault
   16 | A::B::B(U u) {}
  |   ^
0x29720df internal_error(char const*, ...)
../../gcc-bug/gcc/diagnostic-global-context.cc:517
0x145866f crash_signal
../../gcc-bug/gcc/toplev.cc:321
0xbd4fed cp_printer
../../gcc-bug/gcc/cp/error.cc:4689
0x2995638 format_phase_2
../../gcc-bug/gcc/pretty-print.cc:2157
0x2995638 pretty_printer::format(text_info&)
../../gcc-bug/gcc/pretty-print.cc:1710
0x295c238 pp_format(pretty_printer*, text_info*)
../../gcc-bug/gcc/pretty-print.h:594
0x295c238 diagnostic_context::report_diagnostic(diagnostic_info*)
../../gcc-bug/gcc/diagnostic.cc:1504
0x295c665 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
../../gcc-bug/gcc/diagnostic.cc:1640
0x29718af error(char const*, ...)
../../gcc-bug/gcc/diagnostic-global-context.cc:397
0xd3c9cd push_template_decl(tree_node*, bool)
../../gcc-bug/gcc/cp/pt.cc:6250
0xb88aab start_preparsed_function(tree_node*, tree_node*, int)
../../gcc-bug/gcc/cp/decl.cc:18500
0xb9f946 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc-bug/gcc/cp/decl.cc:18837
0xccbfd7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-bug/gcc/cp/parser.cc:33569
0xccbfd7 cp_parser_init_declarator
../../gcc-bug/gcc/cp/parser.cc:24051
0xcd40e3 cp_parser_single_declaration
../../gcc-bug/gcc/cp/parser.cc:34112
0xcd433f cp_parser_template_declaration_after_parameters
../../gcc-bug/gcc/cp/parser.cc:33766
0xcd433f cp_parser_explicit_template_declaration
../../gcc-bug/gcc/cp/parser.cc:33940
0xcd4767 cp_parser_template_declaration_after_export
../../gcc-bug/gcc/cp/parser.cc:33959
0xcd4767 cp_parser_template_declaration_after_parameters
../../gcc-bug/gcc/cp/parser.cc:33754
0xcd4767 cp_parser_explicit_template_declaration
../../gcc-bug/gcc/cp/parser.cc:33940
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccLr1ffQ.out file, please attach this to
your bugreport.
```

The bug looks similar to PR118060 but the reproducer in that bug report doesn't
fail anymore on GCC trunk.

On Godbolt GCC 15.1 prints the following error message:
```
:16: confused by earlier errors, bailing out
```

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5

--- Comment #1 from Andrew Pinski  ---
I am not 100% sure this is valid code ...
In C++ requires you to have forward progress and this inifite loop is not
foward progress at all:

void f(int * p){ 
l:
assert (p == &a);
if (b)
goto l;
}

Which makes it undefined ...

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

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

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

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

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

commit r16-273-g3cf97980aaab6971ae179625a5e1188255dcf925
Author: Richard Biener 
Date:   Mon Apr 28 13:31:16 2025 +0200

debug/78685 - reword -Og documentation

The following rewords the documentation for -Og which over-promises
the ability to debug the generated code.  While -Og enables
var-tracking and thus improves debugging in some areas the experience
is usually worse than -O0 for standard C code.

PR debug/78685
* doc/invoke.texi (-Og): Reword.

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

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

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

--- Comment #31 from Jakub Jelinek  ---
That is nonsense.
-O0 -fvar-tracking doesn't work and would be substantial amount of work, far
more than artificially adding uses of all vars at the end of their scopes for
-Og.

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

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #33 from Konstantin Kharlamov  ---
@Richard Biener: thank you for the change! If I may point out though, the new
text still says:

> […]-Og should be the optimization level of choice for the standard
> edit-compile-debug cycle, offering a reasonable blend of optimization, fast
> compilation and debugging experience[…]

which is a problem, because it which is a problem, because it the actual
situation. I know not a single project who uses Og for debugging due to the
"optimized out" issue.

May I suggest to reword this as something like:

> -Og may sometimes be preferred to -O0 during the development when speed is
> important, but otherwise -O0 provides the best debugging experience.

WDYT?

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

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #34 from Konstantin Kharlamov  ---
> which is a problem, because it which is a problem, because it the actual 
> situation

whoops, sorry, not sure what happened to that part, it's supposed to be "which
is a problem, because it contradicts to the actual situation".

[Bug rtl-optimization/119982] [16 Regression] FAIL: gcc.target/i386/pr109362.c scan-assembler \tmovq\t8\\(%rdi\\), %r by r16-190-g6901d56fea2132

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> 
> and nothing in the RTL pipeline sees to "fix" this - forwprop or
> now late_combine comes to my mind (RTL combine doesn't work across
> BBs either).

That is because both are very conserative when it comes to volatile mem. See PR
60749 (and others).

[Bug c++/119983] Member function in unnamed type causes internal compiler error in module.

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Nathaniel Shead  ---
Thanks for the report!  As Andrew noted, the ICE is fixed for 14.3 by
r14-10825-g01d3a974fe3474c37cd52b595c29dddafad954dc.

The code is ill-formed, however:

  export module M;
  struct {} instance;

is not legal in a module interface, because of
https://eel.is/c++draft/basic.link#15.2 (the type of the unnamed struct is
TU-local), https://eel.is/c++draft/basic.link#14 (the declaration of the
variable exposes the TU-local type), and https://eel.is/c++draft/basic.link#17
(the variable is not TU-local, so this is ill-formed).

We don't check this in GCC 14 (so 14.3 will accept this code), but for GCC 15
we properly implement https://wg21.link/p1815 and so error in this case:

:2:11: error: 'instance' exposes TU-local entity 'struct'
2 | struct {} instance;
  |   ^~~~
:2:8: note: '' has no name and is not defined within a
class, function, or initializer
2 | struct {} instance;
  |^

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 119983 Summary: Member function in unnamed type causes internal compiler 
error in module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119983

   What|Removed |Added

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

[Bug c++/119983] Member function in unnamed type causes internal compiler error in module.

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

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

--- Comment #3 from Nathaniel Shead  ---
I will note that making the variable internal linkage will silence GCC 15,
since a TU-local variable itself is not an exposure; this is appropriate if you
only need the variable within that TU.  For example, adjusting your original
testcase, the following sample is valid:

export  module  M;
static struct
{
void aRandomFunc()
{

}
} variableWithNamelessType{};

export void foo() {
variableWithNamelessType.aRandomFunc();
}

[Bug rtl-optimization/119982] [16 Regression] FAIL: gcc.target/i386/pr109362.c scan-assembler \tmovq\t8\\(%rdi\\), %r by r16-190-g6901d56fea2132

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 29 Apr 2025, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119982
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>See Also||https://gcc.gnu.org/bugzill
>||a/show_bug.cgi?id=60749
> 
> --- Comment #3 from Andrew Pinski  ---
> (In reply to Richard Biener from comment #2)
> > 
> > and nothing in the RTL pipeline sees to "fix" this - forwprop or
> > now late_combine comes to my mind (RTL combine doesn't work across
> > BBs either).
> 
> That is because both are very conserative when it comes to volatile mem. See 
> PR
> 60749 (and others).

So that to me means we'd either WONTFIX the original bugreport and remove
the test or come to senses and allow optimizations to the addressing
mode of volatile mems.

At least GIMPLE (and TER, as can be seen) have no problems with
"optimizing" volatiles - and in this case the "volatile" isn't
even visible, it's a call argument on GIMPLE.

[Bug gcov-profile/118581] auto_profile can't annotate bb with all debug_stmt which assigned value with constant

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:59e853308bd797f91df15fd0fa65a3b5ce2cf4a2

commit r16-274-g59e853308bd797f91df15fd0fa65a3b5ce2cf4a2
Author: hongtao.liu 
Date:   Wed Jan 22 07:44:01 2025 +0100

Annotate empty bb with all debug_stmt with location of phi in the
single_succ.

For an empty BB with all debug_stmt, it will be ignored by
afdo_set_bb_count, but it can be set with count of single successors
PHIs which edge from the BB.

gcc/ChangeLog:

PR gcov-profile/118581
* auto-profile.cc (autofdo_source_profile::get_count_info):
Overload the function with parameter gimple location instead
of stmt.
(afdo_set_bb_count): For !has_annotated BB, Check single
successors PHIs corresponding to the block and use those
count.

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

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

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

--- Comment #35 from Lukas Grätz  ---
(In reply to Jakub Jelinek from comment #31)
> That is nonsense.
> -O0 -fvar-tracking doesn't work and would be substantial amount of work, far
> more than artificially adding uses of all vars at the end of their scopes
> for -Og.

I do not understand what you mean, -O0 -fvar-tracking works without a warning
indicating that something went wrong. That said, I am not entirely sure if you
really need that option for -O0. According to your GCC documentation, it might
be needed. If I remember correctly, DWARF should contain the debugging info
also for the prolog/epilog but the base frame is computation is more difficult
there.

I agree with Konstantin Kharlamov about the misleading documentation, I also
observed that -O0 often provides a better debugging experience.

[Bug gcov-profile/118581] auto_profile can't annotate bb with all debug_stmt which assigned value with constant

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #7 from Hongtao Liu  ---
Fixed in GCC16

[Bug c++/119996] [modules] Inline reference to a TU-local entity is nulled when used

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
 Ever confirmed|0   |1
 CC||nshead at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-04-29
   Keywords||accepts-invalid, wrong-code

--- Comment #1 from Nathaniel Shead  ---
Confirmed.  This applies to inline object references as well.

The root cause seems to be that because a reference is potentially-constant, we
avoid streaming its TU-local value, and never end up marking it as an exposure.
 I think we should be marking it an exposure at that point.

gcc-bugs@gcc.gnu.org

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

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

Bug ID: 119997
   Summary: [13/14/15/16 Regression] PRE no longer hoists
&ptr->field
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Since r13-137-gee1cb43bc76de8 PRE no longer hoists the invariant address
computations in gcc.target/i386/pr109362.c:

struct S { long a, b; };

int
foo (struct S *v)
{
  while (1)
{
  __atomic_load_n (&v->a, __ATOMIC_ACQUIRE);
  if (__atomic_load_n (&v->b, __ATOMIC_ACQUIRE))
return 1;
}
}


   [local count: 118111600]:

   [local count: 1073741824]:
  _1 = &v_6(D)->a;
  __atomic_load_8 (_1, 2);
  _2 = &v_6(D)->b;
  _3 = __atomic_load_8 (_2, 2);
  if (_3 != 0)
goto ; [11.00%]
  else
goto ; [89.00%]

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


since PRE in compute_avail() relies on vn_reference_lookup_pieces to lookup
the address but that a) did not get the special-handling of such addresses
so we can't find the inserted expression, b) it relies on the vn_reference
instead of just wanting a value, but we internally handle it as vn_nary.

gcc-bugs@gcc.gnu.org

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-04-29
   Keywords||missed-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |13.4
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

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

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

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

--- Comment #30 from Lukas Grätz  ---
(In reply to rguent...@suse.de from comment #29)
> On Mon, 28 Apr 2025, Hi-Angel at yandex dot ru wrote:
> > Hi, I understand it's a low-priority issue, but could we at least change the
> > documentation to say that `-Og` is "supposed to be useful for debugging, but
> > currently isn't"? I mean, it's a decades old problem, and likely won't be 
> > fixed
> > in the near future; however the recommendation being present in GCC docs is
> > harmful, because over and over in different projects someone brings up "why
> > aren't you using Og instead of O0", wasting I think thousands of man-hours
> > globally.
> > 
> > Having docs clarified here would be immensely useful, WDYT?
> 
> There is still the issue that -O0 does not do variable-tracking which
> means you get no debug info for the prologue/epilogue - -Og fixes that,
> at the expense of degraded debugging experience.
> 
> -Og is supposed to be a blend of optimization which result should be
> still debuggable (better than -O2).
> 
> I agree the documentation is misleading, while it may want to spell
> out the -fvar-tracking issue it fixes, it suggests the debugging
> experience is better than -O0 which it is not.
> 
> I'll note that -Og was also mainly motivated by C++ standard library
> debugging where you end up with quite deep inlining from abstraction
> penalty which _is_ a bad experience when debugging (and also for
> runtime performance).

I am not a GCC developer, but in my opinion, the solutions are not that
complicated nor is there a reason that this bug report remained open so many
years. There are multiple options to deal with it:

1. Deprecate -Og in favor to -O0 -fvar-tracking. -Og never worked as intended
anyway.

2. Change the semantics of -Og to mean -O0 -fvar-tracking. You could introduce
something like -Og1 to get the old -Og back.

3. Introduce a new option that is really optimized for the best debugging
experience. Again this would mean -O0 -fvar-tracking, but this would make it
easier if new options like -fvar-tracking were introduced in future gcc
versions.

For C++ the situation might be different, but for C, the run-time performance
is mostly irrelevant when debugging.

[Bug rtl-optimization/119982] [16 Regression] FAIL: gcc.target/i386/pr109362.c scan-assembler \tmovq\t8\\(%rdi\\), %r by r16-190-g6901d56fea2132

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=119997

--- Comment #2 from Richard Biener  ---
The change is that we now hoist

  _1 = &v_6(D)->a;
  _2 = &v_6(D)->b;

out of the loop in anticipation that PRE would have done the same which
it does not because of how we handle &v_6(D)->a in VN.  This restores
an optimization broken earlier (I filed PR119997) for this.  The testcase
was added just because of that "fix" without further analysis.

The simple analysis is that this is TER at play and the initial RTL
expansion without the hoisting is

7: r103:DI=[r102:DI]
8: [scratch]=unspec[[scratch]] 17
9: r100:DI=[r102:DI+0x8]
   10: [scratch]=unspec[[scratch]] 17

while otherwise we get (TER does not work across BBs)

6: r98:DI=r102:DI
7: {r99:DI=r102:DI+0x8;clobber flags:CC;}
   13: L13:
8: NOTE_INSN_BASIC_BLOCK 4
9: r103:DI=[r98:DI]
   10: [scratch]=unspec[[scratch]] 17
   11: r100:DI=[r99:DI]
   12: [scratch]=unspec[[scratch]] 17

and nothing in the RTL pipeline sees to "fix" this - forwprop or
now late_combine comes to my mind (RTL combine doesn't work across
BBs either).

So basically this bug is a duplicate of PR109362 itself, the effect of
PR119997 on the testcase has been fixed by r16-190-g6901d56fea2132,
so the latent issue is here again.

Adjusted testcase which was never "fixed":

struct S { long a, b; };

int
foo (struct S *v)
{
  long *x = &v->a;
  long *y = &v->b;
  while (1)
{
  __atomic_load_n (x, __ATOMIC_ACQUIRE);
  if (__atomic_load_n (y, __ATOMIC_ACQUIRE))
return 1;
}
}

[Bug target/119985] TARGET_PROMOTE_FUNCTION_RETURN is still referenced in target.def

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 16.

[Bug target/119985] TARGET_PROMOTE_FUNCTION_RETURN is still referenced in target.def

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

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

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

https://gcc.gnu.org/g:0f3a6b3972f6e6886297e59fcaf85f374859ca46

commit r16-275-g0f3a6b3972f6e6886297e59fcaf85f374859ca46
Author: H.J. Lu 
Date:   Tue Apr 29 09:44:29 2025 +0800

target.def: Remove TARGET_PROMOTE_FUNCTION_RETURN reference

Since TARGET_PROMOTE_FUNCTION_RETURN is no longer used, remove its
reference from target.def.

PR target/119985
* target.def: Remove TARGET_PROMOTE_FUNCTION_RETURN reference.
* doc/tm.texi: Regenerated.

Signed-off-by: H.J. Lu 

[Bug c++/119806] OpenACC, OpenMP 'target' offloading vs. C++ 'typeinfo' parts

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=119692
   Last reconfirmed||2025-04-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
I suspect this may get addressed via  "C++
'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading".

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #2 from mcccs at gmx dot com ---
Relevant discussion: https://github.com/llvm/llvm-project/issues/60622

[Bug c++/107020] [OpenMP][UBSAN] ICE during GIMPLE pass: sanopt via ubsan_expand_vptr_ifn: "output_operand: invalid expression as operand"

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||tschwinge at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
Tagging this PR107020 as a duplicate of PR112475, as the latter already has
details about what's happening.

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

[Bug middle-end/112475] [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in output_operand: invalid expression as operand

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

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

--- Comment #5 from Thomas Schwinge  ---
*** Bug 107020 has been marked as a duplicate of this bug. ***

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #3 from Jonathan Wakely  ---
Right, it's undefined to keep looping like that, so the compiler assumes that
the loop must terminate, which can only happen if the assert fails, so it
optimizes it to fail.

[Bug target/120000] New: Unoptimal structure copy loop

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 12
   Summary: Unoptimal structure copy loop
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
typedef unsigned long uword __attribute__ ((mode (word)));

struct a { uword arr[30]; };

__seg_gs struct a m;

void fromgs (struct a *dst) { *dst = m; }

void togs (struct a *src) { m = *src; }

__thread struct a n;

void fromthr (struct a *dst) { *dst = n; }

void tothr (struct a *src) { n = *src; }
--cut here--

Compiles on x86_64 target to (-Os):

fromgs:
movl$m, %esi
movl$60, %ecx
rep movsl   %gs:(%rsi), (%rdi)
ret

togs:
xorl%eax, %eax
.L3:
movl%eax, %edx<- here.
addl$8, %eax
movq(%rdi,%rdx), %rcx
movq%rcx, %gs:m(%rdx)
cmpl$240, %eax
jb  .L3
ret

Please note unoptimal usage of registers in the above loop, resulting in one
extra move. The loop could be compiled as:

xorl%eax, %eax
.L3:
movq(%rdi,%rax), %rcx
movq%rcx, %gs:m(%rax)
addl$8, %eax
cmpl$240, %eax
jb  .L3
ret

Somehow related issue is when copying from __thread address space

fromthr:
movq%fs:0, %rdx
movl$60, %ecx
leaqn@tpoff(%rdx), %rsi
rep movsl   (%rsi), (%rdi)
ret

Please note that "rep movsl" can use segment override with its source (as is
the case with fromgs function):

movln@tpoff(%rdx), %esi
movl$60, %ecx
rep movsl   %fs:(%rsi), (%rdi)
ret

resulting in much shorter asm:

   0:   8b b2 00 00 00 00   mov0x0(%rdx),%esi
2: R_X86_64_TPOFF32 n
   6:   b9 3c 00 00 00  mov$0x3c,%ecx
   b:   64 f3 a5rep movsl %fs:(%rsi),%es:(%rdi)
   e:   c3  ret

vs:

   0:   64 48 8b 14 25 00 00mov%fs:0x0,%rdx
   7:   00 00 
   9:   b9 3c 00 00 00  mov$0x3c,%ecx
   e:   48 8d b2 00 00 00 00lea0x0(%rdx),%rsi
11: R_X86_64_TPOFF32n
  15:   f3 a5   rep movsl %ds:(%rsi),%es:(%rdi)
  17:   c3  ret

tothr:
movq%fs:0, %rax
movq%rdi, %rsi
movl$60, %ecx
leaqn@tpoff(%rax), %rdi
rep movsl   (%rsi), (%rdi)
ret

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1

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

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

--- Comment #18 from Jason Merrill  ---
(In reply to Iain Sandoe from comment #17)
> > > In the meantime, perhaps it would be enough to revert the "fix" for 
> > > PR115908
> > > (and presumably mark that as INVALID?) - or do you have other thoughts?
> > 
> > I think that would be a good start, but the reversion seems to be
> > significantly complicated by other changes to that function.
> 
> yeah, it is not going to be a git revert - but more of a logical reversion. 
> Do you want me to try that or have you something already in mind?

Please.

> (it would be queued after doing the other 14.3 back ports)

Makes sense, though I imagine that backporting the build_ramp_function changes
from after 115908 will also be complicated by this issue.

[Bug rtl-optimization/120004] __builtin_unreachable/noreturn should not fall through to another function

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Another option which I am thinking about is just expanding
> __builtin_unreachable as the same as a trap. So at -O0, an explict
> __builtin_unreachable will turn into a trap. And the RTL optimizations don't
> take that much into account for unreachable either so having it as a trap
> seems ok.

The only issue with this is Why unreachable was added in the first place (PR
39252) but maybe it is ok to have one instruction (for most targets that
support Linux except sh[PR70216] ) after the inline-asm.

[Bug c/120010] __attribute__((unused)) does not work for function arguments

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Common-Type-Attributes.html#index-unused-type-attribute
"This is often the case with lock or thread classes, which are usually defined
and then not referenced, but contain constructors and destructors that have
nontrivial bookkeeping functions."

It should just mention only applies to non-parameters. Because for parameters
you can omit the name and it will work (in both GNU C [C23+] and C++).

[Bug c/120010] __attribute__((unused)) does not work for function arguments

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #2 from H. Peter Anvin  ---
Having to omit the name puts us right back into macro hell... having to
macroize every function definition.

It also violates the principle of least surprise, since __attribute__((used))
works if attached to the variable name in the definition, but not if it is
carried with the type; I believe the user has a reasonable expectation that the
two syntactical options would behave equivalently.

[Bug c/120010] __attribute__((unused)) does not work for function arguments

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #3 from H. Peter Anvin  ---
THat should of course have been __attribute__((unused)).

[Bug libgcc/120011] New: [15 Regression] Impossible asm constraints in 32 bit libgcc when compiling with -march=x86-64-v4

[stefan.kneifel at bluewin dot ch via Gcc-bugs]

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

Bug ID: 120011
   Summary: [15 Regression] Impossible asm constraints in 32 bit
libgcc when compiling with -march=x86-64-v4
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan.kneifel at bluewin dot ch
  Target Milestone: ---

Regression 15.1.1 against 15.0:

When compiling gcc itself using -march=x86-64-v4, it stops at compiling the 32
bit version of libgcc with the following error:

'asm' operand has impossible constraints or there are not enough registers

creduc'ing the regression gives the following code snippet:
--
long a, b, c, d;

void f()
{
long e[2];

if (e[0] | e[1])
{
__asm__("add %7,%3; adc %6,%2; adc %5,%1; adc %4,%0"
: "=r"(d), "=&r"(c), "=&r"(b), "=&r"(a)
: "0"(0L), "g"(e), "g"(e[1]), "g"(e[0]));
}
}
--

Compiling this with gcc 15.0 works with -march=x86-64-v4 -m32, gcc 15.1.1 does
not work and gives the mentioned error. 64 bit compiling works fine with both
versions.

[Bug c/120009] RFE: idea: void (dummy) objects (really...)

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

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

--- Comment #3 from Andrew Pinski  ---
>I will file a bug for __attribute__((unused)).


There is no bug on the unused case, you are marking the typedef decl as unused
not the type being unused. GNU C (and C23) also handles omitting the paramater
name and there is no warning there.

[Bug c/120009] RFE: idea: void (dummy) objects (really...)

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #2 from H. Peter Anvin  ---
Very interesting indeed... I just tried it as such:

struct empty_t { }  __attribute__((unused));
typedef struct empty_t empty_t __attribute__((unused));

int foo(empty_t a, int b, int c, empty_t d, int e, int f, int g, int h)
{
return b+c+e+f+g+h;
}

int bar(int b, int c, int e, int f, int g, int h)
{
empty_t a, d;
return foo(a,b,c,d,e,f,g,h);
}

int empty_size(void)
{
return sizeof(empty_t);
}

empty_t *empty_ptr(void)
{
static empty_t dummy;
return &dummy;
}

void set_empty(empty_t *ptr, empty_t x)
{
*ptr = x;
}

The only issues that I ran into are:

1. &dummy in the case above ends up pointing to a random location in .bss; it
probably would be better to be NULL.
2. __attribute__((unused)) doesn't work as advertised in this case
(__attribute__((unused)) on a type is supposed to quiet the unused warnings for
a "variable", but doesn't seem to do so in the case.

Otherwise it seems to work beautifully. I presume that the above would be minor
tweaks, and don't even prevent using on legacy compilers.

I will file a bug for __attribute__((unused)).

Beautiful!

[Bug rtl-optimization/120004] __builtin_unreachable/noreturn should not fall through to another function

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

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

--- Comment #3 from Andrew Pinski  ---
Another option which I am thinking about is just expanding
__builtin_unreachable as the same as a trap. So at -O0, an explict
__builtin_unreachable will turn into a trap. And the RTL optimizations don't
take that much into account for unreachable either so having it as a trap seems
ok.

[Bug c/120010] New: __attribute__((unused)) does not work for function arguments

[hpa at zytor dot com via Gcc-bugs]

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

Bug ID: 120010
   Summary: __attribute__((unused)) does not work for function
arguments
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

Created attachment 61242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61242&action=edit
Test case

__attribute__((unused)) on a type is there to mark that "a variable of that
type are meant to appear possibly unused."

However, it does not work as advertised if that type is used as a function
argument, which is one way that a variable can be created.

This can be a result of different code configuration, for example.

Attached test case when compiled with gcc 15.0.1 20250329 (Fedora 42):

gcc -O2 -Wall -Wextra -c unused.c
unused.c: In function ‘unused’:
unused.c:3:28: warning: unused parameter ‘b’ [-Wunused-parameter]
3 | int unused(int a, unused_t b, int c)
  |   ~^

Note the warning for the argument b, but not the local variable d.

[Bug c/120009] RFE: idea: void (dummy) objects (really...)

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #4 from H. Peter Anvin  ---
Well, I did both.
See also bug 120010; I don't believe this is at all consistent.

Having to omit the variable name defeats the whole purpose here.

[Bug target/120011] [15 Regression] Impossible asm constraints in 32 bit libgcc when compiling with -march=x86-64-v4

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-15&id=972a03737284b8611ec4e6315f6ca04d56ec05bf
is the only x86 change on the 15 branch. There are no other changes on the
branch which would have touched inline-asm on 86.

[Bug target/120011] [15 Regression] Impossible asm constraints in 32 bit libgcc when compiling with -march=x86-64-v4

[stefan.kneifel at bluewin dot ch via Gcc-bugs]

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

--- Comment #2 from Stefan Kneifel  ---
Created attachment 61243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61243&action=edit
creduced addtf3.c from libgcc

[Bug other/119855] Fixincludes needed for assert.h to support C++26's P2264R7

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

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

--- Comment #10 from Jonathan Wakely  ---
The C23 change and the C++26 change were proposed concurrently and were
originally part of the same proposal, and the glibc bug about scoped enums is
related to that same proposal.

However, glibc really needs two separate definitions of assert, as different
solutions are needed for C and C++, even if the goal is similar in each case.

[Bug rtl-optimization/120004] __builtin_unreachable/noreturn should not fall through to another function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-29
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I will be looking into this maybe in a few weeks.

[Bug fortran/119995] 521.wrf_r module_bl_mynn.fppized.f90:(.text+0x3398): undefined reference to `erf_'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Andrew Pinski  ---
.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
As explained both behaviors are valid.

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

[hpa at zytor dot com via Gcc-bugs]

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

H. Peter Anvin  changed:

   What|Removed |Added

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

--- Comment #22 from H. Peter Anvin  ---
I think this request is completed and takes care of this request, so *thank
you*, and I'm going to close this ticket as completed.

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta

[anhollander516 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Avraham Hollander  ---
Created attachment 61239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61239&action=edit
util-linux build log from portage. Contains all the compiler output.

[Bug c++/120005] TU-local exposure error in constexpr function

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

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

--- Comment #1 from Andrew Pinski  ---
>I'm additionally seeing errors in a module which internally uses some boost 
>containers. 

That one looks like a correct error. 
https://github.com/boostorg/container/commit/a4c4c3b3191ece1396e0a863e63634600b58a44a
looks like fixed boost. but I could be wrong.

[Bug c++/120005] TU-local exposure error in constexpr function

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

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

--- Comment #2 from Andrew Pinski  ---
I think even comment #0 is correct error message. constexpr causes the linkage
to be local. I think you need inline here to cause the linkage to be vague.

[Bug ipa/120006] New: [15 Regression] wrong code with -O2 -fipa-pta

[anhollander516 at gmail dot com via Gcc-bugs]

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

Bug ID: 120006
   Summary: [15 Regression] wrong code with -O2 -fipa-pta
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anhollander516 at gmail dot com
  Target Milestone: ---

Created attachment 61238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61238&action=edit
preprocessed file from -save-temps

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.1.0/work/gcc-15.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --disable-libunwind-exceptions
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 15.1.0 p55' --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 --with-multilib-list=m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --with-isl --disable-isl-version-check --disable-libsanitizer
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.1.0 (Gentoo 15.1.0 p55)

After rebuilding my two Gentoo systems with GCC 15, I am running into an issue
where util-linux 2.41 fsck isn't properly passing options along to the
filesystem-specific program it calls.

I am able to reproduce it simply by calling fsck -a on any FAT32 filesystem.

Using strace I was able to narrow it down to this:
13 execve("/usr/bin/fsck.vfat", ["fsck.vfat", "", "/dev/nvme0n1p1"],
0x7ffe3254b7d8 /* 77 vars */) = 0
-a is supposed to be passed through to fsck.vfat, but instead there is an empty
string, which fsck.vfat interprets as an invalid command line argument causing
it to fail.

I narrowed this down to a compiler issue by experimenting with the compiler
flags. The failure constently happens when -fipa-pta is used, and it works
again after removing it. I don't have the know-how to create a code snippet
that reproduces the issue, so I've provided as much as I can here, including
the preprocessed file.