[Bug fortran/120889] [16 regression] gfortran.dg/asan/array_constructor_1.f90 Fails since r16-1696-gdff66a690f6d47

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Andre Vehreschild  ---
I can not reproduce this on powerpc64le nor on x86_64 nor on aarch64. Can you
please recheck and reopen with added details when the error prevails? Which
sanitizer did you use (in code, system provided)? What are the parameters to
configure? On which system are you running? HW or emulated-VM?

[Bug c++/88853] ICE: verify_type failed (error: type variant differs by TYPE_PACKED) with -fpack-struct -g

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
For this C++ code:

cvise $ more bug1108.cc
template 
constexpr bool is_trivially_destructible_v = __is_trivially_destructible(_Tp);
template  struct _Traits {
  static constexpr bool _S_trivial_dtor =
  (is_trivially_destructible_v<_Types> && ...);
  static constexpr bool _S_trivial_move_assign = _S_trivial_dtor;
};
template  struct _Move_assign_base {};
template 
using _Move_assign_alias =
_Move_assign_base<_Traits<_Types...>::_S_trivial_move_assign>;
template 
struct _Variant_base : _Move_assign_alias<_Types...> {};
template  struct vector {
  const _Tp data();
};
template  using _variant = _Variant_base>;
template  typename K> struct y_comb : K> {};
void get(const y_comb<_variant>) {}
cvise $ 

Recent g++ does this:

cvise $ ~/gcc/results/bin/g++ -g -fpack-struct bug1108.cc 2>&1 | greperror:
bug1108.cc:14:32: error: type variant differs by TYPE_PACKED
bug1108.cc:14:32: internal compiler error: ‘verify_type’ failed
cvise $

[Bug c++/120495] error: non-template type 'coroutine_handle' used as a template

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

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

--- Comment #5 from Iain Sandoe  ---
this was reported against GCC-15.1 - I was expecting to back-port for 15.2, so
perhaps re-open so that it does not get forgotten?

[Bug c++/120495] error: non-template type 'coroutine_handle' used as a template

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

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

--- Comment #6 from LIU Hao  ---
oh, as you wish.

[Bug middle-end/120709] [15 Regression] ICE in expand_builtin_crc_table_based with __builtin_crc8_data8 and non constant poly argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15/16 Regression] ICE in   |[15 Regression] ICE in
   |expand_builtin_crc_table_ba |expand_builtin_crc_table_ba
   |sed with|sed with
   |__builtin_crc8_data8 and|__builtin_crc8_data8 and
   |non constant poly argument  |non constant poly argument

--- Comment #7 from Andrew Pinski  ---
Fixed so far on the trunk. Will backport in a week or so.

[Bug middle-end/120709] [15/16 Regression] ICE in expand_builtin_crc_table_based with __builtin_crc8_data8 and non constant poly argument

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r16-2044-gbe07dd9a96a7a6f8fb59c939eda84d74b54f8182
Author: Andrew Pinski 
Date:   Sun Jul 6 10:20:26 2025 -0700

crc: Error out on non-constant poly arguments for the crc builtins
[PR120709]

These builtins requires a constant integer for the third argument but
currently
there is assert rather than error. This fixes that and updates the
documentation too.
Uses the same terms as was being used for the __builtin_prefetch arguments.

Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/120709

gcc/ChangeLog:

* builtins.cc (expand_builtin_crc_table_based): Error out
instead of asserting the 3rd argument is an integer constant.
* internal-fn.cc (expand_crc_optab_fn): Likewise.
* doc/extend.texi (crc): Document requirement of the poly argument
being a constant.

gcc/testsuite/ChangeLog:

* gcc.dg/crc-non-cst-poly-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug c++/63164] unnecessary calls to __dynamic_cast

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

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

--- Comment #8 from Florian Weimer  ---
There's this big comment in typeinfo:

// Determine whether typeinfo names for the same type are merged (in which
// case comparison can just compare pointers) or not (in which case strings
// must be compared), and whether comparison is to be implemented inline or
// not.  We used to do inline pointer comparison by default if weak symbols
// are available, but even with weak symbols sometimes names are not merged
// when objects are loaded with RTLD_LOCAL, so now we always use strcmp by
// default.  For ABI compatibility, we do the strcmp inline if weak symbols
// are available, and out-of-line if not.  Out-of-line pointer comparison
// is used where the object files are to be portable to multiple systems,
// some of which may not be able to use pointer comparison, but the
// particular system for which libstdc++ is being built can use pointer
// comparison; in particular for most ARM EABI systems, where the ABI
// specifies out-of-line comparison.  The compiler's target configuration
// can override the defaults by defining __GXX_TYPEINFO_EQUALITY_INLINE to
// 1 or 0 to indicate whether or not comparison is inline, and
// __GXX_MERGED_TYPEINFO_NAMES to 1 or 0 to indicate whether or not pointer
// comparison can be used.

So I'm not sure how much we can optimize the final case for GNU systems.

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #9 from Sam James  ---
(In reply to Fangrui Song from comment #8)
> I am curious when the regression started to happen.

I think it's probably the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117100#c1 (it got broken by a
backport that is in 13.3).

[Bug c/120978] New: Punctuators that contain # or %: are incorrectly rejected within attributes

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 120978
   Summary: Punctuators that contain # or %: are incorrectly
rejected within attributes
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

The following code is not accepted by GCC:

[[ignored(##)]]int main(){}

Unknown attributes should be ignored, so this code should be valid. The issue
seems to be that GCC rejects any code that contains #, ##, %:, and %:%:
punctuators after preprocessing. However, these punctuators can be validly used
within attributes so they shouldn't be rejected unconditionally. Clang accepts
this code, ignoring the warning for an ignored attribute.

This bug also exists in the GCC C++ compiler.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC also rejects this:
(1): error C2014: preprocessor command must start as first nonwhite
space
(1): error C2958: the left '[[' found at '(1)' was not matched
correctly

EDG also rejects this:
"", line 1: error: "#" not expected here
  [[ignored(##)]]int main(){}
^

So maybe this is a clang bug ...

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

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

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

--- Comment #2 from Andrew Pinski  ---
The C23 spec says:
any token other than a parenthesis, a bracket, or a brace

But # is not a token in C; it is only a preprocessor token ...

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> The C23 spec says:
> any token other than a parenthesis, a bracket, or a brace
> 
> But # is not a token in C; it is only a preprocessor token ...

I was wrong there, it is a C token but I suspect it is considered either the
`#` or `##` pp operator which case then would be invalid here.
And that is why GCC, EDG and MSVC all reject this because those 2 pp operators
are processed earlier than attribute processing.

But I could be reading the spec wrong still.

[Bug libstdc++/120976] error: static_assert( !is_same_v<__float128, long double> failed

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

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

--- Comment #1 from John David Anglin  ---
I would have thought __float128 and long double should have been the same
on this target.

[Bug libstdc++/120976] error: static_assert( !is_same_v<__float128, long double> failed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-07-06
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to John David Anglin from comment #1)
> I would have thought __float128 and long double should have been the same
> on this target.

They are, that's the problem.

The formatter<__float128, _CharT> specialization should not be used on targets
where __float128 and long double are the same.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #19 from Segher Boessenkool  ---
Hi Peter!

(In reply to Peter Bergner from comment #18)
> So the error message is coming from this hunk in my patch:
> 
> + /* Both the earlyclobber operand and conflicting operand
> +cannot both be user defined hard registers.  */
> + if (HARD_REGISTER_P (operand_reg[i])
> + && REG_USERVAR_P (operand_reg[i])
> + && operand_reg[j] != NULL_RTX
> + && HARD_REGISTER_P (operand_reg[j])
> + && REG_USERVAR_P (operand_reg[j]))
> +   fatal_insn ("unable to generate reloads for "
> +   "impossible constraints:", curr_insn);
> 
> ...which I believe is correct.

Yes, that is correct.  Was that patch ever committed?  Should this PR
be open at all then?

The REG_USER_VAR_P things aren't necessary really, if RA decides to do
this it is just as wrong, but it will not decide to do this anyway.

> As you said, operand 4 cannot use the same
> register as the early clobber output operand 0, and this hunk is catching
> the illegal usage.  That is a good thing.

Yup.

Xi, please open your own PR for the loongarch problem?  I'll close this one
(as fixed) asap.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #20 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #17)
> The reason operands 0, 1 and 4 all use the register r23, is that each
> operand is using the same pseudo, coming from variable "x", which is a user
> defined hard register:
> 
>register long x asm ("s0");

So, user error.

> It does seem wrong that combine succeeded in combining those patterns, but
> as Segher mentioned, it's recog() that said it was "ok".

Yes, combine has nothing to do with this (as usual whenever combine is
blamed!)

> (In reply to Segher Boessenkool from comment #16)
> > It is allowed by recog().  Most likely your pattern is incorrect, but it
> > is not completely impossible there is something wrong in genrecog.cc --
> > but that isn't combine either.
> 
> Does recog() not check for early clobber when run before RA?

It does not care at all if anything is a hard reg or a pseudo, nor if
any pseudos still exist ("RA has not yet run").

> Or does it
> assume a pseudo cannot early clobber itself?

It does not assume such things, no.  In very many (older) backends many
pseudos are written to multiple times (and not just on the branches of
a diamond either).  That just makes it hard (or impossible) for RA to do
a good job (or to do its job at all), and it makes combine a lot less
effective, etc.; SSA form is good form!  But anything valid is valid.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #9 from Harald van Dijk  ---
I think Andrew is right for C++, but wrong for C. The relevant part in the
phases of translation is translation phase 7: "Each preprocessing token is
converted into a token". In C++, although #, ##, %: and %:%: are valid
pp-tokens, they are not valid tokens: https://eel.is/c++draft/lex.token
includes only operator-or-punctuator, not preprocessing-op-or-punc. In C,
however, #, ##, %: and %:%: are included in punctuators, making them valid
tokens, and there does not seem to be any rule disallowing them in a
balanced-token-sequence.

I would be highly surprised if this difference between C and C++ is
intentional.

[Bug c++/120495] error: non-template type 'coroutine_handle' used as a template

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

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

--- Comment #4 from LIU Hao  ---
https://github.com/msys2/MINGW-packages/issues/24209#issuecomment-3019838909

[Bug libstdc++/120976] error: static_assert( !is_same_v<__float128, long double> failed

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

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

--- Comment #3 from Tomasz Kamiński  ---
I have posted this patch in May, that will fix the issue:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061450.html
I think we should merge it.

The only architecture where __float128 exists and is different from long
double, that I am aware of is x86_64. However, this patch covers that case, via
formatting it using _Float128.

[Bug tree-optimization/120980] Vectorizer (early exit) introduces out-of-bounds memory access

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

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

--- Comment #1 from Tamar Christina  ---
I'm not sure that I'd draw the same conclusion. I view it as the vectorizer has
put a 32-byte alignment requirement on the object and so I'd consider the
object itself to be 32-bytes sized. 

So to the notion of the object the vectorizer has it's a partial out of bounds
access.

Otherwise if a1 was just {0} even doing two element vector loads, and later
scalarizing the loads means that that the second scalar access becomes
"invalid" while the vector version would be valid.

So I don't think this works unless the object is considered to be sized
according to the alignment.

[Bug rtl-optimization/120973] New: ICE on x86_64-linux-gnu: verify_flow_info failed with naked attribute: wrong insn in the fallthru edge

[jiangchangwu at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 120973
   Summary: ICE on x86_64-linux-gnu: verify_flow_info failed with
naked attribute: wrong insn in the fallthru edge
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchangwu at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/nGrb6dP8e

***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)

***
Program:
$ cat mutant.c
__attribute__((naked)) int a() {
  static int b;
  if (b) {
&&c;
&&d;
b = 1;
  }
  goto * 0;
c:
  return 1;
d:
  return 2;
}
void main() {}

***
Command Lines:
$ gcc -O2 mutant.c
mutant.c: In function 'a':
mutant.c:13:1: error: verify_flow_info: Incorrect fallthru 8->9
   13 | }
  | ^
mutant.c:13:1: error: wrong insn in the fallthru edge
(barrier 56 53 58)
during RTL pass: bbro
mutant.c:13:1: internal compiler error: verify_flow_info failed
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x138dea2 verify_flow_info()
../../gcc/gcc/cfghooks.cc:287
0x137cb0c checking_verify_flow_info()
../../gcc/gcc/cfghooks.h:214
0x13c7a39 cfg_layout_finalize()
../../gcc/gcc/cfgrtl.cc:4631
0x4bbf965 execute
../../gcc/gcc/bb-reorder.cc:2683
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.

[Bug target/120959] [16 Regression] 9% slowdown of 549.fotonik3d_r on Zen5 since r16-1645-g309dbcea2cabb3

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #4 from Tamar Christina  ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > That change shouldn't have caused code generation changes IIRC.
> 
> That is, I would have expected RTL expansion to expand the
> division/multiplications as shifts.

I've been looking into this and PR120805

There are two changes, first one is simple,
there are some match.pd rules to optimize shifts into & for rounding down to
the nearest multiple of the VF.

These don't trigger now since we get one of the shifts as a multiplication.
I've added the missing foldings for unsigned integers.  That shouldn't have
resulted in any large loss though as this is only triggered in the preheader.

The second change is that before the bounds variable didn't have any range
attached to it.

e.g.

bnd.704_180 = _181 - _132;

but now it shows

# RANGE [irange] unsigned int [1, 2147483647]
bnd.704_180 = _181 - _132;

for some reason ranges don't seem to be determined on shifts.
This additional change information causes additional foldings
to apply. in the case of PR120805 this causes it to remove
some codepaths that are not reachable and results in the
removal of instructions, hende the change in asm output.

The range above is correct, due to the loop versioning that's happening
in the loop.

I suspect that a similar thing is happening here and it's perturbing something
in the backend.  At the GIMPLE level the changes look sound.

So I'll need to ask someone with some more knowledge of the x86 backend
to take a look, as this seems target expansion specific.

[Bug testsuite/120805] [16 Regression] gcc.target/powerpc/p9-vec-length-epil-4.c fail starting with r16-1645-g309dbcea2cabb3

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

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

--- Comment #3 from Tamar Christina  ---
before the bounds variable didn't have any range attached to it.

e.g.

bnd.704_180 = _181 - _132;

but now it shows

# RANGE [irange] unsigned int [1, 2147483647]
bnd.704_180 = _181 - _132;

For some reason ranges don't seem to be determined on shifts.

This causes it to remove
some codepaths that are not reachable and results in the
removal of instructions, hende the change in asm output.

The range above is correct, due to the loop versioning that's happening
in the loop.

So I think these are testisms, but but the generic change looks correct.

I think someone with more PPC knowledge should have a look and say if
the changes are resulting in worse code or not.  I don't want to blindly
update the testcase.

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

--- Comment #11 from Tamar Christina  ---
(In reply to Richard Biener from comment #10)
> (In reply to Tamar Christina from comment #8)
> > C testcase
> > 
> > typedef struct {
> > int _M_current;
> > } __normal_iterator;
> > 
> > typedef struct {
> > char _M_elems[5];
> > } array_5;
> > 
> > __normal_iterator __trans_tmp_1 = {0};
> > 
> > array_5 copySourceIntoTarget() {
> > array_5 target;
> > char* target_it = target._M_elems;
> > 
> > while (__trans_tmp_1._M_current != 0) {
> > *target_it = 0;
> > __trans_tmp_1._M_current++;
> > target_it++;
> > }
> > 
> > return target;
> > }
> > 
> > compiled with -mcpu=neoverse-n2 -O1 -ftree-loop-vectorize
> > 
> > The cost model for Neoverse-N2 is needed to get it to generate an Adv.SIMD
> > main loop and an SVE trailing loop.
> 
> So the issue seems to be that DSE sees the .MASK_STORE after the epilog
> is dead because it is to &target + _55 + POLY_INT_CST[16, 16].  Given
> pointers may not "advance" to before an object we get an ao_ref with base
> 
> &target + _55
> 
> and offset = POLY_INT_CST[16, 16]
> 
> that is always out of char _M_elems[5].
> 
> So, iff that pointer increment by _55 is say for alignment peeling via mask
> with
> a negative bias that pointer arithmetic invokes UB and has to be done
> in uintptr_t.

It's a POINTER_PLUS though, so offset is a ssize_type so should be ok no?

that said, that store isn't the problem, that store is indeed dead.

The store that's still alive is

  vectp_target.14_54 = &targetD.4595 + _55;
  max_mask_63 = .WHILE_ULT (0, bnd.12_51, { 0, ... });
  # .MEM_48 = VDEF <.MEM_31>
  # USE = anything 
  # CLB = anything 
  .MASK_STORE (vectp_target.14_54, 8B, max_mask_63, { 0, ... });

this is storing to &targetD.4595 + _55 and _55 is a PHI ;

so it's a ref with targetD.4595 and offset 0.

So that's within _M_elems[5].

The versioning if on VF here, so if the main loop is skipped the epilogue does
all the work.

Still working through why that ref isn't seen as alive as

  # .MEM_17 = PHI <.MEM_12(10), .MEM_5(D)(2)>
  # .MEM_6 = VDEF <.MEM_17>
  D.4601 = targetD.4595;
  # .MEM_7 = VDEF <.MEM_6>
  targetD.4595 ={v} {CLOBBER(eos)};
  # VUSE <.MEM_7>
  return D.4601;

keeps it alive.

[Bug c++/120975] New: GCC incorrectly accepts requires-clause for virtual functions

[ykakeyama3014 at gmail dot com via Gcc-bugs]

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

Bug ID: 120975
   Summary: GCC incorrectly accepts requires-clause for virtual
functions
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ykakeyama3014 at gmail dot com
  Target Milestone: ---

GCC seems to accept incorrect code like below:

template 
struct A {
  virtual void f() requires true;
};

C++ standard explicitly forbids constraints for virtual functions as per
[class.virtual]#6.

Additionally, GCC also accepts:

template 
struct A {
  virtual void f() requires true final;
};

This is syntactically not allowed, as member-declarator and function-definition
cannot have both virt-specifier-seq and requires-clause; see
[class.mem.general] and [dcl.fct.def.general].

references:
https://eel.is/c++draft/class.virtual#6
https://eel.is/c++draft/class.mem.general#nt:member-declarator
https://eel.is/c++draft/dcl.fct.def.general#nt:function-definition

[Bug c++/120975] GCC incorrectly accepts requires-clause for virtual functions

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

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

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 105699 ***

[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ykakeyama3014 at gmail dot com

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

[Bug c/120921] gimple verifier (and gimple FE) accepts CST on LHS

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:5c2dc85c1923af118a9ec9657dc969fd3d95498a

commit r16-2038-g5c2dc85c1923af118a9ec9657dc969fd3d95498a
Author: Andrew Pinski 
Date:   Sat Jul 5 12:38:35 2025 -0700

tree-cfg: Reject constants and addr on lhs for assign single [PR120921]

For GIMPLE_SINGLE_RHS, we don't currently test LHS for some invalid cases.
In this case all constants and ADDR_EXPR should be invalid on the LHS.
Also for vector (non-empty) constructors, the LHS needs to be an
is_gimple_reg.

This adds the checks.
Also this fixes the following gimple testcase so it no longer ICEs, all
functions are correctly rejected:
```
typedef vector int vi;

void __GIMPLE b1(int t) {
  1 = t;
}
void __GIMPLE b2() {
  1 = 2;
}
void __GIMPLE b3(int t, int t1) {
  &t1 = &t;
}
void __GIMPLE b4(vi t, vi t1) {
  _Literal(vi){0} = _Literal(vi){1};
}
void __GIMPLE b5(vi t, vi t1) {
  _Literal(vi){t} = _Literal(vi){t1};
}
```

Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/120921
gcc/ChangeLog:

* tree-cfg.cc (verify_gimple_assign_single): Reject constant and
address expression LHS.
For non-empty vector constructors, make sure the LHS is an
is_gimple_reg.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/120951] [16 regression] error: gimple cond condition cannot throw

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

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

--- Comment #11 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r16-2039-ge17e3de4bbb1848ce1ce7d69d7786b92f1969b11
Author: Andrew Pinski 
Date:   Sat Jul 5 08:40:45 2025 -0700

cdce: Fix non-call exceptions with signaling nans [PR120951]

The cdce code introduces a test for a NaN using the EQ_EXPR code.
The problem is EQ_EXPR can cause an exception with non-call exceptions
and signaling nans turned on. This is now correctly rejected by the verfier
since r16-241-g4c40e3d7b9152f.
The fix is seperate out the comparison into its own statement from the
GIMPLE_COND.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/120951

gcc/ChangeLog:

* tree-call-cdce.cc (use_internal_fn): For non-call exceptions
with EQ_EXPR can throw for floating point types, then create
the EQ_EXPR seperately.

gcc/testsuite/ChangeLog:

* gcc.dg/torture/pr120951-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug c/101057] [meta-bug] [gimplefe] GIMPLE frontend issues

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

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

Bug 120921 Summary: gimple verifier (and gimple FE) accepts CST on LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921

   What|Removed |Added

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

[Bug c/120921] gimple verifier (and gimple FE) accepts CST on LHS

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/120951] [16 regression] error: gimple cond condition cannot throw

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/120973] ICE on x86_64-linux-gnu: verify_flow_info failed at -O2 and above with naked attribute: wrong insn in the fallthru edge

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED
   Severity|normal  |minor

--- Comment #2 from Andrew Pinski  ---
ICEs even on invalid input (for the most part) should not happen.

[Bug middle-end/120973] ICE on x86_64-linux-gnu: verify_flow_info failed at -O2 and above with naked attribute: wrong insn in the fallthru edge

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end
 Ever confirmed|0   |1
   Last reconfirmed||2025-07-06
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
Maybe during expand error out if there is anything besides an inline-asm inside
a function marked with the naked attribute 

[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os

[fiesh at zefix dot tv via Gcc-bugs]

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

--- Comment #5 from fiesh at zefix dot tv ---
Ah of course, sizing individual object files might make it much easier.  Thank
you, I think I'll be able to create a proper testcase this way.  I'll get back
to here when I've reduced it.

[Bug c++/120974] New: Default -fdeps-file and -fdeps-target arguments don't support output directories with spaces

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

Bug ID: 120974
   Summary: Default -fdeps-file and -fdeps-target arguments don't
support output directories with spaces
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.werner at hotmail dot de
  Target Milestone: ---

Imagine the following module:


export module test;

export void foo() {}

If we have a target directory named "dir with spaces", the following command
will fail, because "too many filenames" are given:

g++ -fmodules -fdeps-format=p1689r5 -c -MD -o 'dir with spaces/test.o'
test.cpp

This is because the spec rule in
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=c6e600fa0d34712682f6457721c6d212caafcf26;hb=024f135a1e9b8f8e102960357cae6e99e1dbe6eb#l1240
fails when the output directory contains spaces.

The following command does work correctly:

g++ -fmodules -fdeps-format=p1689r5 -c -MD -o 'dir with spaces/test.o'
'-fdeps-file=dir with spaces/test.ddi' '-fdeps-target=dir with spaces/test.o'
test.cpp


System info:

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++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--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 --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 --disable-libada --enable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --without-isl --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-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.0 (Gentoo 15.1.0 p55

[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)

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

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

--- Comment #13 from Alexandre Oliva  ---
I'm not sure how to tell, but the fact that it has an lto-related symbolic name
suggested to me it was generated by the compiler rather than by the linker:
__sinput__get_source_file_index__assertions.0.lto_priv.0_veneer

Grepping for veneer in the sources, I don't see that the compiler would
generate such symbols, but the linker would pick such names for some stubs.  So
I stand corrected, thanks for the lead.

I wonder if this is the sort of thing that -mlong-calls is meant to work
around...

[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target

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

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

--- Comment #12 from Tamar Christina  ---
Looks like the problem is that during ao_ref_init_from_ptr_and_range when
initializing vectp_target.14_54 = &targetD.4595 + _55;

we don't enter the block splitting apart POINTER_PLUS_EXPR.

So it ends up creating a ref with the base being MEM_REF <&targetD.4595 + _55>

later on when checking of &targetD.4595 and MEM_REF <&targetD.4595 + _55> could
alias in refs_may_alias_p it doesn't think these two can alias, even though

  # _38 = PHI 
  # RANGE [irange] sizetype [0, 0][32, 4294967264] MASK 0xffe0 VALUE 0x0
  _55 = (sizetype) _38;


so clearly they can alias. Need to look into how tree-ssa-alias normally
handles PHI offsets.

[Bug rtl-optimization/120973] ICE on x86_64-linux-gnu: verify_flow_info failed at -O2 and above with naked attribute: wrong insn in the fallthru edge

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Please see [1]:

naked

This attribute allows the compiler to construct the requisite function
declaration, while allowing the body of the function to be assembly code. The
specified function will not have prologue/epilogue sequences generated by the
compiler. Only basic asm statements can safely be included in naked functions
(see Basic Asm — Assembler Instructions Without Operands). While using extended
asm or a mixture of basic asm and C code may appear to work, they cannot be
depended upon to work reliably and are not supported.

[1] https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/x86-Function-Attributes.html

[Bug libstdc++/120976] New: error: static_assert( !is_same_v<__float128, long double> failed

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

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

Bug ID: 120976
   Summary: error: static_assert( !is_same_v<__float128, long
double> failed
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: tkaminsk at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

libtool: compile:  /home/dave/gnu/gcc/objdir64/./gcc/xgcc -shared-libgcc
-B/home/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-16/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-16/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-16/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-16/hppa64-hp-hpux11.11/sys-include -fno-checking
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/../libgcc
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++20 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=19
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=tzdb.lo -fimplicit-templates -O2 -g -I. -c
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc  -DPIC -D_GLIBCXX_SHARED -o
tzdb.o
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:40,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/ratio:41,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/chrono.h:39,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/chrono:45,
 from ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:31:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/semaphore_base.h:
In constructor
'std::__atomic_semaphore::__atomic_semaphore(std::__detail::__platform_wait_t)':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/semaphore_base.h:178:32:
warning: comparison of unsigned expression in '>= 0' is always true
[-Wtype-limits]
  178 |   __glibcxx_assert(__count >= 0 && __count <= _S_max);
  |^~~~
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11/bits/c++config.h:657:49:
note: in definition of macro '__glibcxx_assert'
  657 | if (std::__is_constant_evaluated() && !bool(cond)) 
\
  | ^~~~
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: At global scope:
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:195:52: warning:
'init_priority' attribute ignored [-Wattributes]
  195 |   constinit tzdb_list tzdb_list::_Node::_S_the_list(nullptr);
  |^
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:198:58: warning:
'init_priority' attribute ignored [-Wattributes]
  198 |   constinit tzdb_list::_Node::head_ptr
tzdb_list::_Node::_S_head_owner{nullptr};
  |  ^
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/chrono_io.h:41,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/chrono:3378:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/format: In
instantiation of 'struct std::formatter':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:3559:54:
  required from 'constexpr const bool
std::is_default_constructible_v >'
 3559 |   inline constexpr bool is_default_constructible_v =
__is_constructible(_Tp);
  | 
^~~
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/format:4942:23:
  required from
'std::__format::_Formatting_scanner,
wchar_t>::_M_format_arg(std::size_t):: [with auto:9 = long
double]'
 4942 |   else if constexpr (is_default_constructible_v<_Formatter>)
  |  ^~
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/format:4360:44:
  required from 'decltype(auto)
std::basic_format_arg<_Context>::_M_visit(_Visitor&&, std::__format::_Arg_t)
[with _Visitor =
std::__format::_Formatting_scanner,
wchar_t>::_M_format_arg(std::size_t)::; _Context =
std:

[Bug middle-end/120709] [15/16 Regression] ICE in expand_builtin_crc_table_based with __builtin_crc8_data8 and non constant poly argument

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 61809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61809&action=edit
Patch which I am testing

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

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

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

--- Comment #12 from Jonathan Wakely  ---
That's why the bug is still open.

[Bug sanitizer/120970] New: -static-pie together with -fsanitize=address should be disallowed

[christian.morales.vega at gmail dot com via Gcc-bugs]

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

Bug ID: 120970
   Summary: -static-pie together with -fsanitize=address should be
disallowed
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.morales.vega 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: ---

If I take this code

```
static int x[1];

int main() {
  x[1] = 5;
}
```
and compile it with "gcc -o test test.c -fsanitize=address", ASan correctly
complains when running "test".

If I add "-static" to it, it correctly fails to even try to build anything
```
$ gcc -o test test.c -fsanitize=address -static
gcc: error: cannot specify -static with -fsanitize=address
```

But if I use -static-pie instead of -static, I only get
```
# gcc -o test test.c -fsanitize=address -static-pie -fpie
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/15/libasan.a(asan_interceptors.o): in function
`InitializeCommonInterceptors()':
(.text+0xea7a): warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/15/libasan.a(asan_interceptors.o): in function
`___interceptor_lgamma.part.0':
(.text+0x173d7): undefined reference to `signgam'
/usr/bin/ld: (.text+0x1748f): undefined reference to `signgam'
/usr/bin/ld: (.text+0x174af): undefined reference to `signgam'
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/15/libasan.a(asan_interceptors.o): in function
`___interceptor_lgammaf.part.0':
(.text+0x17737): undefined reference to `signgam'
/usr/bin/ld: (.text+0x177ef): undefined reference to `signgam'
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/15/libasan.a(asan_interceptors.o):(.text+0x1780f):
more undefined references to `signgam' follow
collect2: error: ld returned 1 exit status
```

And by adding -lm, I can actually make it create a binary
```
# gcc -o test test.c -fsanitize=address -static-pie -fpie -lm
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/15/libasan.a(asan_interceptors.o): in function
`InitializeCommonInterceptors()':
(.text+0xea7a): warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking
```

which fails in a more (not really) "surprising" way
```
$ ./test 
AddressSanitizer: CHECK failed:
sanitizer_common_interceptors_memintrinsics.inc:239
"((__interception::real_memcpy)) != (0)" (0x0, 0x0) (tid=160)


$
```

So, it seems to me, using -static-pie should make gcc complaing with "gcc:
error: cannot specify -static-pie with -fsanitize=address".

[Bug c/120971] New: ICE on x86_64-linux-gnu: in omp_extract_for_data, at omp-general.cc:423

[jiangchangwu at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 120971
   Summary: ICE on x86_64-linux-gnu: in omp_extract_for_data, at
omp-general.cc:423
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchangwu at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/Mzb6ss8MK

***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)

***
Program:
$ cat mutant.c
enum a b;
enum a { c, d } e() {
#pragma omp for
  for (b = c; b < d; ++b)
;
}

***
Command Lines:
$ gcc -fopenmp mutant.c
during GIMPLE pass: omplower
mutant.c: In function 'e':
mutant.c:3:9: internal compiler error: in omp_extract_for_data, at
omp-general.cc:423
3 | #pragma omp for
  | ^~~
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x54d2d0a fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1803
0x1d26ccb omp_extract_for_data(gomp_for*, omp_for_data*, omp_for_data_loop*)
../../gcc/gcc/omp-general.cc:423
0x1da98b8 lower_omp_for
../../gcc/gcc/omp-low.cc:11846
0x1dc5a4b lower_omp_1
../../gcc/gcc/omp-low.cc:14826
0x1dc7578 lower_omp
../../gcc/gcc/omp-low.cc:15038
0x1dc583e lower_omp_1
../../gcc/gcc/omp-low.cc:14810
0x1dc7578 lower_omp
../../gcc/gcc/omp-low.cc:15038
0x1dc7925 execute_lower_omp
../../gcc/gcc/omp-low.cc:15077
0x1dc7d4c execute
../../gcc/gcc/omp-low.cc:15131
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.

[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from Eric Botcazou  ---
> Anyhow, this explains why lto and PIE are both needed to trigger the problem.

Thanks for the investigation!

> As for a solution, unless the arm port can find some way to avoid the
> register overlap for thunks that need the static chain.
> 
> Failing that, I have a hunch that the issue has to do with the call's
> crossing lto (re)compilation units, in which case one solution could be to
> sacrifice some optimization opportunities and force functions and their
> inner functions to remain in a single unit.

Is that really a MI thunk or rather a PLT stub?  In the latter case, it's a
known pitfall and, for example, you must be sure not to make functions that
require the static chain public.  But of course LTO can do its own damages.

[Bug tree-optimization/120972] New: restrict does not work for not-parameter pointer

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 120972
   Summary: restrict does not work for not-parameter pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

We could get the below loop vectorized with options "-Ofast -S -mavx512f
--param vect-max-version-for-alias-checks=0", since __restrict__ on parameters
could ensure no alias among memory accesses.

void add(char* __restrict__ a0, char * __restrict__ b0, char * __restrict__ c0,
int n, int m)
{
  double *__restrict__ a = (double *) &a0[m];
  double *__restrict__ b = (double *) &b0[m];
  double *__restrict__ c = (double *) &c0[m];

  for(int i = 0; i < n; i++)
  c[i] = a[i] + b[i];
}

But alias-analysis does not follow the same assumption for __restrict__
non-parameter pointers, as the result, a modified case below could not be
vectorized with the same options, since runtime alias checks are disabled.

char *ga();
char *gb();
char *gc();

void add(int n)
{
  double *__restrict__ a = (double *) ga();
  double *__restrict__ b = (double *) gb();
  double *__restrict__ c = (double *) gc();

  for(int i = 0; i < n; i++)
  c[i] = a[i] + b[i];
}

[Bug tree-optimization/120972] restrict does not work for not-parameter pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||alias, missed-optimization

[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os

[fiesh at zefix dot tv via Gcc-bugs]

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

--- Comment #6 from fiesh at zefix dot tv ---
Alas, running `avr-size` on the individual modules doesn't produce anything of
significant data size.  They also don't add up even remotely to the final
linked file.  Am I doing something wrong?

I'm fairly certain I know which translation unit would be a good testcase
candidate, but I'd need some means to assess its data size.  Using `nm` and
filtering for symbol types d / D also hardly shows anything.

[Bug tree-optimization/119920] Missed vectorization for conditioned adds

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Alfie Richards from comment #4)
> Ah okay great, I'll shelve this for now and check back later.

I am going to start working on this today. I should have a prototype by the end
of this week.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

[luigighiron at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Halalaluyafail3  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The C23 spec says:
> > any token other than a parenthesis, a bracket, or a brace
> > 
> > But # is not a token in C; it is only a preprocessor token ...
> 
> I was wrong there, it is a C token but I suspect it is considered either the
> `#` or `##` pp operator which case then would be invalid here.
> And that is why GCC, EDG and MSVC all reject this because those 2 pp
> operators are processed earlier than attribute processing.
> 
> But I could be reading the spec wrong still.
They are only considered operators during macro expansion. The standard
provides the following example:

> #define hash_hash # ## #
> #define mkstr(a) # a
> #define in_between(a) mkstr(a)
> #define join(c, d) in_between(c hash_hash d)
> char p[] = join(x, y); // equivalent to
> // char p[] = "x ## y";
Which demonstrates that a ## token can be used (in this case stringized)
without causing it to be treated as an operator.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Halalaluyafail3 from comment #4)
> They are only considered operators during macro expansion. The standard
> provides the following example:
> 
> > #define hash_hash # ## #
> > #define mkstr(a) # a
> > #define in_between(a) mkstr(a)
> > #define join(c, d) in_between(c hash_hash d)
> > char p[] = join(x, y); // equivalent to
> > // char p[] = "x ## y";
> Which demonstrates that a ## token can be used (in this case stringized)
> without causing it to be treated as an operator.

Though if 3 of the major compilers all agree and only one disagrees maybe this
should be brought up to the committee as a defect requesting a clearification.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

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

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

--- Comment #6 from Andrew Pinski  ---
The way I read the standard is the following:
during phase 4:
Preprocessing directives are executed,

And it is invalid for `#` or the `##` operator to be outside of `the
replacement list of a function-like macro,` as far as I can tell during phase
4.



Because otherwise it would mean:
```
[[ignored(
#)]]int main(){}
```

Would be invalid C while:
```
[[ignored(#)]]int main(){}
```

Would be valid.  That is white space of a return would matter which I am not
sure is the expected behavior at all.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #21 from Xi Ruoyao  ---
(In reply to Segher Boessenkool from comment #20)
> (In reply to Peter Bergner from comment #17)
> > The reason operands 0, 1 and 4 all use the register r23, is that each
> > operand is using the same pseudo, coming from variable "x", which is a user
> > defined hard register:
> > 
> >register long x asm ("s0");
> 
> So, user error.

The user cannot anticipate what the RTL will become like after optimization
passes at all.

So it means the user just *cannot* use defined hard register in the code at
all, as long as the machine description has an earlyclobber?  That would just
seem insane.

Or would we need to add the checks like
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688634.html for every insn
having an earlyclobber?  That would seem insane too IMO.

[Bug rtl-optimization/120983] New: recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

Bug ID: 120983
   Summary: recog violates earlyclobber with user-defined hard
register before reload (causing ICE on
gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

bitwise-shift-reassoc-clobber.c:12:1: error: unable to generate reloads for
impossible constraints:
   12 | }
  | ^
(insn 12 10 15 2 (set (reg/v:DI 23 $r23 [ x ])
(sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23
$r23 [ x ])
(const_int 3 [0x3]))
(const_int 2208 [0x8a0])) 0)
(reg:SI 23 $r23 [ x ]
"bitwise-shift-reassoc-clobber.c":11:7 272 {and_alsl_reversesi_extended}
 (nil))

During combine we get:

Trying 10 -> 12:
   10: r91:DI=sign_extend($r23:DI<<0x3&0x8a0#0+$r23:SI)
  REG_DEAD $r23:DI
   12: $r23:DI=r91:DI
  REG_DEAD r91:DI
Successfully matched this instruction:
(set (reg/v:DI 23 $r23 [ x ])
(sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23 $r23 [
x ])
(const_int 3 [0x3]))
(const_int 2208 [0x8a0])) 0)
(reg:SI 23 $r23 [ x ]
allowing combination of insns 10 and 12

which violates the earlyclobber in _alsl_reversesi_extended:

  [(set (match_operand:DI 0 "register_operand" "=&r")
(sign_extend:DI
  (plus:SI
(subreg:SI
  (any_bitwise:DI
(ashift:DI
  (match_operand:DI 1 "register_operand" "r0")
  (match_operand:SI 2 "const_immalsl_operand" ""))
(match_operand:DI 3 "const_int_operand" "i"))
  0)
(match_operand:SI 4 "register_operand" "r"]

The combine maintainer suggests either this is a user error, or an issue in the
machine description, or recog is doing things wrong.

I cannot believe this should be considered a user error: the user cannot
anticipate what the RTL optimization passes will do to his/her defined hard
register variable.  Thus if we consider this a user error, the user-defined
hard register variables would be unusable at all.  (If this was an inline-asm
we can claim it as a user error though.)

I also don't think we'd consider this something wrong in the machine
description.  Yes we can do things like
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688634.html for this
specific insn, but how about all other insns using an earlyclobber?  There are
about 1200 matches of [+=]& in *.md, would it be really rational to audit them
one by one???

Thus to me either recog should just reject this, or reload should "work this
around" like what happend before GCC 9.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #22 from Xi Ruoyao  ---
(In reply to Segher Boessenkool from comment #19)
> 
> Xi, please open your own PR for the loongarch problem?  I'll close this one
> (as fixed) asap.

PR120983.

But frankly I still cannot see any difference between that and the powerpc
case.

[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

--- Comment #3 from Segher Boessenkool  ---
Please attach a testcase, and how to compile the code (-O2 etc.).  Oh, and fill
in
the target field :-)

[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Oh look:
/* Both the earlyclobber operand and conflicting operand
   cannot both be user defined hard registers.  */
if (HARD_REGISTER_P (operand_reg[i])
&& REG_USERVAR_P (operand_reg[i])
&& operand_reg[j] != NULL_RTX
&& HARD_REGISTER_P (operand_reg[j])
&& REG_USERVAR_P (operand_reg[j]))
  {
/* For asm, let curr_insn_transform diagnose it.  */
if (INSN_CODE (curr_insn) < 0)
  return false;
fatal_insn ("unable to generate reloads for "
"impossible constraints:", curr_insn);
  }


Which dates to PR 87600.

[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

--- Comment #5 from Andrew Pinski  ---
gcc.target/loongarch/bitwise-shift-reassoc-clobber.c:
```
/* { dg-do run } */
/* { dg-options "-O2" } */

register long x asm ("s0");

#define TEST(x) (int)(((x & 0x114) << 3) + x)

[[gnu::noipa]] void
test (void)
{
  x = TEST (x);
}

int
main (void)
{
  x = 0x;
  test ();
  if (x != TEST (0x))
__builtin_trap ();
}

```

[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

--- Comment #6 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #4)
> Oh look:
> /* Both the earlyclobber operand and conflicting operand
>cannot both be user defined hard registers.  */
> if (HARD_REGISTER_P (operand_reg[i])
> && REG_USERVAR_P (operand_reg[i])
> && operand_reg[j] != NULL_RTX
> && HARD_REGISTER_P (operand_reg[j])
> && REG_USERVAR_P (operand_reg[j]))
>   {
> /* For asm, let curr_insn_transform diagnose it.  */
> if (INSN_CODE (curr_insn) < 0)
>   return false;
> fatal_insn ("unable to generate reloads for "
> "impossible constraints:", curr_insn);
>   }
> 
> 
> Which dates to PR 87600.

Yup, the change was to detect broken inline-asm.  But I don't think it should
happen w/o inline-asm.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #25 from chenglulu  ---
(In reply to Segher Boessenkool from comment #24)
> (In reply to Xi Ruoyao from comment #21)
> > (In reply to Segher Boessenkool from comment #20)
> > > (In reply to Peter Bergner from comment #17)
> > > > The reason operands 0, 1 and 4 all use the register r23, is that each
> > > > operand is using the same pseudo, coming from variable "x", which is a 
> > > > user
> > > > defined hard register:
> > > > 
> > > >register long x asm ("s0");
> > > 
> > > So, user error.
> > 
> > The user cannot anticipate what the RTL will become like after optimization
> > passes at all.
> 
> What?  No.  The user can assume that (barring errors in the compiler) the
> compiler will at any point have an instruction stream that faithfully
> implements what the input code expressed.
> 
> And if the input is non-sensical, the compiler output will be as well, or the
> compiler can give up in some cases.
> 
I also don't quite agree that this is a user error. If the user's code follows
the C standard, shouldn't the compiler ICE even if the output doesn't make
sense?

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #23 from Segher Boessenkool  ---
It is a different target.  Your issue has nothing at all to do with the
problem we used to have.  The root cause is very likely completely unrelated.
Etc. etc. etc.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #24 from Segher Boessenkool  ---
(In reply to Xi Ruoyao from comment #21)
> (In reply to Segher Boessenkool from comment #20)
> > (In reply to Peter Bergner from comment #17)
> > > The reason operands 0, 1 and 4 all use the register r23, is that each
> > > operand is using the same pseudo, coming from variable "x", which is a 
> > > user
> > > defined hard register:
> > > 
> > >register long x asm ("s0");
> > 
> > So, user error.
> 
> The user cannot anticipate what the RTL will become like after optimization
> passes at all.

What?  No.  The user can assume that (barring errors in the compiler) the
compiler will at any point have an instruction stream that faithfully
implements what the input code expressed.

And if the input is non-sensical, the compiler output will be as well, or the
compiler can give up in some cases.

> So it means the user just *cannot* use defined hard register in the code at
> all, as long as the machine description has an earlyclobber?  That would
> just seem insane.

If the user requires multiple values to be held in the same hard register
at the same time, the compiler will not be able to do that.

> Or would we need to add the checks like
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688634.html for every
> insn having an earlyclobber?  That would seem insane too IMO.

Such things are never needed.  But it appears we have a bug somewhere.

[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

--- Comment #1 from Andrew Pinski  ---
So the problem is before reload only the predicates are used and not the
constraints. The early clobbered is never looked at.

I wonder why IRA could not generate a reload here though since it could push
(reg:SI 23 $r23 [ x ]) into its own register for the last operand ...

[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ra

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> So the problem is before reload only the predicates are used and not the
> constraints. The early clobbered is never looked at.
> 
> I wonder why IRA could not generate a reload here though since it could push
> (reg:SI 23 $r23 [ x ]) into its own register for the last operand ...

Sorry LRA and not IRA.

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #26 from Segher Boessenkool  ---
(In reply to chenglulu from comment #25)
> > And if the input is non-sensical, the compiler output will be as well, or 
> > the
> > compiler can give up in some cases.
> > 
> I also don't quite agree that this is a user error. If the user's code
> follows the C standard, shouldn't the compiler ICE even if the output
> doesn't make sense?

The stuff we are talking about here never ever follows the C standard of
course, it uses many GNU extensions.

If a program is wrong, undefined behaviour for example, the compiler cannot
always detect that.  Not until the halting problem is solved.  It is very
nice if we can give nicer error messages, but there is a limit to possibility
there.

[Bug target/120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting

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

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

Bug 118241 Summary: RISC-V ICE: internal compiler error: in int_mode_for_mode, 
at stor-layout.cc:407 caused by prefetch instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118241

   What|Removed |Added

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

[Bug target/118241] RISC-V ICE: internal compiler error: in int_mode_for_mode, at stor-layout.cc:407 caused by prefetch instructions

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

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

Vineet Gupta  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||vineetg at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #13 from Vineet Gupta  ---
Fixed on trunk w/ auto-recorded commit !

[Bug target/120977] New: [16 Regression] ICE on Cortex-M23/M33/M55/M85 with -mcmse

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

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

Bug ID: 120977
   Summary: [16 Regression] ICE on Cortex-M23/M33/M55/M85 with
-mcmse
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: azoff at gcc dot gnu.org
  Target Milestone: ---

arm-none-eabi-gcc gcc/testsuite/gcc.target/arm/cmse/cmse-14.c -mthumb
-mcpu=cortex-m33 -mfloat-abi=soft -O2 -mcmse -S -o - >/dev/null
during RTL pass: expand
gcc/testsuite/gcc.target/arm/cmse/cmse-14.c: In function 'foo':
gcc/testsuite/gcc.target/arm/cmse/cmse-14.c:9:10: internal compiler error:
Segmentation fault
0x2ff66dc internal_error(char const*, ...)
gcc/diagnostic-global-context.cc:517
0x18b4ca1 crash_signal
gcc/toplev.cc:321
0x7fa03326c08f ???
   
/build/glibc-B3wQXB/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1099e78 emit_call_1
gcc/calls.cc:484
0x10a3829 expand_call(tree_node*, rtx_def*, int)
gcc/calls.cc:3734
0x129e7df expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
gcc/expr.cc:12485
0x128fdc5 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
gcc/expr.cc:9529
0x1283f11 store_expr(tree_node*, rtx_def*, int, bool, bool)
gcc/expr.cc:6762
0x128257b expand_assignment(tree_node*, tree_node*, bool)
gcc/expr.cc:6483
0x10c448d expand_call_stmt
gcc/cfgexpand.cc:3149
0x10c8511 expand_gimple_stmt_1
gcc/cfgexpand.cc:4223
0x10c8b47 expand_gimple_stmt
gcc/cfgexpand.cc:4370
0x10c8c63 expand_gimple_tailcall
gcc/cfgexpand.cc:4416
0x10d1418 expand_gimple_basic_block
gcc/cfgexpand.cc:6407
0x10d3ac6 execute
gcc/cfgexpand.cc:7181
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.

The ICE started in r16-1041-g2da641d0170 and is still present in
r16-2034-g6c472b330ac.

[Bug target/120977] [16 Regression] ICE on Cortex-M23/M33/M55/M85 with -mcmse

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm
   Keywords||ice-on-valid-code
   Target Milestone|--- |16.0

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

Fangrui Song  changed:

   What|Removed |Added

 CC||maskray at gcc dot gnu.org

--- Comment #8 from Fangrui Song  ---
(In reply to GCC Commits from comment #6)
> The releases/gcc-13 branch has been updated by Sam James
> :
> 
> https://gcc.gnu.org/g:a987affa2b10cd8a0b1d244d9f010746837e031c
> 
> commit r13-9114-ga987affa2b10cd8a0b1d244d9f010746837e031c
> Author: Aldy Hernandez 
> Date:   Tue May 23 12:34:45 2023 +0200
> 
> Remove buggy special case in irange::invert [PR109934].
> 
> This patch removes a buggy special case in irange::invert which seems
> to have been broken for a while, and probably never triggered because
> the legacy code was handled elsewhere, and the non-legacy code was
> using an int_range_max of int_range<255> which made it extremely
> likely for num_ranges == 255.  However, with auto-resizing ranges,
> int_range_max will start off at 3 and can hit this bogus code in the
> unswitching code.
> 
> PR tree-optimization/109934
> 
> gcc/ChangeLog:
> 
> * value-range.cc (irange::invert): Remove buggy special case.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/tree-ssa/pr109934.c: New test.
> 
> (cherry picked from commit 8d5f050dabbf6dd3b992c3b46661848dbcf30d9e)

This commit in releases/gcc-13 but not in 13.3.0 has resolved a miscompile I've
seen in LLVM llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp.

Worked around in
https://github.com/llvm/llvm-project/commit/6d67794d164ebeedbd287816e1541964fb5d6c99

Requires a -O3 build of llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
(CMAKE_BUILD_TYPE=Release;   RelWithDebInfo uses -O2 and doesn't reproduce)

```
% ninja -C /tmp/out/custom-gcc-13 llc && /tmp/out/custom-gcc-13/bin/llc
llvm/test/CodeGen/X86/2008-08-06-RewriterBug.ll -mtriple=i686
ninja: Entering directory `/tmp/out/custom-gcc-13'
ninja: no work to do.
Unknown immediate size
UNREACHABLE executed at
/home/ray/llvm/llvm/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:904!
```

I am curious when the regression started to happen.

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Filed the clang bug https://github.com/llvm/llvm-project/issues/147217 since it
is the odd one out.

[Bug tree-optimization/120979] New: Missed strdup to malloc + memcpy for known strings

[kaelfandrew at gmail dot com via Gcc-bugs]

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

Bug ID: 120979
   Summary: Missed strdup to malloc + memcpy for known strings
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaelfandrew at gmail dot com
  Target Milestone: ---

Created attachment 61810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61810&action=edit
C code

Flags with -O3.

strdup() shouldn't be called for const strings like "Hello".

Real code that could be optimized include
https://github.com/gcc-mirror/gcc/blob/57d30924e2b3887a1aedc6102daa67bc3272ace7/gcc/config/aarch64/aarch64.cc#L19381

```
static char *
aarch64_offload_options (void)
{
  if (TARGET_ILP32)
return xstrdup ("-foffload-abi=ilp32 -foffload-abi-host-opts=-mabi=ilp32");
  else
return xstrdup ("-foffload-abi=lp64 -foffload-abi-host-opts=-mabi=lp64");
}
```

[Bug tree-optimization/120979] Missed strdup to malloc + memcpy for known strings

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/120979] Missed strdup to malloc + memcpy for known strings

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

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

--- Comment #1 from Andrew Pinski  ---
Note xstrdup  is not the same as strdup ...

```
char *a()
{
  return __builtin_strdump ("");
}
```

Would need to be changed into:
```
char *a()
{
  const char tt[] = "";
  char *t = __builtin_malloc(sizeof(tt));
  if (t) __builtin_memcpy(t,tt, sizeof(tt));
  return t;
}
```

I am not 100% sure if it is worth it either.

[Bug tree-optimization/120979] Missed strdup to malloc + memcpy for known strings

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Note xstrdup  is not the same as strdup ...
> 
> ```
> char *a()
> {
>   return __builtin_strdump ("");

Sorry typo, __builtin_strdup.

> }
> ```
> 
> Would need to be changed into:
> ```
> char *a()
> {
>   const char tt[] = "";
>   char *t = __builtin_malloc(sizeof(tt));
>   if (t) __builtin_memcpy(t,tt, sizeof(tt));
>   return t;
> }
> ```
> 
> I am not 100% sure if it is worth it either.

[Bug tree-optimization/120979] Missed strdup to malloc + memcpy for known strings

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

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

--- Comment #3 from Andrew Pinski  ---
Also as I mentioned xstrdup is not linked at all to the normal strdup (it is a
wrapper around strdup which will error out [and exit] if strdup returns NULL).

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #17 from Peter Bergner  ---
(In reply to Xi Ruoyao from comment #15)
> The problem is operand 4 does not have "0", and it's also assigned the hard
> register r23.  It's fine for operand 0 and 1 to be the same, also for
> operand 1 and 4 to be the same, but operand 0 and 4 cannot be same.  Thus
> this combine breaks the code.

The reason operands 0, 1 and 4 all use the register r23, is that each operand
is using the same pseudo, coming from variable "x", which is a user defined
hard register:

   register long x asm ("s0");

It does seem wrong that combine succeeded in combining those patterns, but as
Segher mentioned, it's recog() that said it was "ok".



(In reply to Segher Boessenkool from comment #16)
> It is allowed by recog().  Most likely your pattern is incorrect, but it
> is not completely impossible there is something wrong in genrecog.cc --
> but that isn't combine either.

Does recog() not check for early clobber when run before RA?  Or does it assume
a pseudo cannot early clobber itself?

[Bug c/120978] Punctuators that contain # or %: are incorrectly rejected within attributes

[luigighiron at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Halalaluyafail3  ---
(In reply to Andrew Pinski from comment #6)
> Because otherwise it would mean:
> ```
> [[ignored(
> #)]]int main(){}
> ```
> 
> Would be invalid C while:
> ```
> [[ignored(#)]]int main(){}
> ```
> 
> Would be valid.  That is white space of a return would matter which I am not
> sure is the expected behavior at all.
The preprocessor is whitespace sensitive, so I don't see it as surprising. If
one wanted to write it on two lines like that they could define a macro NONE
like so:

#define NONE

Expanding this macro before the # would cause it to not be interpreted as a
directive.

> The way I read the standard is the following:
> during phase 4:
> Preprocessing directives are executed,
> 
> And it is invalid for `#` or the `##` operator to be outside of `the
> replacement list of a function-like macro,` as far as I can tell during
> phase 4.
This interpretation would forbid the hash_hash example that is in the standard.
Also, GCC doesn't diagnose #, ##, %:, and %:%: being used in other contexts
during preprocessing. For example when just preprocessing (-E) the original
example of [[ignored(##)]] does not generate any errors, the error only occurs
during compilation. If your interpretation is correct, shouldn't an error be
generated during preprocessing instead of compilation?

[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register

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

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

--- Comment #18 from Peter Bergner  ---
(In reply to Xi Ruoyao from comment #13)
> I'm almost sure this is causing
> gcc.target/loongarch/bitwise-shift-reassoc-clobber.c ICE in GCC 16:
> 
> bitwise-shift-reassoc-clobber.c:12:1: error: unable to generate reloads for
> impossible constraints:
>12 | }
>   | ^
> (insn 12 10 15 2 (set (reg/v:DI 23 $r23 [ x ])
> (sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23
> $r23 [ x ])
> (const_int 3 [0x3]))
> (const_int 2208 [0x8a0])) 0)
> (reg:SI 23 $r23 [ x ]
> "bitwise-shift-reassoc-clobber.c":11:7 272 {and_alsl_reversesi_extended}
>  (nil))
> 
> We get:
> 
> Trying 10 -> 12:
>10: r91:DI=sign_extend($r23:DI<<0x3&0x8a0#0+$r23:SI)
>   REG_DEAD $r23:DI
>12: $r23:DI=r91:DI
>   REG_DEAD r91:DI
> Successfully matched this instruction:
> (set (reg/v:DI 23 $r23 [ x ])
> (sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23 $r23
> [ x ])
> (const_int 3 [0x3]))
> (const_int 2208 [0x8a0])) 0)
> (reg:SI 23 $r23 [ x ]
> allowing combination of insns 10 and 12
> 
> which violates the earlyclobber in _alsl_reversesi_extended:
> 
>   [(set (match_operand:DI 0 "register_operand" "=&r")
> (sign_extend:DI
>   (plus:SI
> (subreg:SI
>   (any_bitwise:DI
> (ashift:DI
>   (match_operand:DI 1 "register_operand" "r0")
>   (match_operand:SI 2 "const_immalsl_operand" ""))
> (match_operand:DI 3 "const_int_operand" "i"))
>   0)
> (match_operand:SI 4 "register_operand" "r"]

So the error message is coming from this hunk in my patch:

+   /* Both the earlyclobber operand and conflicting operand
+  cannot both be user defined hard registers.  */
+   if (HARD_REGISTER_P (operand_reg[i])
+   && REG_USERVAR_P (operand_reg[i])
+   && operand_reg[j] != NULL_RTX
+   && HARD_REGISTER_P (operand_reg[j])
+   && REG_USERVAR_P (operand_reg[j]))
+ fatal_insn ("unable to generate reloads for "
+ "impossible constraints:", curr_insn);

...which I believe is correct.  As you said, operand 4 cannot use the same
register as the early clobber output operand 0, and this hunk is catching the
illegal usage.  That is a good thing.

[Bug tree-optimization/120980] New: Vectorizer introduces out-of-bounds memory access

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

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

Bug ID: 120980
   Summary: Vectorizer introduces out-of-bounds memory access
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vectorizer introduces out-of-bounds memory access for the function below
when compiled for AArch64 with  "-O3 -march=armv9.5-a -fno-strict-aliasing".

void foo(long *p1, long *p2) {
  for (int i = 0; i < 8; i++)
if (p1[i] != p2[i])
  __builtin_exit(0);
}

The vectorized code checks if p1 and p2 are 32-byte aligned, and in that case
processes 4 elements at a time:

  vect__4.19_93 = MEM  [(long int *)vectp_p1.17_91];
  vectp_p1.17_94 = vectp_p1.17_91 + 16;
  vect__4.20_95 = MEM  [(long int *)vectp_p1.17_94];
  vect__6.15_85 = MEM  [(long int *)vectp_p2.13_83];
  vectp_p2.13_86 = vectp_p2.13_83 + 16;
  vect__6.16_87 = MEM  [(long int *)vectp_p2.13_86];
  mask_patt_7.21_96 = vect__6.15_85 != vect__4.19_93;
  mask_patt_7.21_97 = vect__6.16_87 != vect__4.20_95;
  vexit_reduc_98 = mask_patt_7.21_97 | mask_patt_7.21_96;
  if (vexit_reduc_98 != { 0, 0 })
goto ; [5.50%]
  else
goto ; [94.50%]

The problem occurs if the input is smaller, such as
  long a1[8] = {0, 0, 0, 0, 0, 0, 0, 0};
  long a2[2] = {0, 1};
  foo(a1, a2);
This makes vect__6.16_87 be loaded from outside the array, which is harmless as
the bytes are within the same page, but it is invalid to do fully out-of-bounds
accesses according to the discussion in
https://gcc.gnu.org/pipermail/gcc/2025-April/245873.html
The IR would have been valid if the loads were done as one 4-element load
instead of two 2-element loads, as partly out-of-bounds accesses are valid.

[Bug tree-optimization/120981] New: Vectorizer introduces UB address calculation

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

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

Bug ID: 120981
   Summary: Vectorizer introduces UB address calculation
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vectorizer introduces an invalid address calculation for the function below
when compiled for AArch64 with "-O3 -march=armv9.5-a -fno-strict-aliasing".

void f(int n, int y, char *arr_2, char *arr_6) {
  for (int i = y; i < n; i++)
arr_6[i] = arr_6[i] ? (arr_2[i] ? 3 : 8) : 1;
}

The problem occurs when arr_6[i] is always 0. arr_2 does not in that case need
to be a valid pointer as it is not accessed, but the vectorized code must
performs the address calculation, and it is possible that the address
calculation overflows or results in 0, which both are UB.

The input to the vectorizer seems to correctly have worked around this in the
.LOOP_VECTORIZED code, where the address calculations are done by first casting
the pointer to unsigned long. But the vectorizer changes this to use pointer
arithmetic, which may trigger the UB.

[Bug tree-optimization/120982] New: Incorrect alignment after vectorization

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

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

Bug ID: 120982
   Summary: Incorrect alignment after vectorization
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vectorizer introduces incorrect alignment for the function below when
compiled for AArch64 with "-O3 -march=armv9.5-a -fno-strict-aliasing".

long a[1000];
int foo (int n)
{
  for (int i = 0; i < n; i++)
if (a[i] == 0)
  return 1;
  return 0;
}

The vectorized memory accesses look like
  vect__1.10_30 = MEM  [(long int *)vectp_a.8_28];
  vectp_a.8_31 = vectp_a.8_28 + 16;
  vect__1.11_32 = MEM  [(long int *)vectp_a.8_31];
where get_object_alignment returns that both have 32-byte alignment.