[Bug target/118950] [14/15 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

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

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

Robin Dapp  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Robin Dapp  ---
Richi, is something like the following OK to get the original LHS?  I'm not
really convinced.

  stmt_vec_info pattern_stmt_info = STMT_VINFO_RELATED_STMT (stmt_info);
  if (!STMT_VINFO_IN_PATTERN_P (stmt_info)
  && pattern_stmt_info
  && gimple_get_lhs (pattern_stmt_info->stmt))
  scalar_type = TREE_TYPE (gimple_get_lhs (pattern_stmt_info->stmt));

I just wonder why this didn't surface with the first masked-load else operand
test.  That was also a masked gather with a bool type.

[Bug target/118957] [15 Regression] 5-9% slowdown of 511.povray_r and 453.povray

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

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

--- Comment #3 from Filip Kastl  ---
> this isn't a regression

Huh, I apparently got confused.  The graph shows that this *is* a regression. 
Thanks, richi, for fixing the bug title.

[Bug fortran/107635] [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays.

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:08bdc2ac98ae05ef694f4e55c296835fc01a3673

commit r15-7662-g08bdc2ac98ae05ef694f4e55c296835fc01a3673
Author: Andre Vehreschild 
Date:   Fri Feb 21 08:18:40 2025 +0100

Fortran: Fix build on solaris [PR107635]

libgfortran/ChangeLog:

PR fortran/107635
* caf/single.c: Replace alloca with __builtin_alloca.

[Bug middle-end/118965] New: [OpenMP] require at least one target/targetsync with append_args' interop and 'interop's init clause

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

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

Bug ID: 118965
   Summary: [OpenMP] require at least one target/targetsync with
append_args' interop and 'interop's init clause
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

GCC accepts:
  omp interop init(obj)  init(prefer_type("...") : obj2)
and
  omp declare variant(...) ... append_args(interop(prefer_type("...")))

namely: 'init(...)' and 'append_args(interop(...))' without TARGET or
TARGETSYNC.

EXPECTED:

* Reject this - by requiring at least one of target/targetsync
  (and no duplicates, but that's already checked for)

* This also implies that having modifiers to init are always required
  and not optional (with 'interop'; in 6.0, 'init' is also clause on
  'depend', but there the depinfo-modifier is required)

* * *

In principle, GCC implementation would be fine: It permits to obtain some data;
for instance, whether a certain type of foreign runtime is available at all.
Still, as it is not valid, we should reject it. Available data by flag:

OpenMP 6.0's "5.6 init Clause" has:

* For any interop-type, the properties type, type_name, vendor, vendor_name and
device_num will be available
* The targetsync interop-type will additionally provide the targetsync property
* The target interop-type will additionally provide the following properties …
device … device_context … platform

* * *

OpenMP 5.1 has
---
  init([interop-modifier, ]interop-type[[, interop-type] ... ]:interop-var)

interop-modifier = prefer_type
interop-type = target | targetsync
• Each interop-type may be specified on an action-clause at most once
---

OpenMP 5.2 has in "14.1.2 init Clause":
---
interop-preference | prefer_type| complex, unique
interop-type   | target, targetsync | repeatable, required

• Each interop-type may be specified at most once.
---

OpenMP 6.0 has:
---
interop-preference | prefer_type| complex, unique
interop-type   | target, targetsync | repeatable

• If the init clause appears on an interop construct, the interop-type modifier
has the required property and each interop-type keyword has the unique
property. Otherwise, the interop-type modifier must not be present.
---

[Bug target/118931] [15 Regression] RISC-V: rv64gcv miscompile at -O[23] since r15-3228-g771256bcb9d

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

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

--- Comment #3 from Li Pan  ---
It is a bug of interleaved_stepped when expand_const_vector, the base + i*step
for base1 series may overflow and then the base2 series will OR overflowed bits
to the final result.

I will prepare a fix for this.

[Bug tree-optimization/118521] [15 regression] std::vector Wstringop-overflow false positive since r15-4473

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

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

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

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

commit r15-7664-gd2720051c419a781a2f04daadcbefc99fa77b051
Author: Richard Biener 
Date:   Fri Feb 21 10:05:19 2025 +0100

Improve g++.dg/torture/pr118521.C

Alexander pointed out the way to do a dg-bogus in an included header.

PR tree-optimization/118521
* g++.dg/torture/pr118521.C: Use dg-bogus properly.

[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #17 from rguenther at suse dot de  ---
On Thu, 20 Feb 2025, sjames at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
> 
> --- Comment #13 from Sam James  ---
> I've only seen this on amd64 so far (2 machines) but I didn't try to reproduce
> it on arm64 or elsewhere.

I've seen it on x86_64 as well

[Bug fortran/48958] Add runtime diagnostics for SIZE intrinsic function

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7d383a7343af052798a52d575a0f0205c4a82c9c

commit r15-7663-g7d383a7343af052798a52d575a0f0205c4a82c9c
Author: Harald Anlauf 
Date:   Thu Feb 20 21:22:56 2025 +0100

Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]

PR fortran/48958

gcc/fortran/ChangeLog:

* trans-array.cc (gfc_trans_deferred_array): Initialize the data
component of non-saved pointers when -fcheck=pointer is set.

gcc/testsuite/ChangeLog:

* gfortran.dg/pointer_init_13.f90: New test.

[Bug target/116686] [15 Regression] RISC-V: gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2

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

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

Robin Dapp  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org

--- Comment #7 from Robin Dapp  ---
Hmm, I don't fully understand.  We're actually building with zvl256b right,
zvl1024b is first and thus gets overridden?  But with zvl256b and QEMU vlen=256
I'm not seeing a FAIL either.

Edwin, can you try reproducing this on the current trunk?

[Bug target/118957] [15 Regression] 5-9% slowdown of 511.povray_r and 453.povray since r15-7400-gd3ff498c478ace

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

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

Filip Kastl  changed:

   What|Removed |Added

Summary|[15 Regression] 5-9%|[15 Regression] 5-9%
   |slowdown of 511.povray_r|slowdown of 511.povray_r
   |and 453.povray  |and 453.povray since
   ||r15-7400-gd3ff498c478ace
 CC||hjl at gcc dot gnu.org

--- Comment #4 from Filip Kastl  ---
I checked on the Zen5 machine and indeed the commit r15-7400-gd3ff498c478ace
introduces a slowdown (~2.3%).  (The other machines are currently busy and I
don't want to disturb them.)

So I guess we can be pretty sure that the commit is the reason for these
slowdowns and can Cc H. J. Lu.

Btw I looked through our benchmarking for some povray speedups asociated with
this commit.  There are some:

5% speedup
2017 povray_r Zen4 -O2 -march=generic -flto and some hardening options[1]
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1103.467.0

??% speedup
2006 povray Zen4 -O2 -march=generic -flto and some hardening options[1]
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1100.160.0

2% speedup
2017 povray_r Zen4 -Ofast -march=native -flto PGO
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=958.467.0

The slowdowns are more numerous and bigger though.

---

[1] -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection

[Bug ada/118939] [14 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #3 from Nicolas Boulenguez  ---
The segmentation fault disappears if either -fstack-check or -O1 is removed.

(gdb) run
Starting program: /home/nicolas/runner 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf7f9a2f8 in system.pool_global.global_pool_object () from
/lib/arm-linux-gnueabi/libgnat-14.so
(gdb) bt
#0  0xf7f9a2f8 in system.pool_global.global_pool_object () from
/lib/arm-linux-gnueabi/libgnat-14.so
#1  0xf7eef2ac in system.storage_pools.subpools.allocate_any_controlled
(pool=..., context_subpool=, context_master=, 
fin_address=0xf7f9a2f8 ,
storage_size=1714523404, alignment=1852411464, is_controlled=164,
on_subpool=true)
at s-stposu.adb:326
#2  0xfffef5a4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Bug modula2/118978] ICE when attempting to pass a REAL actual parameter into an INTEGER formal parameter

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug middle-end/78917] missing -Wnonnull passing null to a nonnull function

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Fix was fixed back in the gcc-12 era.

[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull

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

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

Bug 78917 Summary: missing -Wnonnull passing null to a nonnull function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78917

   What|Removed |Added

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

[Bug middle-end/78998] missing -Wnonnull for an unconditional call to strlen with a null argument

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Fixed in the gcc-12 era.

[Bug modula2/118978] ICE when attempting to pass a REAL actual parameter into an INTEGER formal parameter

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 60557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60557&action=edit
Proposed fix which detects an incorrect parameter being passed

the ICE occurs when a range test is performed on incompatible types.  The fix
adds dependencies to the range tests to respective type tests.  If a parameter
type check fails then the subsequent range checks are cancelled.  In the ICE an
error message had been generated but the subsequent range checks were still
performed.

The result with the patch is shown below:

$ gm2 -c badparamtype.mod 
: error: formal parameter ‘INTEGER’
: error: actual parameter the RType
badparamtype.mod:9:9: error: 1st parameter failure due to assignment
incompatibility between actual parameter ‘3.14’ and the 1st formal ‘i’
parameter in procedure ‘foo’
9 |foo (3.14)
  | ^~~~

[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull

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

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

Bug 78998 Summary: missing -Wnonnull for an unconditional call to strlen with a 
null argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78998

   What|Removed |Added

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

[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
The warning is meant to catch cases where the compiler can prove there is a
NULL value that flows into either a pointer dereference or into a function
argument where that argument has been declared as never allowed to be NULL.

In this case we have no semantic information about GetWindowsDirectoryA; it's
totally opaque.  So the NULL poiner that gets passed in as PATH in the call to
GetSystemDirectory16 flows into the __builtin_strcpy and we get a warning per
design.

[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull

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

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

Bug 111669 Summary: bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669

   What|Removed |Added

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

[Bug tree-optimization/116851] vector assignment compilation fails claiming null STL argument

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

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

--- Comment #3 from Jeffrey A. Law  ---
Correct.  We aren't able to optimize away the path in question until full jump
threading which is way too late for the NULL warnings.

[Bug translation/118979] New: Wrong gettext extraction in c.opt

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 118979
   Summary: Wrong gettext extraction in c.opt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

c.opt says:
> Warn about deprecated space between "" and suffix in a user-defined literal 
> operator.

The resulting gcc.pot says:
> msgid ""
> "Warn about deprecated space between  and suffix in a user-defined literal "
> "operator."

The quotes in the middle should have been escaped as \"\" instead of being
omitted.

[Bug libstdc++/118980] std::system_error should not be default constructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |16.0

[Bug libstdc++/118980] std::system_error should not be default constructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/118980] New: std::system_error should not be default constructible

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

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

Bug ID: 118980
   Summary: std::system_error should not be default constructible
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We have a non-standard default argument on this constructor:

system_error(error_code __ec = error_code())

The system_error(error_code) constructor was added to the C++0x WP by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue24

That ctor was added to libstdc++ by r0-86777-g4514bed67d02fb but with a default
argument, but I don't know why. We don't have any tests that 

We should split the constructor into two, deprecate the default ctor for GCC
16, then remove it:

--- a/libstdc++-v3/include/std/system_error
+++ b/libstdc++-v3/include/std/system_error
@@ -561,7 +561,9 @@ namespace __adl_only
 error_code _M_code;

   public:
-system_error(error_code __ec = error_code())
+[[__deprecated__]] system_error() : system_error(error_code{}) { }
+
+system_error(error_code __ec)
 : runtime_error(__ec.message()), _M_code(__ec) { }

 system_error(error_code __ec, const string& __what)

We need to fix one test that currently uses the default constructor:

FAIL: 19_diagnostics/system_error/cons_virtual_derivation.cc  -std=gnu++17
(test for excess errors)

For now the fix will be to add a dg-warning for the -Wdeprecated-declaration
warning (or suppress it) but after we remove the default constructor we'll need
to find some way to construct a std::system_error in the
diamond_derivation_error class, which assumes that either it's default
constructible or can be constructed from a const char*.

N.B. https://cplusplus.github.io/LWG/issue3162 says the
system_error(error_code) ctor should be explicit, but it hasn't been approved.

[Bug driver/118975] -undef is passed to the linker

[John.Bollinger at StJude dot org via Gcc-bugs]

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

John.Bollinger at StJude dot org changed:

   What|Removed |Added

 CC||John.Bollinger at StJude dot 
org

--- Comment #6 from John.Bollinger at StJude dot org ---
This seems to be a pretty longstanding issue.  I can reproduce it at least as
far back as v8.5.0.

[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates

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

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

--- Comment #13 from Andrew Pinski  ---
Created attachment 60556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60556&action=edit
Patch which adds the simplified copy prop for agg

This fixes the testcase and has been bootstrapped and tested on x86_64 (other
targets might have some testcase failures due to SRA no longer needed to do the
copy prop). 

Just like the copy prop for zeroing, this only handles the previous memory
setting statement. 

I have an idea of how to improve this not just for the final copy. I had a
patch which handled call arguments but I want to make it more generic.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors but compiled with -mcpu=neoverse-v1 (which is only for 256bit v

[lrbison at amazon dot com via Gcc-bugs]

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

--- Comment #7 from Luke Robison  ---
Andrew,

Perhaps you mean that setting -mcpu=neoverse-v1 overrides
-msve-vector-bits=scalable argument.  So I tried with `-march=armv9-a+sve
-msve-vector-bits=scalable`.  I still observe the same erroneous output, so I
still think there is an error here.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors but compiled with -mcpu=neoverse-v1 (which is only for 256bit v

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
.

[Bug driver/118975] -undef is passed to the linker

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

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

--- Comment #3 from Andrew Pinski  ---
undef
Driver
; C option, but driver must not handle as "-u ndef".

[Bug ipa/118973] [15 regression] ICE when building glog-0.6.0 (single_succ_edge, at basic-block.h:332)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-02-21
 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
Confirmed. I don't see any off of the BB either.

Honza,
  Can you take a look?

[Bug sanitizer/118972] Missing ubsan complaint for double->int cast overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003dfloat-cast-overflow

With -fsanitize=float-cast-overflow, I get:

/app/example.cpp:4:35: runtime error: 1.79769e+308 is outside the range of
representable values of type 'int'
/app/example.cpp:5:35: runtime error: 1.79769e+308 is outside the range of
representable values of type 'int'
8000
8000

The option is documented not to be enabled with -fsanitize=undefined too.

[Bug sanitizer/118972] Missing ubsan complaint for double->int cast overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

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

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

[Bug driver/118975] -undef is passed to the linker

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

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

--- Comment #5 from Andrew Pinski  ---
Maybe %

[Bug target/118977] m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||m68k-rtems

--- Comment #1 from Andrew Pinski  ---
>And our test compiles and links fine on that.

That is because arm has defined __atomic_test_and_set in the libgcc.

So m68k will need to defined one and I suspect it will be specific to rtems
too.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
-mcpu=neoverse-v1 sets the number of SVE bits to 256.

tuning_models/neoversev1.h:  SVE_256, /* sve_width  */



So you can only run it on targets which have 256 bits.

If you want to override that you can use the `-msve-vector-bits=scalable`
option to say to use the scalable option.

But since you are specifying what cpu you are compiling for, it won't run on a
cpu which has a different bits set.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors but compiled with -mcpu=neoverse-v1 (which is only for 256bit v

[lrbison at amazon dot com via Gcc-bugs]

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

--- Comment #6 from Luke Robison  ---
Andrew,

Thanks for taking a look.  I actually had not realized that
-msve-vector-bits=scalable is the only option guaranteed to produce correct
execution on machines with other vector sizes.  I need to make sure I include
that in a few places, thank you.

However, you and the documentation suggest that -msve-vector-bits=scalable
should take precedence over the value in neoversev1.h, yet I'm still seeing the
problem:


gcc -Wall -Wextra -O3 -fno-strict-aliasing -mcpu=neoverse-v1
-msve-vector-bits=scalable final.c

gcc:9 gives PASS: got 0x00bb 0x00aa as expected
gcc:10 gives PASS: got 0x00bb 0x00aa as expected
gcc:11 gives PASS: got 0x00bb 0x00aa as expected
gcc:12.4 gives ERROR: expected 0x00bb 0x00aa but got 0x00bb
0xaa00
gcc:13.3 gives ERROR: expected 0x00bb 0x00aa but got 0x00bb
0xaa00
gcc:14.2 gives ERROR: expected 0x00bb 0x00aa but got 0x00bb
0xaa00

[Bug sanitizer/100591] -fsanitize=undefined fails to detect undefined floating to integer conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||blubban at gmail dot com

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

[Bug target/118977] m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h

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

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

--- Comment #2 from Joel Sherrill  ---
In reply to Andrew Pinski from comment #1)
> >And our test compiles and links fine on that.
> 
> That is because arm has defined  in the libgcc.

That symbol is not in the arm-rtems libgcc.a and I do not see this symbol in 

> So m68k will need to defined one and I suspect it will be specific to rtems
> too.

[Bug target/118977] m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h

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

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

--- Comment #3 from Joel Sherrill  ---
Sorry. Submitted accidentally while incomplete.

(In reply to Andrew Pinski from comment #1)
> >And our test compiles and links fine on that.
> 
> That is because arm has defined __atomic_test_and_set in the libgcc.

That symbol is not in the arm-rtems libgcc.a and I do not see this symbol in 
config/m68k/atomic-linux.c or anywhere else.

> 
> So m68k will need to defined one and I suspect it will be specific to rtems
> too.

I assumed that something would need to be implemented. I just don't see an
example that provides that symbol.

Advice appreciated.

[Bug target/116662] The value of __GCC_DESTRUCTIVE_SIZE for riscv64 could be improved

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

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

--- Comment #12 from Jason Merrill  ---
(In reply to Jeffrey A. Law from comment #11)
> I think Jason's position is that while it has ABI implications, that anyone
> using it in a way that exposes those ABI implications is using the feature
> in an unsafe way and that we shouldn't even try to present a stable &
> correct value as it inherently has to change based on underlying
> u-architectures.

That is indeed my position.  To reinforce that I added -Winterference-size (on
by default) to warn about any use in a header or module interface unit; see the
documentation for that warning.

[Bug modula2/118978] New: ICE when attempting to pass a REAL actual parameter into an INTEGER formal parameter

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

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

Bug ID: 118978
   Summary: ICE when attempting to pass a REAL actual parameter
into an INTEGER formal parameter
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As per mailing list, here is a reduced testcase:

MODULE badparamtype ;  

PROCEDURE foo (i: INTEGER) ;
BEGIN

END foo ;

BEGIN
   foo (3.14)
END badparamtype.

which cause ICE on gcc-15 (and gcc-14).

[Bug libstdc++/118981] New: tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

[Erich.Loew at outlook dot com via Gcc-bugs]

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

Bug ID: 118981
   Summary: tzdb.cc contains 3 times in sequence:
[[gnu::init_priority(99)]]
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Erich.Loew at outlook dot com
  Target Milestone: ---

LATEST GCC 15.0.1 quits at compiling the second occurrence
of "[[gnu::init_priority(99)]" with message:
{standard input}:131506: Error: symbol `_GLOBAL__sub_I.00099_tzdb.cc' is
already defined

---

Observation

The 3 GNU attribute [[gnu::init_priority(99)]] wordings have been added

as per
Parent: 0ca8d56f2085715f27ee536c6c344bc47af49cdd (libstdc++: Fix
std::chrono::tzdb to work with vanguard format)

by
Jonathan Wakely   2025-02-12 18:29:59

Commenting out these 3 GCC attributations leads to compiling without any
error.

---

I check further if multiple identic priorities in sequence are allowed in
C++20.
--> If YES --> code is fine and problem root is something else.

---

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-02-21
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
The code is correct.

What target are you compiling gcc for?

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

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

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

--- Comment #2 from Sam James  ---
On what platform? Please show us:
* the configure line used to build GCC
* the error in full, including the command before it that failed
* which commit / snapshot of GCC trunk
you're using.

The commit you're referring to is from April 2024, not 2025. It's also been
backported with zero complaints.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

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

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to Peter Dimov from comment #19)
> This should work.

In simple cases, yes. But if we have a mixed C++11 and C++14 (or later)
codebase, it's possible for the std::atomic to be initialized in a C++11 TU, so
padding is not cleared, and the CAS to be done in a C++14 TU, so it assumes
padding is cleared. And so we have the same problem.

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Sam James from comment #2)
> The commit you're referring to is from April 2024, not 2025. It's also been
> backported with zero complaints.

I think they just showed the wrong hash, note "Parent:"

The attributes were added recently in r15-7645-g99f57446e63b8e

I bet this is AIX. If needed, we can use priorities of 97, 98 and 99 to
workaround the assembler(?) bug.

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

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

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

--- Comment #4 from Sam James  ---
Ah, thanks. I both missed the 'Parent' but also missed the recent addition so
it didn't ring any alarm bells.

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

[Erich.Loew at outlook dot com via Gcc-bugs]

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

--- Comment #5 from Erich Löw  ---
I found in "7.7 C++-Specific Variable, Function, and Type Attributes" that
the lowest supported cardinal (indicating highest prio) should be 101.

I tried to replace all occurrences of 99 with 101 and LATEST compiler 15.0.1 is
as well compiling smoothly tzdb.cc.

So... passing 2 or more times 99 as prio is maybe the root cause of problem.

-

P.S.: the SPEC wording is

init_priority (priority)
In Standard C++, objects defined at namespace scope are guaranteed to be
initialized in an order in strict accordance with that of their definitions in
a given translation unit. No guarantee is made for initializations across
translation units. However, GNU C++ allows users to control the order of
initialization of objects defined at namespace scope with the init_priority
attribute by specifying a relative priority, a constant integral expression
currently bounded between 101 and 65535 inclusive. Lower numbers indicate a
higher priority.

-

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Erich Löw from comment #5)
> I found in "7.7 C++-Specific Variable, Function, and Type Attributes" that
> the lowest supported cardinal (indicating highest prio) should be 101.
> 
> I tried to replace all occurrences of 99 with 101 and LATEST compiler 15.0.1
> is as well compiling smoothly tzdb.cc.
> 
> So... passing 2 or more times 99 as prio is maybe the root cause of problem.
> 
> -
> 

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

has:
Note that priorities 0-100 are reserved. 

init_priority attribute should most likely link back to the constructor
function attribute for the description of the priority .

[Bug libstdc++/118981] tzdb.cc contains 3 times in sequence: [[gnu::init_priority(99)]]

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

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

--- Comment #7 from Andrew Pinski  ---
Can you provide the following:
the exact version of GCC;
the system type;
the options given when GCC was configured/built;
the complete command line that triggers the bug;
the compiler output (error messages, warnings, etc.); and

Which is documented at https://gcc.gnu.org/bugs/#need .

[Bug c++/118964] New: include in the module causes a compilation error

[printfne at gmail dot com via Gcc-bugs]

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

Bug ID: 118964
   Summary: include  in the module causes a
compilation error
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: printfne at gmail dot com
  Target Milestone: ---

Created attachment 60553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60553&action=edit
Source code and error information

When I tried to build my code on gcc14, I got an internal compiler error. I
built gcc15 for this purpose, and a new compilation error occurred. This code
can be compiled using clang19, so I'm not sure if my code or the code in the
opencv library doesn't follow the c++ standard or if gcc's support for modules
is inadequate. The error message is summarized as follows:
包含于文件 /usr/include/opencv2/core.hpp:57,
于 /usr/include/opencv2/opencv.hpp:52,
于 /home/yongheng/Projects/untitled/Image.ixx:7:
/usr/include/opencv2/core/types.hpp:279:9: 错误：‘template _Tp
cv::Point3_<_Tp>::dot(const cv::Point3_<_Tp>&) const’ exposes TU-local entity
‘template _Tp cv::saturate_cast(hfloat)’
  279 | _Tp dot(const Point3_& pt) const;
  | ^~~
包含于文件 /usr/include/opencv2/core/matx.hpp:54,
于 /usr/include/opencv2/core.hpp:56:
/usr/include/opencv2/core/saturate.hpp:161:42: 附注：‘template _Tp
cv::saturate_cast(hfloat)’ declared with internal linkage
  161 | template static inline _Tp saturate_cast(hfloat v) {
return saturate_cast<_Tp>((float)v); }
  |  ^
包含于文件 /usr/include/opencv2/core.hpp:58:
/usr/include/opencv2/core/mat.hpp:343:28: 错误：‘template
cv::_OutputArray::_OutputArray(const std::vector >&)’ exposes
TU-local entity ‘template cv::MatExpr
cv::operator+(const Matx<_Tp, m, n>&, const Mat&)’
  343 | template _OutputArray(const
std::vector >& vec);
  |^~~~
/usr/include/opencv2/core/mat.hpp:3656:9: 附注：‘template
cv::MatExpr cv::operator+(const Matx<_Tp, m, n>&, const Mat&)’ declared with
internal linkage
 3656 | MatExpr operator + (const Matx<_Tp, m, n>& a, const Mat& b) { return
Mat(a) + b; }
  | ^~~~
/usr/include/opencv2/core/mat.hpp:2343:12: 错误：‘template size_t
cv::Mat_<_Tp>::elemSize1() const’ exposes TU-local entity ‘template cv::MatExpr cv::operator/(const Matx<_Tp, m, n>&, const Mat&)’
 2343 | size_t elemSize1() const;
  |^
/usr/include/opencv2/core/mat.hpp:3698:9: 附注：‘template
cv::MatExpr cv::operator/(const Matx<_Tp, m, n>&, const Mat&)’ declared with
internal linkage
 3698 | MatExpr operator / (const Matx<_Tp, m, n>& a, const Mat& b) { return
Mat(a) / b; }
  | ^~~~
/usr/include/opencv2/core/mat.hpp:2347:12: 错误：‘template size_t
cv::Mat_<_Tp>::step1(int) const’ exposes TU-local entity ‘template cv::MatExpr cv::operator/(const Matx<_Tp, m, n>&, const Mat&)’
 2347 | size_t step1(int i=0) const;
  |^
/usr/include/opencv2/core/mat.hpp:3698:9: 附注：‘template
cv::MatExpr cv::operator/(const Matx<_Tp, m, n>&, const Mat&)’ declared with
internal linkage
 3698 | MatExpr operator / (const Matx<_Tp, m, n>& a, const Mat& b) { return
Mat(a) / b; }


Reproduction step:
mkdir build && cd build  
cmake .. -G Ninja  
cmake --build .  

gcc version: gcc 15.0.1
cmake version  : cmake 3.31.5-1
ninja version  : ninja 1.12.1-2
opencv version : opencv 4.11.0-3

[Bug c++/118964] include in the module causes a compilation error

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-02-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Keywords||needs-source

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source and NOT just a cmake file but all of
the commands neded to generate the error?

[Bug c++/118964] include in the module causes a compilation error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Though this might be a dup of bug 118799.

[Bug rtl-optimization/118956] [15 regression] gcc.target/aarch64/sve/pred-not-gen-[14].c fail after r15-268-g9dbff9c05520a74e

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/118974] New: Use SVE cbranch sequence for Neon modes when TARGET_SVE

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

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

Bug ID: 118974
   Summary: Use SVE cbranch sequence for Neon modes when
TARGET_SVE
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

For example, the testcase from the testsuite:

#define N 640
int a[N] = {0};
int b[N] = {0};

void f1 ()
{
  for (int i = 0; i < N; i++)
{
  b[i] += a[i];
  if (a[i] > 0)
break;
}
}

When compiled with, say, -mcpu=neoverse-v2 will choose to vectorise with Neon
modes and emit:
cmgtv31.4s, v30.4s, #0
umaxp   v31.4s, v31.4s, v31.4s
fmovx3, d31
cbz x3, .L2

for the early break check. But since this target supports SVE it could be using
the SVE sequence:
cmpgt   p14.s, p7/z, z28.s, #0
ptest   p15, p14.b
b.none  .L3

which is a bit shorter and, if I read the Neoverse V2 optimisation guide
correctly, should take one less cycle.
In this particular case the compiler would know that the operand to the compare
came from a Neon load so the >128 bits are zero for VLA code. But if it can't
prove that generally it could still make this codegen decision with
-msve-vector-bits=128

[Bug target/106531] -march=rv32iabmc should also enable zba, zbb, zbs

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
This has been fixed on the trunk.

[Bug target/118955] Fortran uses vector math functions without -ffast-math

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org

--- Comment #10 from avieira at gcc dot gnu.org ---
FWIW people currently blocked by this can disable simdclones using
-fdisable-ipa-simdclone.

Wilco's approach is partly glibc side and partly gcc side and has the benefit
of blocking the vectorization in older GCC's if we manage to backport the
change to glibc to all versions that introduced these vector routines, which I
think are less than GCC versions that use the fortran preinclude?

Having said that, there's always the question of how likely gcc versions that
are out of support and no longer active are going to be paired with a glibc
version that uses these vector routines...

No strong feelings here, but just wanted to point that out, even if maybe
obvious.

[Bug target/118974] Use SVE cbranch sequence for Neon modes when TARGET_SVE

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #1 from Tamar Christina  ---
Confirmed, I had submitted a patch for this a few years ago but it never got a
review/help I requested
https://patchwork.sourceware.org/project/gcc/patch/zjw6svuwbaxlp...@arm.com/

I was stuck on being able to do this in RTL because the problem is that the
sequence in gimple is

b = a > 0
if (c != 0)
  break

and so the cbranch expansion doesn't always see the actual comparison being
done.
And if you try to match them up in RTL it becomes very complicated as the patch
above showed.

I've been thinking about it again, but this time I'd instead change it so that
expand gives the comparison as the operation to cbranch. This removes the
complication of trying to match an SVE and Adv. SIMD compare into one.

But this can only be done if the target supports more than 0 as the second
operand.

because e.g. MVE can do c != 0, but not b1 > b2, where they're both predicates.

Also:

cmpgt   p14.s, p7/z, z28.s, #0
ptest   p15, p14.b
b.none  .L3

should be:

cmpgt   p14.s, p7/z, z28.s, #0
b.none  .L3

we don't need the ptest since we only use b.none or b.any and the size of the
predicate of the ptest is smaller than the original.

This however is a general problem with SVE codegen in GCC and not cbranch
related. The CC elimination pass needs to be expanded here, I think Richard was
playing with extending it to do this.

[Bug ipa/118973] New: [15 regression] ICE when building glog-0.6.0 (single_succ_edge, at basic-block.h:332)

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

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

Bug ID: 118973
   Summary: [15 regression] ICE when building glog-0.6.0
(single_succ_edge, at basic-block.h:332)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 60554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60554&action=edit
logging_unittest.cc.ii.xz

```
$ g++ -O2 -c ./CMakeFiles/logging_unittest.dir/src/logging_unittest.cc.ii
during GIMPLE pass: local-fnsummary
/var/tmp/portage/dev-cpp/glog-0.6.0/work/glog-0.6.0/src/logging_unittest.cc: In
member function ‘virtual void DeathNoAllocNewHook_logging_Test::TestBody()’:
/var/tmp/portage/dev-cpp/glog-0.6.0/work/glog-0.6.0/src/logging_unittest.cc:1484:1:
internal compiler error: in single_succ_edge, at basic-block.h:332
 1484 | }
  | ^
0x5e81b6a8e901 internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x5e81b6a8ea9c fancy_abort(char const*, int, char const*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic.cc:1722
0x5e81b52a4822 single_succ_edge(basic_block_def const*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/basic-block.h:332
0x5e81b6eec986 builtin_unreachable_bb_p
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:2711
0x5e81b6eec986 guards_builtin_unreachable
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:2733
0x5e81b6eec986 find_necessary_statements
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:2808
0x5e81b6ecdf88 analyze_function_body
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:2934
0x5e81b6ebd262 compute_fn_summary(cgraph_node*, bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:3476
0x5e81b6ee3ce9 compute_fn_summary_for_current
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:3506
0x5e81b6ee3ce9 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-fnsummary.cc:5161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

---

```
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.0./work/gcc-15.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-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 15.0. p, commit
2f960908caaad18d54ce7cb764ac470656e664c4' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250220 (experimental)
d7ff3142821bd114ba925cb5a3778d973fe5335e (Gentoo Hardened 15.0. p, commit
2f960908caaad18d54ce7cb764ac470656e664c4)
```

[Bug sanitizer/118972] New: Missing ubsan complaint for double->int cast overflow

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 118972
   Summary: Missing ubsan complaint for double->int cast overflow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

int main()
{
double max = __DBL_MAX__;
__builtin_printf("%x\n", (int)(double)max);
__builtin_printf("%x\n", (int)(double)__DBL_MAX__);
}

-O0 -fsanitize=undefined -Wall -Wextra


Expected: Two UBSan complaints or compiler warnings. Or, if GCC defines some
particular semantics for overflowing double->int casts, at least return the
same number for both.

Actual:

8000
7fff

Clang's UBSan complains about both, as expected (then returns different
numbers, but that's fine, it's UB). https://godbolt.org/z/8rK7co19s

[Bug ipa/118973] [15 regression] ICE when building glog-0.6.0 (single_succ_edge, at basic-block.h:332)

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code

[Bug c++/118968] GCC compiles illegal label in constexpr

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to qurong from comment #0)
> The compiler gcc10.1 accepts this program.

We aren't interested in bugs in GCC 10.1, it stopped being supported five years
ago when GCC 10.2 was released, and all 10.x versions stopped being supported
in 2023 when GCC 10.5 was released.

[Bug c++/118971] New: GCC incorrectly accepts a C++ program with a malformed lambda expression in the capture list

[qurong at ios dot ac.cn via Gcc-bugs]

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

Bug ID: 118971
   Summary: GCC incorrectly accepts a C++ program with a malformed
lambda expression in the capture list
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qurong at ios dot ac.cn
  Target Milestone: ---

The compiler gcc accepts this program and clang will reject it.

void f(void) {
constexpr int b = 4096;
int a= [=, a] {
return b;
}();
}

int main() {
f();
return 0;
}

[Bug c/118970] Const local array not considered to be const unless `static` is added

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/59863] const array in function is placed on stack

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||agriff at tin dot it

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

[Bug c/118970] New: Const local array not considered to be const unless `static` is added

[agriff at tin dot it via Gcc-bugs]

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

Bug ID: 118970
   Summary: Const local array not considered to be const unless
`static` is added
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: agriff at tin dot it
  Target Milestone: ---

in the following code example

```
int foo(int x) {
static int tt[] = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
};
return tt[x & 15];
}
```

the code generated is ok (the array ends up being statically initialized and
just looked up in the function); so the optimizer sees that no one can legally
access and change its content.

In the other hand if `static` is removed this doesn't happen (the data is
copied and the copy is looked up).

Adding `const` or (even `constexpr` in C++) doesn't help.

This happens at -O1 -O2 -O3 and -Os (exactly how is copied changes, but still
looks like a copy is made and then the copy is looked up immediately).

[Bug c++/118971] GCC incorrectly accepts a C++ program with a malformed lambda expression in the capture list

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
GCC gives a diagnostic, which is all the standard requires.

If you use -pedantic-errors then it's rejected with an error.

Please don't keep reporting bugs like this and PR 118969, the standard only
requires a diagnostic, and GCC gives a diagnostic.

[Bug c++/118971] GCC incorrectly accepts a C++ program with a malformed lambda expression in the capture list

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

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

--- Comment #2 from Jonathan Wakely  ---
Also, it's not helpful to say "the compiler gcc accepts this program" and not
mention that actually it gives a warning.

[Bug middle-end/59863] const array in function is placed on stack

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
I have an idea on how to fix this for the case when there is enough values that
GCC's gimplifier creates a const static variable to copy from. Which happens in
almost reported duplicates except it does NOT for testcase in comment #0.

[Bug middle-end/59863] const array in function is placed on stack

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

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

--- Comment #14 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #13)
> I have an idea on how to fix this for the case when there is enough values
> that GCC's gimplifier creates a const static variable to copy from. Which
> happens in almost reported duplicates except it does NOT for testcase in
> comment #0.

Well it does for the arm target.

[Bug target/118967] 5% slowdown of 473.astar on AMD Zen3 since r15-7400-gd3ff498c478ace

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

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

Filip Kastl  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/118967] New: 5% slowdown of 473.astar on AMD Zen3 since r15-7400-gd3ff498c478ace

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

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

Bug ID: 118967
   Summary: 5% slowdown of 473.astar on AMD Zen3 since
r15-7400-gd3ff498c478ace
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=464.260.0

there was a 5% exec time slowdown of the 473.astar SPEC 2006 benchmark caused
by commit r15-7400-gd3ff498c478ace

when run with -O2 -march=native on an AMD Zen3 machine.

Cc-ing H. J. Lu and Honza.

I have looked at more astar results.  There are some configurations where astar
speeds up a bit.  Here is one example, but it is quite noisy:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=292.260.0

However, the slowdowns are more numerous and bigger.

---

This is *not* a regression against GCC14. See the comparison
here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1037.260.0&plot.9=464.260.0&;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/118954] [15 regression] Miscompile at -O3 since r15-1757-g4d24159a1fcb15

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

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

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

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

commit r15-7665-gee30e2586a3142e63daaf301a561984f1d22d38d
Author: Richard Biener 
Date:   Fri Feb 21 09:58:04 2025 +0100

tree-optimization/118954 - avoid UB on ref created by predcom

When predicitive commoning moves an invariant ref it makes sure to
not build a MEM_REF with a base that is negatively offsetted from
an object.  But in trying to preserve some transforms it does not
consider association of a constant offset with the address computation
in DR_BASE_ADDRESS leading to exactly this problem again.  This is
arguably a problem in data-ref analysis producing such an out-of-bound
DR_BASE_ADDRESS, but this looks quite involved to fix, so the
following avoids the association in one more case.  This fixes the
testcase while preserving the desired transform in
gcc.dg/tree-ssa/predcom-1.c.

PR tree-optimization/118954
* tree-predcom.cc (ref_at_iteration): Make sure to not
associate the constant offset with DR_BASE_ADDRESS when
that is an offsetted pointer.

* gcc.dg/torture/pr118954.c: New testcase.

[Bug tree-optimization/118954] [15 regression] Miscompile at -O3 since r15-1757-g4d24159a1fcb15

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Fixed on trunk.

[Bug target/118967] 5% slowdown of 473.astar on AMD Zen3 since r15-7400-gd3ff498c478ace

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|15.0|---

[Bug driver/118975] -undef is passed to the linker

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #1 from Nate Eldredge  ---
I should have said, credit to StackOverflow user anol for finding this.

https://stackoverflow.com/questions/79457581/gcc-undef-leads-to-cannot-find-entry-symbol-start-defaulting-to-x/79457825#79457825

[Bug tree-optimization/118976] New: Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

[lrbison at amazon dot com via Gcc-bugs]

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

Bug ID: 118976
   Summary: Correctness Issue: SVE vectorization results in data
corruption when cpu has 128bit vectors
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lrbison at amazon dot com
  Target Milestone: ---

Created attachment 60555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60555&action=edit
Standalone Reproducer

Hello Team,

A customer came to me with a sha1 implementation that was producing corrupt
values on Graviton4 with -O3.

I isolated the problem to the generation of the trailing bytecount in
big-endian which is then included in the checksum.  The original code snippet
is here, and several variants of it can be found online with some googling

for (i = 0; i < 8; i++) {
finalcount[i] = (unsigned char)((context->count[(i >= 4 ? 0 : 1)]
 >> ((3-(i & 3)) * 8) ) & 255);  /* Endian independent */
}


I've attached a stand-alone reproducer in which the problematic function is
called finalcount_av.  I have found that gcc 11 and previous don't vectorize
and don't have the issue, while gcc 12.4 through gcc 14.2 produce corrupt
results.  Although trunk doesn't exhibit the problem, I believe this is because
of changed optimization weights rather than because the error was fixed.

It is also worth noting that the corruption only occurs in hardware with
128-bit SVE vectors.  On Graviton3 with 256-bit vectors the generated machine
code can exit early and not execute the problematic second half.

Here is a link to Compiler Explorer with the same function
https://godbolt.org/z/c99bMjene

Note that the value of NCOUNT can be set to either 2 or 4, with 4 preventing
the compiler from simply using the `rev` instruction on trunk.  Notably though
setting NCOUNT to 4 generates correct code in all versions I tested.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

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

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

--- Comment #1 from Sam James  ---
Does -fno-strict-aliasing work (the uint32_t* cast)?

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

[lrbison at amazon dot com via Gcc-bugs]

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

--- Comment #2 from Luke Robison  ---
In particular I believe the error occurs because of the following sequence of
instructions.  Looking at line numbers form the compiler explorer output of
14.2

In the first block line 8:

index   z31.s, #-1, #-1

This generates a vector of {-1, -2, -3, -4, -5, -6, -7 -8} on 256-bit vector
machines, and only {-1, -2, -3, -4} on 128-bits.

Then for 128-bit machines, the vector is generated again for the second half on
line 20, and then manipulated into negative values {-4, -5, -6, -7}

index   z29.s, w3, #-1

But clearly the values should be {-5, -6, -7 -8}, and hence the resulting data
is shifted by one.

[Bug middle-end/117263] [12/13/14 Regression] genautomata.cc does not compile with -DNDEBUG due to unused but set variable

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
We're not going to backport this.  It doesn't fix any kind of functional issue.

[Bug driver/118975] -undef is passed to the linker

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

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

--- Comment #2 from Sam James  ---
A workaround is probably -Wp,-undef but not tried it.

[Bug target/86802] riscv port needs updating for CVE-2017-5753

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Not actively working on this.  I also suspect it'll have to be addressed on a
per-uarch basis as I suspect at least some uarchs will have design mititagions
for these problems.

[Bug driver/118975] New: -undef is passed to the linker

[nate at thatsmathematics dot com via Gcc-bugs]

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

Bug ID: 118975
   Summary: -undef is passed to the linker
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nate at thatsmathematics dot com
  Target Milestone: ---

When the `-undef` option is given to gcc for a command that involves linking,
the option is passed to the linker as well as the compiler.  This makes no
sense as `-undef` should only affect preprocessing, and it causes the linker to
misbehave.

When running `gcc -undef -v m.c` for a file `m.c` containing only `int
main(void) { }` in my test, the linker command line is:

/usr/libexec/gcc/aarch64-unknown-linux-gnu/14/collect2 [...] -undef .../Scrt1.o
[...] 

GNU ld parses this as equivalent to `--undefined=.../Scrt1.o`, so the path
`.../Scrt1.o` is treated as a symbol to be undefined, rather than as a file to
be linked.  I get a message about the `_start` entry point being undefined, and
the resulting executable doesn't work.

Tested locally with Gentoo's ebuild of 14.2.1_p20241221 p7 on arm64, but also
reproducible with all recent versions on godbolt, e.g.
https://godbolt.org/z/3s6qGex8o

[Bug target/114516] RISC-V: TSVC2 s315 has spill with dynamic lmul

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

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

--- Comment #1 from Robin Dapp  ---
The issue is that we're not considering pattern statements for costing.  It's
rather straightforward to include those as well which would fix this PR.
I'm going to test a patch locally.

[Bug debug/118837] Interpretation of DW_FORM_data*

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

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

--- Comment #4 from Tom Tromey  ---
(In reply to Jakub Jelinek from comment #3)

> And perhaps we could also try to optimize the DW_FORM_sdata cases if there
> is no ambiguity (e.g. for 8-bit signed contexts with negative value
> DW_FORM_data1 could be unambiguous).

Ok.  I think we're in agreement about the interpretation then?
To sum up:

* If the context is clearly signed, then DW_FORM_data* should
  sign-extend.
* If the context is clearly unsigned, then DW_FORM_data* should
  not sign-extend.
* If the context is ambiguous, then DW_FORM_[su]data should be used.

Perhaps ambiguous contexts should be clarified in the DWARF standard,
but that's a separate issue.

FWIW I think this is also the LLVM interpretation.  There are
definitely places in the DWARF emitter that choose DW_FORM_sdata
rather than some default.

If you both agree with the above I think we can just close this
bug and I'll fix gdb.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Correctness Issue: SVE  |[12/13/14/15 regression]
   |vectorization results in|Correctness Issue: SVE
   |data corruption when cpu|vectorization results in
   |has 128bit vectors  |data corruption when cpu
   ||has 128bit vectors
  Component|tree-optimization   |target
   Target Milestone|--- |12.5

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

[lrbison at amazon dot com via Gcc-bugs]

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

--- Comment #3 from Luke Robison  ---
Sam,

No, -fno-strict-aliasing still produces incorrect results.

[Bug target/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors

[lrbison at amazon dot com via Gcc-bugs]

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

--- Comment #4 from Luke Robison  ---
Apologies I forgot to include compile line and output:

gcc -fno-inline -O3 -Wall -fno-strict-aliasing  -mcpu=neoverse-v1 -o final
final.c

gcc:9 gives PASS: got 0x00bb 0x00aa as expected
gcc:10 gives PASS: got 0x00bb 0x00aa as expected
gcc:11 gives PASS: got 0x00bb 0x00aa as expected
gcc:12.4 gives ERROR: expected 0x00bb 0x00aa but got 0x00bb
0xaa00
gcc:13.3 gives ERROR: expected 0x00bb 0x00aa but got 0x00bb
0xaa00
gcc:14.2 gives ERROR: expected 0x00bb 0x00aa but got 0x00bb
0xaa00

[Bug rtl-optimization/101188] [12/13 Regression] [postreload] Uses content of a clobbered register

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

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

Sam James  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/100570] g++ does not suppress bitfield conversion warning even isystem flag is set

[fsmoke at mail dot ru via Gcc-bugs]

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

--- Comment #6 from fsmoke  ---
I just now tested my sample on gcc 13.3 it seems bug already fixed somehow

>>That's not a system include directory, because you didn't use -isystem

And no... it's not nesessery, because isystem works for all subdirectories

[Bug ipa/118973] [15 regression] ICE when building glog-0.6.0 (single_succ_edge, at basic-block.h:332)

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

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

--- Comment #1 from Sam James  ---
```
int _setjmp();
void a() {
  int b;
  if (_setjmp())
new int;
  &b;
}
```

[Bug ipa/118973] [15 regression] ICE when building glog-0.6.0 (single_succ_edge, at basic-block.h:332)

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

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

--- Comment #2 from Sam James  ---
```
int foo() __attribute__((returns_twice));

void a() {
  int a;
  if(foo()) new int;
  &a;
}
```

[Bug target/118977] New: m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h

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

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

Bug ID: 118977
   Summary: m68k mcf5282 undefined symbol __atomic_test_and_set
from atomic_base.h
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Target m68k-rtems but likely repeatable on m68k-elf

GCC version: 
m68k-rtems7-gcc (GCC) 14.2.0 20240801 (RTEMS 7, RSB
d5d9d1a4470134ea9292514c43d6a57402564578-modified, Newlib 1b3dcfd)

This is the error from compiling and linking an RTEMS C++ test that targets
"-mcpu=5282". Looking at a manual for that, it appears to be "ISA A" which
doesn't include a test and set instruction. :

/home/joel/rtems-work/tools/7/lib/gcc/m68k-rtems7/14.2.0/include/c++/bits/atomic_base.h:226:(.text.Init+0x19a):
undefined reference to `__atomic_test_and_set'
collect2: error: ld returned 1 exit status

Looking at the file ./libstdc++-v3/include/bits/atomic_base.h, I see a couple
of calls to that method. 

The test is located at
https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/testsuites/sptests/spcxx01/init.cc?ref_type=heads.
 

We do have libatomic.a installed and a grep shows it has variants of
__atomic_test_and_set.

$ m68k-rtems7-nm -g
/home/joel/rtems-work/tools/7/lib/gcc/m68k-rtems7/14.2.0/m5208/libatomic.a |
grep atomic_test_and_
 U __atomic_test_and_set
 T __atomic_test_and_set_1
 T __atomic_test_and_set_2
 T __atomic_test_and_set_4
 T __atomic_test_and_set_8

This set of symbols matches what is in an arm-rtems version of the library. And
our test compiles and links fine on that.

[Bug rtl-optimization/101188] [12/13 Regression] [postreload] Uses content of a clobbered register

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

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

--- Comment #22 from Sam James  ---
I suggest regtesting it on the branches, submitting it, and asking Jeff for
approval. I can't speak for Jeff but I would take the unassignment as "I'm not
going to work on the backport-and-testing" rather than "I refuse to backport".

[Bug rtl-optimization/101188] [12/13 Regression] [postreload] Uses content of a clobbered register

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

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

--- Comment #21 from Georg-Johann Lay  ---
Back then, the patch has been reopened so it won't be forgotten for
backporting.

https://gcc.gnu.org/pipermail/gcc/2024-February/243300.html

As is seems, no backport will happen?

[Bug target/114991] [14/15 Regression] AArch64: LDP pass does not handle some structure copies

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
This is also related to PR 28831.

[Bug driver/118975] -undef is passed to the linker

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) " \
LINK_PLUGIN_SPEC \
   "%{flto|flto=*:%

[Bug tree-optimization/118954] [15 regression] Miscompile at -O3 since r15-1757-g4d24159a1fcb15

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #12 from Richard Biener  ---
  /* We may not associate the constant offset across the pointer plus
 expression because that might form a pointer to before the object
 then.  But for some cases we can retain that to allow tree_could_trap_p
 to return false - see gcc.dg/tree-ssa/predcom-1.c  */
  tree addr, alias_ptr;
  if (integer_zerop  (off))
{
  alias_ptr = fold_convert (reference_alias_ptr_type (ref), coff);
  addr = DR_BASE_ADDRESS (dr);

so we anticipate the problem but wrongly assume any problematic offset
is in DR_OFFSET.  But it can also be in DR_BASE_ADDRESS:

(int *) &g + (sizetype) _23 * 18446744073709551612

you can probably argue that data-ref analysis decomposed the ref in an
invalid way given DR_BASE_ADDRESS is &g[-1] here.

It's split_constant_offset that decomposes

(int *) &g + (long unsigned int) (int) ((unsigned int) _2 + 4294967295) * 4

as

(int *) &g + (sizetype) _23 * 18446744073709551612

and the constant offset 8 and we are not re-evaluating what we consider
the "offset" (that's only computed from get_inner_reference of the original
MEM, not what simple_iv or split_constant_offset makes of it).

It's a bit late in the cycle to try fixing that and I also don't have a good
idea here (CCed Richard as split_constant_offset expert).

But I can mitigate this from predcom as well, in some ad-hoc way (rather
than trying to be conservative).  Testing a patch.

[Bug target/118950] [14/15 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Robin Dapp from comment #5)
> Yeah, the original statement is recognized as a mask conversion pattern:
> 
> pr118950.c:9:21: note:   vect_recog_mask_conversion_pattern: detected: _152
> = .MASK_LOAD (_230, 8B, _229, 0);
> pr118950.c:9:21: note:   mask_conversion pattern recognized: patt_355 =
> .MASK_LOAD (_230, 8B, patt_54, 0);
> 
> but also as a scatter/gather:
> 
> pr118950.c:9:21: note:   gather/scatter pattern: detected: _152 = .MASK_LOAD
> (_230, 8B, _229, 0);
> pr118950.c:9:21: note:   gather_scatter pattern recognized: patt_375 =
> .MASK_LEN_GATHER_LOAD ((sizetype) _215 + 20, _85, 1, 0, _229, 0);
> 
> The type of _152 is _Bool but patt_375's type is unsigned char.  With
> unsigned char the presence of padding bits is not obvious and we should have
> looked at _152's type.

I suppose

  tree load_lhs = vect_recog_temp_ssa_var (gs_info.element_type, NULL);
  gimple_call_set_lhs (pattern_stmt, load_lhs);

is wrong then and confuses bool patterns?  vect_recog_mask_conversion_pattern
simply uses

  lhs = vect_recog_temp_ssa_var (TREE_TYPE (lhs), NULL);
  gimple_call_set_lhs (pattern_stmt, lhs);

so the original LHS type.

[Bug fortran/104651] [OOP] CLASS with assumed-size/assumed-rank array

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

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

--- Comment #4 from Tobias Burnus  ---
Cf. also commit r15-7661-g8293b9e40f12e9 – especially the FIXME in
in trans-types.cc's gfc_get_derived_type.