[Bug rtl-optimization/116028] [15 Regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Surya Kumari Jangala from comment #14)
> (In reply to Richard Earnshaw from comment #13)
> > (In reply to Surya Kumari Jangala from comment #3)
> > > The parameter register is
> > > saved in a volatile register which is saved on stack in the entry bb.
> > > Instead, if the volatile register is saved just before the call, then 
> > > shrink
> > > wrapping will happen.
> > 
> > /v on a register doesn't make it volatile.  It simply means that the
> > register refers to a variable declared in the source-code.  See
> > REG_USERVAR_P() in rtl.texi.
> 
> From the input RTL to the pro_and_epilogue pass (where shrink wrap happens),
> the parameter register r3 is copied to r9 which is then saved on stack. 'r9'
> is a volatile register on Power.

Oh I see there is some terminology issue here, volatile register usage by Surya
in the above means caller saved register and is not related to volatile RTL
flag (which was not being looked at).

[Bug fortran/118747] [15 Regression]: seg fault on accessing an elemental procedure dummy argument's deferred-length componeent

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords||wrong-code
   Target Milestone|--- |15.0

[Bug tree-optimization/118754] [15 Regression] FAIL: gcc.target/i386/pr106010-8c.c by r15-6807-g68326d5d1a593d

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #2 from Tamar Christina  ---
See PR118407

[Bug tree-optimization/118749] [15 regression] fontconfig miscompiled with -O3 -march=pentium4 on x86

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Target||i?86-*-*

--- Comment #3 from Richard Biener  ---
I will have a look.

[Bug fortran/118750] [14/15 Regression] ICE on associate with elemental function with polymorphic array actual argument

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |14.3
   Keywords||ice-on-valid-code

[Bug libstdc++/118701] [15 regression] abi_check FAILs on Solaris due to weak version

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:6b49883e62a1ecf01ffd78c4c20fa7af87f8ec4d

commit r15-7368-g6b49883e62a1ecf01ffd78c4c20fa7af87f8ec4d
Author: Rainer Orth 
Date:   Wed Feb 5 09:59:56 2025 +0100

libstdc++: Fix gnu.ver CXXABI_1.3.16 for Solaris [PR118701]

This patch

commit c6977f765838a5ca8d321d916221a7368622bdd9
Author: Andreas Schwab 
Date:   Tue Jan 21 23:50:15 2025 +0100

libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V

broke the libstdc++-abi/abi_check test on Solaris: the log shows

1 incompatible symbols
0
Argument "{CXXABI_1.3.15}" isn't numeric in numeric eq (==) at
/vol/gcc/src/hg/master/local/libstdc++-v3/scripts/extract_symvers.pl line 129.
version status: incompatible
type: uncategorized
status: added

The problem has two parts:

* The patch above introduced a new version in libstdc++.so,
  CXXABI_1.3.16, which everywhere but on RISC-V contains no symbols (a
  weak version).  This is the first time this happened in libstdc++.

* Solaris uses scripts/extract_symvers.pl to determine the version info.
  The script currently chokes on the pvs output for weak versions:

  libstdc++.so.6.0.34 - CXXABI_1.3.16 [WEAK]: {CXXABI_1.3.15};

  instead of

  libstdc++.so.6.0.34 - CXXABI_1.3.16: {CXXABI_1.3.15};

While this patch hardens the script to cope with weak versions, there's
no reason to introduce them in the first place.  So the new version is
only created on __riscv.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.

2025-01-29  Rainer Orth  
Jonathan Wakely  

libstdc++-v3:
PR libstdc++/118701
* config/abi/pre/gnu.ver (CXXABI_1.3.16): Move __riscv guard
around version.
* scripts/extract_symvers.pl: Allow for weak versions.
* testsuite/util/testsuite_abi.cc (check_version): Wrap
CXXABI_1.3.16 in __riscv.

[Bug c/118756] tree-ssa-loop-ivopts.cc:1156: Function defined but not used

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

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

--- Comment #2 from Tamar Christina  ---
Ah, indeed it's unused now.

I'll send a cleanup patch then.  Thanks for catching it!

[Bug libstdc++/118701] [15 regression] abi_check FAILs on Solaris due to weak version

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #9 from Rainer Orth  ---
Fixed for GCC 15.

[Bug c/118756] tree-ssa-loop-ivopts.cc:1156: Function defined but not used

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Its last non-self-recursive use went away in
r15-6657-g405c99c17210a58df1a237219e773e689f17

[Bug rtl-optimization/118755] New: [15 Regression] ccmp_3.c fails on aarch64

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

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

Bug ID: 118755
   Summary: [15 Regression] ccmp_3.c fails on aarch64
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization, testsuite-fail
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

FAIL: gcc.target/aarch64/ccmp_3.c scan-assembler-not \tcbnz\t

This one is not recorded and it is different from the other issues that were
caused by the fix from PR 101523.

The IR before combine:
```
(insn 11 8 13 2 (set (reg:SI 108)
(eq:SI (reg:CC 66 cc)
(const_int 0 [0]))) "/app/example.cpp":7:18 443 {aarch64_cstoresi}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(nil)))
(insn 13 11 15 2 (set (reg/v:SI 104 [  ])
(zero_extend:SI (subreg:QI (reg:SI 108) 0))) "/app/example.cpp":7:18
114 {*zero_extendqisi2_aarch64}
 (expr_list:REG_DEAD (reg:SI 108)
(nil)))
(insn 15 13 16 2 (set (reg:SI 109)
(and:SI (reg/v:SI 104 [  ])
(const_int 1 [0x1]))) "/app/example.cpp":8:6 504 {andsi3}
 (nil))
(insn 16 15 17 2 (set (reg:CC 66 cc)
(compare:CC (reg:SI 109)
(const_int 0 [0]))) "/app/example.cpp":8:6 405 {cmpsi}
 (expr_list:REG_DEAD (reg:SI 109)
(nil)))
```

Notice 109 is used again later on for the return value.


The testcase:
```
void foo(void);
int f1(int a, int b)
{
  int c = a == 0 || b == 0;
  if (c) foo();
  return c;
}
```

One thing to note here is that the trunk does shrink wrap now too.

[Bug tree-optimization/118749] [15 regression] fontconfig miscompiled with -O3 -march=pentium4 on x86

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

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

--- Comment #4 from Richard Biener  ---
We are wrongly figuring the vectorized *string access is aligned.  We apply
peeling for alignment here, but the vector loop does not maintain the
initial alignment, instead it accesses a V16QI, only effectively using
V8QI and increments the pointer by 8 elements.

  vect__2.17_108 = MEM  [(FcChar8
*)vectp_string.15_106];
  vect__2.18_110 = VEC_PERM_EXPR ;
...

this is because we vectorize a SLP reduction (but high/low are reductions),
so we get

t.c:16:18: note:   node 0x41737490 (max_nunits=16, refcnt=2) vector(16)
unsigned char
t.c:16:18: note:   op template: _2 = *string_26;
t.c:16:18: note:stmt 0 _2 = *string_26;
t.c:16:18: note:stmt 1 _2 = *string_26;
t.c:16:18: note:load permutation { 0 0 }

and the bug is that we think we can apply peeling for alignment for this
access with a VF of just 8.  When we then set the known misalignment to zero
with a target alignment of 16 bytes that's when things go downhill.

Testing a patch.

[Bug tree-optimization/118754] [15 Regression] FAIL: gcc.target/i386/pr106010-8c.c by r15-6807-g68326d5d1a593d

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

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

--- Comment #3 from Tamar Christina  ---
As for vect-tail-nomask-1.c and pr106010-8c.c they are testisms that I had
fixed but it seems like I never updated the final patch with.

The result checking loops just need a
#pragma GCC novector.

Will submit.

[Bug c/118756] New: tree-ssa-loop-ivopts.cc:1156: Function defined but not used

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 118756
   Summary: tree-ssa-loop-ivopts.cc:1156: Function defined but not
used
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Clang says:

gcc/tree-ssa-loop-ivopts.cc:1156:1: warning: function
'contain_complex_addr_expr' is not needed and will not be emitted
[-Wunneeded-internal-declaration]

Source code is

static bool
contain_complex_addr_expr (tree expr)
{

Also:

working $ grep contain_complex_addr_expr ../trunk/gcc/tree-ssa-loop-ivopts.cc
contain_complex_addr_expr (tree expr)
  res |= contain_complex_addr_expr (TREE_OPERAND (expr, 0));
  res |= contain_complex_addr_expr (TREE_OPERAND (expr, 1));
working $ 

Suggest remove function.

[Bug tree-optimization/118727] [15 Regression] gcc.dg/pr108692.c fails on LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #20 from Xi Ruoyao  ---
Fixed for trunk.  Not backporting as there were no targets affected in 14.

[Bug c++/86769] [12/13/14/15 Regression] g++ destroys condition variable in for statement too early

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #60377|0   |1
is obsolete||

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

There were some regressions caused by that patch, this patch ought to fix that
and further extend test coverage.  Still need to bootstrap/regtest it again.

[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095

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

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

--- Comment #12 from Robin Dapp  ---
Some "findings" below but I don't have the feeling I'm much closer to anything
actionable.

At some point we're trying to split a live range of an RVVM8QI register (v16,
hard regno = 112) for the reload insn

(insn 93 169 123 2 (set (reg:RVVM8QI 169 [orig:135 _4 ] [135])
(reg:RVVM8QI 241 [orig:135 _4 ] [135])) "pr115458.c":48:33 2726
{*movrvvm8qi_whole}
 (nil))

In split_reg we have
  mode = RVVM8QI
but
  machine_mode reg_rtx_mode = GET_MODE (regno_reg_rtx[hard_regno]);

However reg_raw_mode[112] = RVVM1SF so
  reg_rtx_mode = RVVM1SF.

As an RVVM8QI access to RVVM1SF constitutes a paradoxical subreg we change the
mode to RVVM1SF and eventually create a spill/save

(insn 174 0 0 (set (reg:RVVM1SF 247)
(reg:RVVM1SF 112 v16)) -1
 (nil))

This happens for all hard regs of RVVM8QI individually (v16 - v23), same for
the restore of course.

As a data point: When prohibiting this mode change and just keeping RVVM8QI we
compile successfully and we barely need to reload at all.

However, reg_rtx_mode[112] = RVVM1SF without the vector ABI so, while odd, it's
not the real culprit.

[Bug target/118089] [12/13/14/15 regression] arm thumb2 return sequence is suboptimal, especially at -O2

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:5163cf2ae14c5e7ec730ad72680564001d0d0441

commit r15-7373-g5163cf2ae14c5e7ec730ad72680564001d0d0441
Author: Richard Earnshaw 
Date:   Thu Dec 19 16:00:48 2024 +

arm: Use POP {pc} to return when returning [PR118089]

When generating thumb2 code,
LDM SP!, {PC}
is a two-byte instruction, whereas
LDR PC, [SP], #4
is needs 4 bytes.  When optimizing for size, or when there's no obvious
performance benefit prefer the former.

gcc/ChangeLog:

PR target/118089
* config/arm/arm.cc (thumb2_expand_return): Use LDM SP!, {PC}
when optimizing for size, or when there's no performance benefit
over
LDR PC, [SP], #4.
(arm_expand_epilogue): Likewise.

[Bug target/116589] [15 regression] vectorization regressions on aarch64 since r15-1575-gea8061f46a30

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

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

--- Comment #8 from Andrew Pinski  ---
r15-7377 fixed ldff1_8.c and ptest_1.c failures.

So what is left is vec_bool_cmp_1.c .

[Bug rtl-optimization/114522] [15 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a

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

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

--- Comment #10 from Andrew Pinski  ---
aarch64 patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675160.html

[Bug target/116589] [15 regression] vectorization regressions on aarch64 since r15-1575-gea8061f46a30

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Actually vec_bool_cmp_1.c was fixed also by r15-7377 .

So all fixed.

[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

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

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

--- Comment #22 from John David Anglin  ---
Actually, it appears the multiplication by 0.25 can be avoided by
setting w directly.

[Bug libstdc++/118757] New: Waiting for stored pointer inside std::atomic>

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 118757
   Summary: Waiting for stored pointer inside
std::atomic>
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

According to https://devblogs.microsoft.com/oldnewthing/20250109-00/?p=110738
the following C++20 program
```
#include 
#include 
#include 

std::shared_ptr q = std::make_shared(42);
std::atomic> p = q;

void signaler()
{
std::this_thread::sleep_for(std::chrono::seconds(1));
p.store({ q, nullptr });
p.notify_one();
std::this_thread::sleep_for(std::chrono::seconds(1));
std::terminate();
}

int main(int, char**)
{
std::thread(signaler).detach();
p.wait(q);
return 0;
}
```
must finish gracefully by return 0; and not by std::terminate, because
p.wait(q) must stop immediately after p.store({ q, nullptr }); p.notify_one();

Online demo: https://gcc.godbolt.org/z/hqG5T8469

[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

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

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

--- Comment #23 from Joseph S. Myers  ---
hppa is an after-rounding architecture and this test is only meant to produce
underflow on before-rounding architectures. You should investigate why the code
in question is entered at all. I'd have expected

  /* If the exponent would be in the normal range when
 rounding to normal precision with unbounded exponent
 range, the exact result is known and spurious underflows
 must be avoided on systems detecting tininess after
 rounding.  */
  if (TININESS_AFTER_ROUNDING)
{
  w.d = a1 + u.d;
  if (w.ieee.exponent == 109)
return w.d * 0x1p-108;
}

to have dealt with this case.

[Bug rtl-optimization/118755] [15 Regression] ccmp_3.c fails on aarch64

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> I think the first thing we could do is (from fwprop1):
> ```
> propagating insn 13 into insn 14, replacing:
> (set (reg:SI 103 [ _3 ])
> (reg/v:SI 104 [  ]))
> successfully matched this instruction to *zero_extendqisi2_aarch64:
> (set (reg:SI 103 [ _3 ])
> (zero_extend:SI (subreg:QI (reg:SI 108) 0)))
> original cost = 4 (weighted: 4.00), replacement cost = 4 (weighted:
> 4.00); rejecting replacement
> change not profitable
> propagating insn 13 into insn 15, replacing:
> (set (reg:SI 109)
> (and:SI (reg/v:SI 104 [  ])
> (const_int 1 [0x1])))
> failed to match this instruction:
> (set (reg:SI 109)
> (zero_extend:SI (and:QI (subreg:QI (reg:SI 108) 0)
> (const_int 1 [0x1]
> ```
> That should just be simplified to:
> (set (reg:SI 109) (and:SI (reg:SI 108) (const_int 1 [0x1])))
> 
> Though I am not sure this will fix everything.

It does not fix it but it is still a good thing to do.

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

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

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

--- Comment #5 from Sam James  ---
Then sometimes once cvise has cleaned up a bunch of crap, it's often obvious
what the problem is, but if not, I let it run to completion. Anyway, I'll
continue reducing here, of course.

[Bug libstdc++/118757] Waiting for stored pointer inside std::atomic>

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
There's no such requirement in the standard, it's perfectly valid for p.wait(q)
to take more than a second to wake up.

But the bug is real, we fail to wake up at all.

Here's a version that the standard requires to exit normally, without assuming
p.wait(q) executes in less than a second:

#include 
#include 
#include 
#include 

std::shared_ptr q = std::make_shared(42);
std::atomic> p = q;

std::barrier bar(2);

void signaler()
{
std::this_thread::sleep_for(std::chrono::seconds(1));
p.store({ q, nullptr });
p.notify_one();
bar.arrive_and_wait();
}

int main(int, char**)
{
std::thread thr(signaler);
p.wait(q);
bar.arrive_and_wait();
thr.join();
}

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to David Binderman from comment #2)
> I will look into a bisection.

The problem seems to exist sometime before 20241231 with g:0b06abe027a78681

[Bug c++/118752] clang::no_sanitize scopped attribute should be an alias to gnu::no_sanitize

[ndesaulniers at google dot com via Gcc-bugs]

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

--- Comment #1 from Nick Desaulniers  ---
Perhaps clang::no_stack_protector, too. Thanks.

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

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

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

--- Comment #1 from Sam James  ---
Reducing.

[Bug c++/118760] New: Alias template in dependent base used via injected-class-name incorrectly rejected

[herring at lanl dot gov via Gcc-bugs]

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

Bug ID: 118760
   Summary: Alias template in dependent base used via
injected-class-name incorrectly rejected
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

GCC trunk rejects

template
struct base {
  template using id=T;
};
template
struct derived : base {
  typename derived::/*template*/ id i;
};
derived<1> x;

complaining that the type of derived<1>::i is not a class type.  This is true,
of course, but hardly an error.  (The commented-out template is for Clang
comparison; it was rendered unnecessary by CWG1710, but Clang still erroneously
requires it.)

[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

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

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

--- Comment #24 from Joseph S. Myers  ---
See my previous comment about possible code movement / need for more usage of
math_opt_barrier. Maybe the a1 + u.d computation got moved before the rounding
mode was restored, or something like that?

[Bug c/118758] New: [15 regression] ok code with -O2, but wrong code with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 118758
   Summary: [15 regression] ok code with -O2, but wrong code with
-O3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code, with recent gcc:

foundBugs $ rm -f ./a.out ; ~/gcc/results/bin/gcc -w -O2 bug1086.c && ./a.out
checksum = E0BB38EE
foundBugs $ rm -f ./a.out ; ~/gcc/results/bin/gcc -w -O3 bug1086.c && ./a.out
checksum = 3489BDAF
foundBugs $ rm -f ./a.out ; ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
bug1086.c && ./a.out
checksum = 3489BDAF
foundBugs $ rm -f ./a.out ; ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange bug1086.c && ./a.out
checksum = 3489BDAF
foundBugs $ 

For stock gcc 14.2.0:

foundBugs $ rm -f ./a.out ; ~/gcc/results.14.2.0/bin/gcc -w -O2 bug1086.c &&
./a.out
checksum = E0BB38EE
foundBugs $ rm -f ./a.out ; ~/gcc/results.14.2.0/bin/gcc -w -O3 bug1086.c &&
./a.out
checksum = E0BB38EE
foundBugs $ 

So this looks like a 15 regression.
For the earliest gcc trunk I have:

foundBugs $ rm -f ./a.out ; ~/gcc/results.20250107.asan.ubsan/bin/gcc -w -O2
bug1086.c && ./a.out
checksum = E0BB38EE
foundBugs $ rm -f ./a.out ; ~/gcc/results.20250107.asan.ubsan/bin/gcc -w -O3
bug1086.c && ./a.out
checksum = 3489BDAF
foundBugs $ 

so it looks like the bug appears sometime before g:aa688dd6302fd9fd

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
The original code is from csmith, so:

foundBugs $ rm ./a.out && ../results/bin/gcc -w bug1086.c && ./a.out 1 > /tmp/0
foundBugs $ rm ./a.out && ../results/bin/gcc -w -O1 bug1086.c && ./a.out 1 >
/tmp/1
foundBugs $ rm ./a.out && ../results/bin/gcc -w -O2 bug1086.c && ./a.out 1 >
/tmp/2
foundBugs $ rm ./a.out && ../results/bin/gcc -w -O3 bug1086.c && ./a.out 1 >
/tmp/3
foundBugs $ diff /tmp/0 /tmp/1 | head
foundBugs $ diff  /tmp/1 /tmp/2 | head
foundBugs $ diff   /tmp/2 /tmp/3 | head -20
22,31c22,31
< ...checksum after hashing g_96 : AC52A137
< ...checksum after hashing g_112 : 76BB478C
< ...checksum after hashing g_115 : E702AF55
< ...checksum after hashing g_120 : D2913B16
< ...checksum after hashing g_122 : 509DFFB2
< ...checksum after hashing g_123 : 3C438752
< ...checksum after hashing g_126 : 2EE87DAF
< ...checksum after hashing g_159.f1 : CCF3889D
< ...checksum after hashing g_171.f0 : D5BDB4B1
< ...checksum after hashing g_174[i] : 8639214
---
> ...checksum after hashing g_96 : A3A5FF7D
> ...checksum after hashing g_112 : 37CBB533
> ...checksum after hashing g_115 : 75843C96
> ...checksum after hashing g_120 : 9BB794D6
> ...checksum after hashing g_122 : 1FCEC711
> ...checksum after hashing g_123 : D3B439C9
> ...checksum after hashing g_126 : 8E5B985A
> ...checksum after hashing g_159.f1 : C699E54E
foundBugs $

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #4 from Sam James  ---
In case it's useful for you David, what I do (in addition to the script I gave
you before), is something like:

# Figure out where the first difference is
$ diff -u <(gcc-14 test.c -o test -O3 && ./test 1) <(gcc-15 test.c -o test2 -O3
&& ./test2 1)

# Patch in an abort on that first difference to allow cvise to kill as much as
possible
```
--- a/pr118758.c
+++ b/pr118758.c
@@ -3967,6 +3967,9 @@
 transparent_crc (uint64_t val, char* vname, int flag)
 {
  crc32_8bytes(val);
+  if (strcmp(vname, "g_96") == 0 && (crc32_context ^ 0xUL) !=
0xAC52A137)
+__builtin_abort();
+
  if (flag) {
 printf("...checksum after hashing %s : %lX\n", vname, crc32_context ^
0xUL);
  }
```

then cvise with a bunch of sanitizer + warning checks and so on to make sure it
only dies with 15 and not 14.

[Bug ipa/118097] [15 regression] recent bug with -O2, but not -O1 since r15-6294-g96fb71883d438b

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

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

--- Comment #35 from Andrew Pinski  ---
Created attachment 60388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60388&action=edit
Better reduced testcase from PR 118758

This one is slightly better than the one in comment #26 .

[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

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

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

--- Comment #26 from John David Anglin  ---
(In reply to Joseph S. Myers from comment #23)
> hppa is an after-rounding architecture and this test is only meant to
> produce underflow on before-rounding architectures. You should investigate
> why the code in question is entered at all. I'd have expected
> 
>   /* If the exponent would be in the normal range when
>  rounding to normal precision with unbounded exponent
>  range, the exact result is known and spurious underflows
>  must be avoided on systems detecting tininess after
>  rounding.  */
>   if (TININESS_AFTER_ROUNDING)
> {
>   w.d = a1 + u.d;
>   if (w.ieee.exponent == 109)
> return w.d * 0x1p-108;
> }

The return in the above hunk isn't taken because the exponent calculated
for "a1 + u.d" is 108.

Note: The "w.d = a1 + u.d;" line seems redundant as "a1 + u.d" is
previously calculated in this hunk:

  if (__glibc_unlikely (adjust < 0))
{
  if ((u.ieee.mantissa1 & 1) == 0)
u.ieee.mantissa1 |= libc_fetestexcept (FE_INEXACT) != 0;
  v.d = a1 + u.d;
  /* Ensure the addition is not scheduled after fetestexcept call.  */
  math_force_eval (v.d);
}

adjust = -1

Should we just return "v.d * 0x1p-108" when TININESS_AFTER_ROUNDING is true?

[Bug tree-optimization/118727] [15 Regression] gcc.dg/pr108692.c fails on LoongArch

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

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

--- Comment #19 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r15-7370-gda88e7027a34a44de84f6d8d5a96d262c29080a7
Author: Xi Ruoyao 
Date:   Sun Feb 2 21:22:36 2025 +0800

vect: Fix wrong code with pr108692.c on targets with only non-widening ABD
[PR118727]

With things like

  // signed char a_14, a_16;
  a.0_4 = (unsigned char) a_14;
  _5 = (int) a.0_4;
  b.1_6 = (unsigned char) b_16;
  _7 = (int) b.1_6;
  c_17 = _5 - _7;
  _8 = ABS_EXPR ;
  r_18 = _8 + r_23;

An ABD pattern will be recognized for _8:

  patt_31 = .ABD (a.0_4, b.1_6);

It's still correct.  But then when the SAD pattern is recognized:

  patt_29 = SAD_EXPR ;

This is not correct.  This only happens for targets with both uabd and
sabd but not vec_widen_{s,u}abd, currently LoongArch is the only target
affected.

The problem is vect_look_through_possible_promotion will throw away a
series of conversions if the effect is equivalent to a sign change and a
promotion, but here the sign change is definitely relevant, and the
promotion is also relevant for "mixed sign" cases like
r += abs((unsigned int)(unsigned char) a - (signed int)(signed char) b
(we need to promote to HImode as the difference can exceed the range of
QImode).

If there were any redundant promotion, it should have been stripped in
vect_recog_abd_pattern (i.e. when patt_31 = .ABD (a.0_4, b.1_6) is
recognized) instead of in vect_recog_sad_pattern, or we'd have a
missed-optimization if the ABD output is not summerized.  So anyway
vect_recog_sad_pattern is just not a proper location to call
vect_look_through_possible_promotion for the ABD inputs, remove the
calls to fix the issue.

gcc/ChangeLog:

PR tree-optimization/118727
* tree-vect-patterns.cc (vect_recog_sad_pattern): Don't call
vect_look_through_possible_promotion on ABD inputs.

gcc/testsuite/ChangeLog:

PR tree-optimization/118727
* gcc.dg/pr108692.c: Mention PR 118727 in the comment.
* gcc.dg/pr118727.c: New test case.

[Bug rtl-optimization/118739] [15 Regression] wrong code at -O{s,3} with "-fno-tree-forwprop -fno-tree-vrp" on x86_64-linux-gnu since r15-268-g9dbff9c05520a7

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

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

--- Comment #13 from Richard Biener  ---
So indeed the bisected revision just restored a previous change which was
originally done by Segher, r14-9692-g839bc42772ba7a, not sure if the issue
would reproduce between that and the initial reversion in
r14-9885-g109f1b28fc94c9

I don't know much of combines CCmode handling nor of CC vs CCNO to be of
any help here, but it does look like a genuine combine issue.

[Bug rtl-optimization/118755] [15 Regression] ccmp_3.c fails on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I am going to take a look at this tomorrow. I suspect there is a missing
simplification in simplify-rtx for STORE_FLAG_VALUE==1.

[Bug middle-end/108016] RISC-V：Bad codegen in scalar code comparing to LLVM

[alexey.merzlyakov at samsung dot com via Gcc-bugs]

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

Alexey Merzlyakov  changed:

   What|Removed |Added

 CC||alexey.merzlyakov at samsung 
dot c
   ||om

--- Comment #4 from Alexey Merzlyakov  ---
I suspect, there might be 3 items are related to the reported in this ticket
case.

=== Item1 ===

This is related to the above analysis provided by Jeff, where the unnecessary
stack store-load generated.
The simplified C-testcase:

  struct value {
unsigned int a;
unsigned char b;
  };

  struct value func(unsigned int a, unsigned int b) {
struct value out;
out.a = a;
out.b = a > b;
return out;
  }

Here I am just wondering, even if the optimized tree has is going through the
memory, why DSE is not optimizing-out unnecessary store-load chain to something
like:

  (insn 16 14 17 2 (set (mem/c:QI (plus:DI (reg/f:DI 65 frame)
(const_int -4 [0xfffc])))
(subreg:QI (reg:DI 140) 0))
  (insn 27 21 28 2 (set (reg:DI 148 [ D.2377+4 ])
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 65 frame)
(const_int -4 [0xfffc])
  ->
  (insn 41 14 17 2 (set (reg:DI 154) (reg:DI 140)))
  (insn 27 21 28 2 (set (reg:DI 148 [ D.2377+4 ])
(zero_extend:DI (subreg/s/u:QI (reg:QI 154) 0))) ?

At least in the testcase from above, it does similar optimization for another
store-load [sp-0x8] chain.

=== Item2 ===

Even if get rid from unnecessary store-load generation, the stack is still
being allocated for the func frame. Assembler, generated for the following
test-case, contains unnecessary stack allocation in prologue/epilogue (thanks
to my colleague, Ankit Mahato for supporting with the reduced testcase on this
situation):

  struct value {
unsigned int a;
unsigned int b;
  };

  struct value func(void) {
struct value out;
out.a = 0;
out.b = 1;
return out;
  }

Here is as in previous case, tree-optimized dump containing MEM usage. However,
for this test-case further memory store-load was optimized-out by DSE1, and
function stack won't contain locals on it anymore. But GCC is still generating
unnecessary stack allocation:

  func():
addisp,sp,-16
li  a0,1
sllia0,a0,32
addisp,sp,16
jr  ra

I looks like that frame size once being calculated in expand-rtl, will never
being changed. Even after DSE removed all unnecessary stack usage, stack offset
value was not corrected. I suppose that DSE if changes the usage of stack (for
some reasons), could it correct the "frame_offset" value, that is responsible
for further SP size allocation in pro_and_epilogue.

For that, I've added simple and ugly "frame_offset" value optimizing-out
function (checking no insns contain RTX_FRAME) to the end of DSE optimization;
and it works for me on the above test-case.

The main question here - should GCC change frame size after RTX was expanded;
or it is not intended to work like this?

=== Item3 ===

Generation of extra sext.w instruction does not seem to be related to the
previous items.
The following test-case contains ADD_OVERFLOW built-in function:

  unsigned int func(unsigned int a, unsigned int b) {
unsigned int out;
unsigned int overflow = __builtin_add_overflow(a, b, &out);
return overflow & out;
  }

It produces an extra sign_extend, whether LLVM does not:

  func(unsigned int, unsigned int):
addwa1,a0,a1
sext.w  a5,a1
sltua0,a5,a0
and a0,a0,a1
ret

The riscv.md > uaddv4 implementation contains "riscv_emit_binary (PLUS,
operands[0], operands[1], operands[2])" which produces the sum of two values in
SI-mode:

  (insn 11 10 12 (set (reg:SI 141)
(plus:SI (subreg/s/u:SI (reg/v:DI 139 [ a ]) 0)
(subreg/s/u:SI (reg/v:DI 140 [ b ]) 0)))

Sign-extend for this is being made separately by calling "emit_insn
(gen_extend_insn (t4, operands[0], DImode, SImode, 0))":

  (insn 12 11 13 (set (reg:DI 143)
(sign_extend:DI (reg:SI 141)))

(a+b) sum in DI-mode is used for expansion of conditional branch:

  (jump_insn 13 12 14 (set (pc)
(if_then_else (ltu (reg:DI 143 [a + b])
(reg:DI 142 [a]))
(label_ref 16)
(pc)))

while the output from the "uaddv4" - operand[0] == (a+b):SI is used
further in the code.

It appears that instructions generation, made in such way can not be optimized
out by further fwprop, crprop, combine, etc... pipeline; because of
extra-dependency outside it PLUS-SIGN_EXTEND chain. Thus, sext.w remains to be
untouched.

However, if change "riscv_emit_binary (PLUS, operands[0], operands[1],
operands[2]);" routine in the "uaddv4" -> to something producing results
in DI-mode, say "emit_insn (gen_add3_insn (operands[0], operands[

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I will look into a bisection.

[Bug c++/118760] [12/13/14/15 Regression] Alias template in dependent base used via injected-class-name incorrectly rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||11.3.0, 11.4.0, 5.4.0,
   ||7.5.0
   Target Milestone|--- |12.5
  Known to fail||12.1.0, 12.3.0, 13.3.0,
   ||14.2.0
Summary|Alias template in dependent |[12/13/14/15 Regression]
   |base used via   |Alias template in dependent
   |injected-class-name |base used via
   |incorrectly rejected|injected-class-name
   ||incorrectly rejected

[Bug c++/118760] [12/13/14/15 Regression] Alias template in dependent base used via injected-class-name incorrectly rejected

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

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

--- Comment #2 from Andrew Pinski  ---
Looks like we are losing that `typename` was used here:
if (TREE_CODE (f) != TYPENAME_TYPE)

[Bug modula2/118761] New: gm2 driver doesn't behave as gcc for --help=BLA

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

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

Bug ID: 118761
   Summary: gm2 driver doesn't behave as gcc for --help=BLA
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

$ gm2 -fsyntax-only --help=optimizers
gm2: fatal error: no input files
compilation terminated.

But gcc gives:

$ gcc -fsyntax-only --help=optimizers
The following options control optimizations:
  -O  Set optimization level to .
  -Ofast  Optimize for speed disregarding exact standards
compliance.

...

Other frontends (gccrs, gfortran, g++, gdc, gccgo) behaves all like gcc.

(ga68, the to-be-merged algol68 has the same issue).

[Bug modula2/118761] gm2 driver doesn't behave as gcc for --help=BLA

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

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

--- Comment #1 from Marc Poulhiès  ---
(same inconsistent behavior with "--help --verbose")

[Bug tree-optimization/118759] [15 regression] ICE when building openmsx-19.1 (exact_div, at poly-int.h:2160)

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #4 from Sam James  ---
Calling it a dupe.

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

[Bug tree-optimization/118464] [15 Regression] gcc-15.0.0_pre20250112 ICE with opencv-4.10.0 using -O2/-ftree-loop-vectorize: memory_descriptor_ref.cpp:94:19: internal compiler error: in exact_div, at

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

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

--- Comment #12 from Sam James  ---
*** Bug 118759 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails

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

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

--- Comment #4 from Andrew Pinski  ---
Part of the reason why late_combine1 fails to do anything here is:
```
  // Avoid increasing the complexity of instructions that
  // reference allocatable hard registers.
  if (!REG_P (SET_SRC (set))
  && !reload_completed
  && (accesses_include_nonfixed_hard_registers (use_insn->uses ())
  || accesses_include_nonfixed_hard_registers (use_insn->defs (
return false;
```

The `accesses_include_nonfixed_hard_registers (use_insn->defs ())` part
specifically. Though I am no sure if that is too conserative.

Anyways there is some missing recog here too.


Also note the code generation is worse if you have:
```
void shift_53_i_(int data, __int128_t *a) {
*a = (__int128_t)data << 53;
}

```

(GCC 15 is only slightly worse than GCC 14 for the above).

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 regression] std::vector |[15 regression] std::vector
   |Wstringop-overflow false|Wstringop-overflow false
   |positive|positive since r15-4473

--- Comment #6 from Andrew Pinski  ---
r15-4473-g3abe751ea86e34

[Bug c++/118763] [12/13/14/15 regression] memory leak involving early return from statement expressions

[valentin at tolmer dot fr via Gcc-bugs]

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

--- Comment #1 from Valentin Tolmer  ---
Potentially related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113579
Though in this case, I'm pretty sure according to the docs, it's not undefined
behavior.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

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

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

Sam James  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||uecker at gcc dot gnu.org
   Keywords||rejects-valid

--- Comment #1 from Sam James  ---
It's better with trunk but some still fail.

[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

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

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

--- Comment #27 from Joseph S. Myers  ---
That's not redundant, the previous calculation is in FE_TOWARDZERO mode, before
the call to libc_feupdateenv_test. But maybe that call needs to be followed by
"a1 = math_opt_barrier (a1);" or similar to ensure the value doesn't get
wrongly reused in the new rounding mode. With a value calculated in the correct
rounding mode, the exponent should be 109, not 108.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---
Note that rules for unions were changed after N3037.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

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

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

--- Comment #4 from Sam James  ---
You're right - I used a mangled version of the testcase when playing, sorry!

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

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

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

--- Comment #5 from Joseph S. Myers  ---
What do you mean by "doesn't work"? Please state both what you expect (based on
C23 with bug fixes that postdate the integration of the original proposal) and
what you see. As per CD1 comments GB-032 and FR-107 (see N3108 for CD1 ballot
resolutions), multiple declarations of a union with members in a different
order can't work with initialization, so in final C23 it's not allowed.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

[himehaieto at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hime Haieto  ---
Odd - I don't see any difference on trunk other than the addition of a helpful
note message (nice!).  However, I'm testing trunk via godbolt, so I don't know
if its trunk might be slightly older.

[Bug c/118765] New: c23 tag matching broken for multiple redeclarations of unions and typedefs

[himehaieto at gmail dot com via Gcc-bugs]

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

Bug ID: 118765
   Summary: c23 tag matching broken for multiple redeclarations of
unions and typedefs
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: himehaieto at gmail dot com
  Target Milestone: ---

Created attachment 60389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60389&action=edit
tag-matching-bugs.i

When reproducing the exact examples from n3037 (example 3), I found a couple
issues.  The first is that the union example doesn't work at all when using
multiple declarations with the same members but written in a different order. 
The second is that two declarations of the a typedef works, but a third (or
fourth) breaks.  Tested with gcc 14.2.1 and -std=c23.

See the attached code for a reproducer, though note that it was specifically
unminimised so as to reproduce all the examples from n3037, and to test each
one at least a third time since it was noted it could still break after the
first redeclaration.

[Bug fortran/116829] Missing default initialization of finalizable non-polymorphic intent(out) arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2025-02-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  All versions since at least gcc-7 fail.

With finalization commented out, I see:

void makeaap (struct aaptype & restrict a)
{
  {
struct aaptype aaptype.2;

aaptype.2.i = 0;
*a = aaptype.2;
  }

as it should, but the original testcase has:

void makeaap (struct aaptype & restrict a)
{
  {
struct array00_aaptype desc.6;

desc.6.dtype = {.elem_len=4, .version=0, .rank=0, .type=5};
desc.6.data = (void * restrict) a;
desc.6.span = (integer(kind=8)) desc.6.dtype.elem_len;
__final_m_Aaptype (&desc.6, 4, 0);
  }

Clearly wrong.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60390|0   |1
is obsolete||

--- Comment #7 from Andrew Pinski  ---
Created attachment 60391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60391&action=edit
The non union case

Since the union case is supposed to be rejected, this is only typedef case.

[Bug fortran/118747] [15 Regression]: seg fault on accessing an elemental procedure dummy argument's deferred-length componeent

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
The issue in comment#2 is fixed by the following - I'd say obvious - patch:

diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 017f184f179..81fa8756a91 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -8144,7 +8144,7 @@ gfc_generate_function_code (gfc_namespace * ns)
   : gfc_generate_initializer (&rsym->ts,
true);
  if (init_exp)
{
- tmp = gfc_trans_structure_assign (result, init_exp, 0);
+ tmp = gfc_trans_structure_assign (result, init_exp, true);
  gfc_free_expr (init_exp);
  gfc_add_expr_to_block (&init, tmp);
}

This turns the broken initialization of the allocatable, fixed-length
character component of the function result into a regular one, also
confirmed by valgrind.

[Bug c++/118766] New: Garbled error message in vararg requires

[sandberg.sven at gmail dot com via Gcc-bugs]

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

Bug ID: 118766
   Summary: Garbled error message in vararg requires
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandberg.sven at gmail dot com
  Target Milestone: ---

The following program produces an error message that appears garbled (see also
https://godbolt.org/z/vxTa73d14). Note that I am not questioning that this code
is wrong (clang agrees that it is), only suggesting that the message should be
more clear.

```
template 
requires requires (const Args_t &... a) { f(a...); }
void g(const Args_t &... arg) {}

int main() {
g();
return 0;
}
```

The error message, up to the garbled line, is:

```
In function 'int main()':
:6:6: error: no matching function for call to 'g(const char [1])'
6 | g("");
  | ~^~~~
:6:6: note: there is 1 candidate
:3:6: note: candidate 1: 'template  requires
requires('type_pack_expansion' not supported by simple_type_specifier...
a'type_pack_expansion' not supported by direct_abstract_declarator) {f(a ...);}
void g(const Args_t& ...)'
```

It is confusing to see the internal-looking identifiers `simple_type_specifier`
and `direct_abstract_declarator` and the English text `not supported by` in the
middle of the parameter list, instead of the parameter type.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

[himehaieto at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hime Haieto  ---
Alright, so apparently the union example is no longer valid (and the comments
you referenced were interesting, and I'd have never found them otherwise!), so
yes, scratch that one - the only issue here is for the typedef redeclaration.

As shown in the original example, a redeclaration of the typedef exactly as in
the attached code is supposed to be valid, and indeed the second declaration
does in fact pass with gcc.  However, a subsequent third declaration does not.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of unions and typedefs

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

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

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

If we don't have WORKS defined, then GCC works. Once you add another definition
of `union bar` or `q_t` after the 2nd one compiling starts to fail. That is the
3rd definition of either will fail but 2 will work.

[Bug c++/118766] Garbled error message in vararg requires

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
`'type_pack_expansion' not supported by simple_type_specifier` is the issue
really. That comes out because the pretty printers don't support it but they
should. Note an ICE would be worse which is why it is done this way.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of typedefs

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

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

--- Comment #9 from uecker at gcc dot gnu.org ---

Test case:
typedef struct q { int x; } q_t;
struct q { int x; };
typedef struct q { int x; } q_t;

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

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

maic  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #5 from maic  ---
$ git bisect bad
3abe751ea86e3472fa2c97bf2014f9f93f569019 is the first bad commit
commit 3abe751ea86e3472fa2c97bf2014f9f93f569019
Author: Jonathan Wakely
Date:   Wed Oct 9 12:55:54 2024 +0100

libstdc++: Refactor std::uninitialized_{copy,fill,fill_n} algos [PR68350]

[Bug rtl-optimization/118755] [15 Regression] ccmp_3.c fails on aarch64

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

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

--- Comment #2 from Andrew Pinski  ---
I think the first thing we could do is (from fwprop1):
```
propagating insn 13 into insn 14, replacing:
(set (reg:SI 103 [ _3 ])
(reg/v:SI 104 [  ]))
successfully matched this instruction to *zero_extendqisi2_aarch64:
(set (reg:SI 103 [ _3 ])
(zero_extend:SI (subreg:QI (reg:SI 108) 0)))
original cost = 4 (weighted: 4.00), replacement cost = 4 (weighted:
4.00); rejecting replacement
change not profitable
propagating insn 13 into insn 15, replacing:
(set (reg:SI 109)
(and:SI (reg/v:SI 104 [  ])
(const_int 1 [0x1])))
failed to match this instruction:
(set (reg:SI 109)
(zero_extend:SI (and:QI (subreg:QI (reg:SI 108) 0)
(const_int 1 [0x1]
```
That should just be simplified to:
(set (reg:SI 109) (and:SI (reg:SI 108) (const_int 1 [0x1])))

Though I am not sure this will fix everything.

[Bug tree-optimization/118759] [15 regression] ICE when building openmsx-19.1 (exact_div, at poly-int.h:2160)

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

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

--- Comment #3 from Sam James  ---
Created attachment 60385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60385&action=edit
reduced.ii

[Bug target/117818] [12/13/14/15 regression] vec_add incorrectly generates vadduwm for vector char const inputs.

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

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

--- Comment #7 from Steven Munroe  ---
(In reply to Richard Biener from comment #6)
> is that powerpc64le or powerpc{,64} big endian?  (or both)

Definitely powerpc64le because few distros support powerpc targets.

I think the lasts GCC I have that supported powerpc was GCC 8.

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

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

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

Sam James  changed:

   What|Removed |Added

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
r15-6294-g96fb71883d438bdb241fdf9c7d12f945c5ba0c7f
Haven't looked if there is no UB in there...

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

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

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

--- Comment #8 from Sam James  ---
-fno-ipa-cp works

[Bug tree-optimization/118749] [15 regression] fontconfig miscompiled with -O3 -march=pentium4 on x86 since r15-1238

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[15 regression] fontconfig  |[15 regression] fontconfig
   |miscompiled with -O3|miscompiled with -O3
   |-march=pentium4 on x86  |-march=pentium4 on x86
   |since   |since r15-1238
   |r15-1238-g1fe55a1794863b5ad |
   |9eeca5062782834716016b2 |

--- Comment #5 from Jakub Jelinek  ---
I think it is better to keep summaries short and have full hashes only in the
body.

[Bug tree-optimization/118749] [15 regression] fontconfig miscompiled with -O3 -march=pentium4 on x86 since r15-1238

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

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

--- Comment #6 from Sam James  ---
(In reply to Jakub Jelinek from comment #5)
> I think it is better to keep summaries short and have full hashes only in
> the body.

Sure.

[Bug fortran/116829] Missing default initialization of finalizable non-polymorphic intent(out) arguments

[trnka at scm dot com via Gcc-bugs]

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

--- Comment #2 from Tomáš Trnka  ---
I have sent a candidate fix for this to the mailing list in the past (and then
somehow forgot about it):
https://gcc.gnu.org/pipermail/fortran/2024-September/061086.html

[Bug testsuite/116860] Move optimization from match.pd into tree-ssa-reassoc (optimize_range_tests) where it can be more effective

[konstantinos.eleftheriou at vrull dot eu via Gcc-bugs]

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

--- Comment #10 from Konstantinos Eleftheriou  ---
We are currently working on a solution for this in reassoc.

[Bug fortran/118740] [OpenMP] 'sorry' used without location data

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:6f95af4f22b641fbb3509f1436bce811d4e4acad

commit r15-7376-g6f95af4f22b641fbb3509f1436bce811d4e4acad
Author: Tobias Burnus 
Date:   Wed Feb 5 14:03:47 2025 +0100

Fortran/OpenMP: Add location data to 'sorry' [PR118740]

PR fortran/118740

gcc/fortran/ChangeLog:

* openmp.cc (gfc_match_omp_context_selector,
match_omp_metadirective):
Change sorry to sorry_at and use gfc_current_locus as location.
* trans-openmp.cc (gfc_trans_omp_clauses): Likewise, but use
n->where.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/append_args-2.f90: Update for line change.

[Bug testsuite/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
For such a trivial method, why don't you just define it inline?
So
--- gcc/simple-diagnostic-path.h.jj 2025-01-02 11:23:37.876218670 +0100
+++ gcc/simple-diagnostic-path.h2025-02-05 15:29:32.882855368 +0100
@@ -100,9 +100,9 @@ class simple_diagnostic_path : public di
  public:
   simple_diagnostic_path (pretty_printer *event_pp);

-  unsigned num_events () const final override;
+  unsigned num_events () const final override { return m_events.length (); }
   const diagnostic_event & get_event (int idx) const final override;
-  unsigned num_threads () const final override;
+  unsigned num_threads () const final override { return m_threads.length (); }
   const diagnostic_thread &
   get_thread (diagnostic_thread_id_t) const final override;
   bool
--- gcc/simple-diagnostic-path.cc.jj2025-01-02 11:23:19.409476476 +0100
+++ gcc/simple-diagnostic-path.cc   2025-02-05 15:29:59.185492553 +0100
@@ -41,15 +41,6 @@ simple_diagnostic_path::simple_diagnosti
   add_thread ("main");
 }

-/* Implementation of diagnostic_path::num_events vfunc for
-   simple_diagnostic_path: simply get the number of events in the vec.  */
-
-unsigned
-simple_diagnostic_path::num_events () const
-{
-  return m_events.length ();
-}
-
 /* Implementation of diagnostic_path::get_event vfunc for
simple_diagnostic_path: simply return the event in the vec.  */

@@ -59,12 +50,6 @@ simple_diagnostic_path::get_event (int i
   return *m_events[idx];
 }

-unsigned
-simple_diagnostic_path::num_threads () const
-{
-  return m_threads.length ();
-}
-
 const diagnostic_thread &
 simple_diagnostic_path::get_thread (diagnostic_thread_id_t idx) const
 {

?

[Bug rtl-optimization/117239] [12/13/14 Regression] wrong code at -O{s,2} with "-fno-inline -fschedule-insns" on x86_64-linux-gnu since r12-7472-g609e8c492d62d9

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

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

--- Comment #14 from Jeffrey A. Law  ---
Late to the party.  The basic idea of the code being modified here is that
there are cases where parts of the caller's stack are effectively "owned" by
the callee.  On the 32 bit PA ABI that was pretty explicit and it seems like
we've stumbled across another case.

The change looks sensible for both the trunk and release branches where I would
expect it to be quite safe.  After all it's just invalidating more stuff from
cselib's hash table.  But obviously your call if you're not comfortable with
backporting it to a release branch.

[Bug target/117814] [15 Regression] arm/MVE: regressions after r15-4734-g63b6967b06b538

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

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

--- Comment #4 from Christophe Lyon  ---
For the warning in
FAIL: gcc.target/arm/pr112337.c (test for excess errors)
this is caused by how we define __fp16, see
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670563.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670611.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673554.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674281.html

The warning appears because the testcase is compiled with
-march=armv8.1-m.main+mve which does not enable fp16 support.

Compiling with -march=armv8.1-m.main+mve.fp or -mcpu=cortex-m55 does not emit
the warning.

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
  Component|c   |middle-end
   Keywords||wrong-code

[Bug tree-optimization/118759] New: [15 regression] ICE when building openmsx-19.1 (exact_div, at poly-int.h:2160)

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

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

Bug ID: 118759
   Summary: [15 regression] ICE when building openmsx-19.1
(exact_div, at poly-int.h:2160)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

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

Originally reported downstream in Gentoo at https://bugs.gentoo.org/949343.

```
$ g++ -c Scaler2.cc.ii -std=c++20 -march=znver2 -O3
during GIMPLE pass: vect
In file included from src/video/scalers/Scaler2.cc:2:
src/video/scalers/LineScalers.hh: In function ‘void
openmsx::Scale_1on2::operator()(std::span, std::span<_Type,
18446744073709551615>) [with Pixel = short unsigned int]’:
src/video/scalers/LineScalers.hh:458:6: internal compiler error: in exact_div,
at poly-int.h:2160
0x602ba61b318a internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x602ba61b3325 fancy_abort(char const*, int, char const*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic.cc:1722
0x602ba4c62233 poly_int<1u, poly_result::is_poly>::type,
poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int<1u, unsigned long> const&,
unsigned long) [clone .isra.0]
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/poly-int.h:2160
0x602ba6d48096 poly_int<1u, poly_result::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int<1u, unsigned long> const&,
poly_int<1u, unsigned long> const&)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/poly-int.h:2173
0x602ba6d48096 vect_get_num_vectors(poly_int<1u, unsigned long>, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vectorizer.h:2119
0x602ba6d402f9 vect_compute_data_ref_alignment
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-data-refs.cc:1388
0x602ba6adbccd vect_analyze_data_refs_alignment(_loop_vec_info*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-data-refs.cc:2946
0x602ba6d8f3a0 vect_analyze_loop_2
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-loop.cc:2960
0x602ba6d8d43c vect_analyze_loop_1
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-loop.cc:3479
0x602ba6a84199 vect_analyze_loop(loop*, gimple*, vec_info_shared*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-loop.cc:3639
0x602ba6d8bdea try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vectorizer.cc:1095
0x602ba6d8bdea try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vectorizer.cc:1212
0x602ba6a553c3 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vectorizer.cc:1328
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
601d2479a8464e3bf1fb53065109a027db7c93f1' --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 --d

[Bug target/118715] Bad PLT asm generated on ARM thumb with PIC and LTO

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #7 from Christophe Lyon  ---
The first time using_thumb_only is called (bfd/elf32-arm.c in binutils
sources), globals->obfd points to a bfd whose filename is:
"pr118715.exe.lto-pr118715.o (symbol from plugin)"
(with "(symbol from plugin)" part of the filename)
and it sees its Tag_CPU_arch_profile as 0.

However, when using readelf to look at the attributes section in
pr118715.exe.lto-pr118715.o, it does have
  Tag_CPU_arch_profile: Microcontroller


So why does bfd_elf_get_obj_attr_int return 0?

I'm not sure how the lto-plugin really works? I've noticed that
pr118715.exe.lto.ltrans0.o does not have an attributes section, but when/how is
it used? I don't see it on linker command line

[Bug tree-optimization/118759] [15 regression] ICE when building openmsx-19.1 (exact_div, at poly-int.h:2160)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=118464
   Target Milestone|--- |15.0

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of PR 118464 .

[Bug c++/16233] unhelpful error message when "template" is omitted

[herring at lanl dot gov via Gcc-bugs]

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

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #12 from S. Davis Herring  ---
-Wmissing-template-keyword is now on by default and helps here, even if the
actual error message is still baroque.

[Bug tree-optimization/118759] [15 regression] ICE when building openmsx-19.1 (exact_div, at poly-int.h:2160)

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

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

--- Comment #2 from Sam James  ---
Ah, sorry, I'd forgot about that one.

[Bug middle-end/118549] -funreachable-traps doesn't transform user provided unreachable into trap

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||bruno at clisp dot org
   Assignee|unassigned at gcc dot gnu.org  |sjames at gcc dot 
gnu.org

--- Comment #9 from Sam James  ---
This came up in
https://lists.gnu.org/archive/html/bug-gnulib/2025-02/msg00024.html too:
"""
[...]

  1) ISO C 23 § 7.21.1.(3) is clear that it's undefined behaviour.
 This is also what gcc does with the usual optimization options:
 It produces no instruction at all, leaving the CPU to execute
 whatever instruction may follow.
 It's documented in
 
 but you can see it directly: compile this code with "gcc -m32 -O2 -S":
 -
 void foo (void) { __builtin_unreachable(); }
 -

 Even with the option -funreachable-traps of GCC >= 13, documented in
 ,
 it produces zero instructions, not even a trap. (See:
 compile the code above with "gcc -m64 -funreachable-traps -S").
[...]
"""

so I think there's a clear case for refining the documentation. I'll put it on
my list.

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
Bug seems to start sometime between 20241217 and 20241231:

foundBugs $ rm ./a.out ; ../results.20241217/bin/gcc -O3 -w bug1086.c &&
./a.out
checksum = E0BB38EE
foundBugs $ rm ./a.out ; ../results.20241231/bin/gcc -O3 -w bug1086.c &&
./a.out
checksum = 3489BDAF
foundBugs $ 
foundBugs $ ../results.20241217/bin/gcc -v 2>&1 | grep exp
gcc version 15.0.0 20241215 (experimental) (fe545ea3d82bc2ba) 
foundBugs $ ../results.20241231/bin/gcc -v 2>&1 | grep exp
gcc version 15.0.0 20241229 (experimental) (0b06abe027a78681) 
foundBugs $ 

trunk $ git log fe545ea3d82bc2ba..0b06abe027a78681 | grep -c "^commit"
193
trunk $

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3 since r15-6294

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60386|0   |1
is obsolete||

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

Note this one now fails at `-O2` too rather than just at `-O3`.

[Bug ipa/118758] [15 regression] wrong code with optimizations since r15-6294

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|middle-end  |ipa
 Status|UNCONFIRMED |NEW
   Keywords|needs-reduction |
Summary|[15 regression] ok code |[15 regression] wrong code
   |with -O2, but wrong code|with optimizations since
   |with -O3 since r15-6294 |r15-6294
   Last reconfirmed||2025-02-05

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

(In reply to Andrew Pinski from comment #11)
> Created attachment 60387 [details]
> Reduced
> 
> Note this one now fails at `-O2` too rather than just at `-O3`.

One note, the reason why it was failing at -O3 rather than -O2 in the original
case is due to a loop which I think was unrolled at -O3 but not at -O2. I
removed the loop and the failure started to happen at -O2 too.

[Bug target/116600] [12/13/14/15 Regression] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.cc:2584 since r7-5127-g827ab47ab1f

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from David Binderman  ---
I see this one also, when compiling gcc.target/s390/preserve-args-2.c
from the gcc testsuite:

dcb@raspberrypi:~/gcc/trunk/gcc/testsuite $ ~/gcc/results.20250131/bin/gcc -c
-g -O2 -march=native ./gcc.target/s390/preserve-args-2.c
dcb@raspberrypi:~/gcc/trunk/gcc/testsuite $ ~/gcc/results.20250205/bin/gcc -c
-g -O2 -march=native ./gcc.target/s390/preserve-args-2.c
during RTL pass: dwarf2
./gcc.target/s390/preserve-args-2.c: In function ‘baz’:
./gcc.target/s390/preserve-args-2.c:19:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.cc:2591
   19 | }
  | ^

[Bug ipa/118758] [15 regression] wrong code with optimizations since r15-6294

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
My reduced testcase is very very similar to the one in bug 118097 comment #26
so closing as a dup.

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

[Bug ipa/118097] [15 regression] recent bug with -O2, but not -O1 since r15-6294-g96fb71883d438b

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

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

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

[Bug target/80881] Implement Windows native TLS

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #101 from LIU Hao  ---
I have bootstrapped GCC 15 (master) with this patch applied, but without
`--enable-tls`, on {i686,x86_64}-w64-mingw32; and have checked that TLS is
emulated as before so it's not an ABI break by default.

I'm preparing more builds with `--enable-tls` now.

[Bug target/115703] [15 Regression] rv64gcv_zvl256b miscompile since r15-1579-g792f97b44ff

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

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

--- Comment #2 from Robin Dapp  ---
> I don't see anything wrong with this move on RTL. Maybe there is something
> wrong going on the pass which is emitting the vsetivli instructions.

Yes, indeed.  With --param=vsetvl-strategy=simple the output is correct.  Going
to have a look.

[Bug c++/118760] Alias template in dependent base used via injected-class-name incorrectly rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/115703] [15 Regression] rv64gcv_zvl256b miscompile since r15-1579-g792f97b44ff

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

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

--- Comment #3 from Robin Dapp  ---
For me this doesn't occur on the trunk anymore and I bisected the working
change to:

r15-3459-gcbea72b265e4c9
Author: Raphael Moreira Zinsly 
Date:   Wed Sep 4 17:21:24 2024 -0600

[PATCH 1/3] RISC-V: Improve codegen for negative repeating large constants

Improve handling of constants where its upper and lower 32-bit
halves are the same and have negative values.

e.g. for:

So it wasn't working since late-combine and started working again with the
above commit.

As the original issue seems to be related to vsetvl placement I'm inclined to
believe that the above just causes it to be latent.

So back to checking vsetvl with the original failing commit.

[Bug middle-end/118758] [15 regression] ok code with -O2, but wrong code with -O3 since r15-6294

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

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

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

Still a few more steps to go but wanted to attach what I have so far.

[Bug c++/70349] FAIL: g++.dg/abi/abi-tag18a.C -std=gnu++98 scan-assembler _ZZ1fB7__test1vEN1T1gB7__test2Ev

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

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

--- Comment #2 from John David Anglin  ---
On hppa64-hp-hpux11.11 at revision r15-7342-gd3627c78be1, we have the following
new fails:

FAIL: g++.dg/abi/abi-tag18a.C  -std=gnu++17  scan-assembler
_ZZZ1fB7__test1vEN1T1gEvE1x
FAIL: g++.dg/abi/abi-tag18a.C  -std=gnu++98  scan-assembler
_ZZZ1fB7__test1vEN1T1gEvE1x
FAIL: g++.dg/abi/abi-tag18a.C  -std=gnu++26  scan-assembler
_ZZZ1fB7__test1vEN1T1gEvE1x

[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

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

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

--- Comment #21 from John David Anglin  ---
For the testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709#c16,
the underflow bit is generated in this glibc code in s_fma.c:

  /* v.ieee.mantissa1 & 2 is LSB bit of the result before rounding,
 v.ieee.mantissa1 & 1 is the round bit and j is our sticky
 bit.  */
  w.d = 0.0;
  w.ieee.mantissa1 = ((v.ieee.mantissa1 & 3) << 1) | j;
  w.ieee.negative = v.ieee.negative;
  v.ieee.mantissa1 &= ~3U;
  v.d *= 0x1p-108;
  w.d *= 0x1p-2;
  return v.d + w.d;

Before the multiplication, w is

$4 = {d = -3.4584595208887258e-323, ieee = {negative = 1, exponent = 0,
mantissa0 = 0, mantissa1 = 7}, ieee_nan = {negative = 1, exponent = 0,
quiet_nan = 0, mantissa0 = 0, mantissa1 = 7}}

After the multiplaction by 0x1p-2 (0.25), w is

$3 = {d = -4.9406564584124654e-324, ieee = {negative = 1, exponent = 0,
mantissa0 = 0, mantissa1 = 1}, ieee_nan = {negative = 1, exponent = 0,
quiet_nan = 0, mantissa0 = 0, mantissa1 = 1}}

and the inexact and underflow bits are set on hppa.  The result looks
reasonable to me.

I'm not sure about ieee754 but different values can be returned when
a non-trapping underflow occurs.  So, the above code seems suspect.

Maybe underflow and inexact should be cleared after w.d is multiplied
by 0x1p-2?

Given the difference between gcc-12 and gcc-13, I'm not sure the return
paths are the same.

[Bug go/118746] In go FE, __builtin_unreachable does not have the attribute cold - or any attribute, for that matter

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Thanks, should be fixed at HEAD.