[Bug target/117562] [15 Regression] 40% slowdown of 482.sphinx3 on Zen4, Zen5 since r15-5120-g9a62c149589103

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Hongtao Liu from comment #10)
> > 
> > I do wonder about the usefulness of the memory alternative on the
> > sse_movhlps pattern though, there's the sse_storehps pattern which
> > also models the store part more precisely as V2SFmode.  Is
> > sse_movhlps_exp ever invoked with a memory destination?
> > 
> 
> Like this?
> 
> typedef float v4sf __attribute__((vector_size(16)));
> void
> foo (v4sf a, v4sf* b)
> {
> *b = __builtin_shufflevector (*b, a, 0, 1, 4, 5);
> }
> 
> 
> foo(float __vector(4), float __vector(4)*):
> movlps  QWORD PTR [rdi+8], xmm0 # 11  [c=4 l=3] 
> sse_movlhps/4
> ret   # 19[c=0 l=1]  simple_return_internal

Indeed.  Btw, I checked and

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 72acd5bde5e..6cd0d932bd9 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -11045,7 +11045,7 @@
 })

 (define_insn "sse_movhlps"
-  [(set (match_operand:V4SF 0 "nonimmediate_operand" "=x,v,x,v,m")
+  [(set (match_operand:V4SF 0 "nonimmediate_operand" "=x,v,x,v,$m")
(vec_select:V4SF
  (vec_concat:V8SF
(match_operand:V4SF 1 "nonimmediate_operand" " 0,v,0,v,0")

does _not_ fix the regression (but maybe I did it wrong).

[Bug c++/117736] Internal error checking coroutine final suspend self reference

[kelbonage at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Nikl Kelbon  ---
Note: its preprocessed sources for another bug with placement new / RVO in
coroutines, i dont know how it placed in my old issue

[Bug c++/117736] Internal error checking coroutine final suspend self reference

[kelbonage at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Nikl Kelbon  ---
There are preprocessed sources

https://github.com/gcc-mirror/gcc/pull/105#issuecomment-2493465483

[Bug fortran/84674] [12/13/14/15 Regression] Derived type name change makes a program segfault, removing non_overridable helps

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #16 from Paul Thomas  ---
Created attachment 59667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59667&action=edit
Fix for this PR

The attached fixes the problem. The compiler doesn't like extensions that are
completely empty!

[Bug sanitizer/117731] [15 Regression] libsanitizer builds not as c++17 even though it uses c++17 features

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

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

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

Untested fix.

[Bug target/117715] [15 regression] gcc.target/sparc/20230328-1.c etc. FAIL

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-22

--- Comment #2 from Eric Botcazou  ---
I can reproduce.

[Bug target/83397] void f() { } has zero arguments for pre C23

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

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

--- Comment #7 from Sam James  ---
It would be useful to fix the pessimisation for the benefit of projects built
with older autoconf (no autoconf release yet made defaults to C23, for example)
or build systems with a hardcoded -std=gnu99 or similar.

[Bug target/117697] gcc.target/i386/avx10_2-vmovd-1.c etc. FAIL

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #9 from Haochen Jiang  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Haochen Jiang  ---
> > Testcase fixed on trunk.
> 
> Great, thanks.
> 
> > Since I do not have a Solaris machine, I could not to solve the problem on
> > Solaris/x86 for:
> >
> >> Weirdly, adding -fomit-frame-pointer to the testcases
> >> make no difference on Solaris and I don't yet see why.
> 
> There's one now in the cfarm (cfarm215), just in case you feel like it ;-)
> 
> Even more strangely, I'd tried an i686-pc-linux-gnu build with
> --enable-frame-pointer (the Solaris default), which showed the testsuite
> failures before your patch, but still -fomit-frame-pointer worked as
> expected.

So if that is the case, it seems that most likely -fomit-frame-pointer did not
work as expected only on Solaris/x86 currently?

[Bug tree-optimization/66179] Sub-optimal code generation with __attribute__((leaf))

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116689
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-22
 Status|UNCONFIRMED |NEW
  Component|ipa |tree-optimization

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

[Bug target/117722] RISC-V: Failed to vectorize x264_pixel_sad_4x4

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

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

--- Comment #13 from Robin Dapp  ---
I don't fully understand yet :)

So the full-register moves are undesirable, I agree.  When accumulating with a
widening op they seem unavoidable, though.  The only alternative would be to
split out the extension and use a regular add which would get us close to your
second example.  I don't see why we would prefer one over the other when the
only difference is one vsetvl outside the loop.  vsext and vmv1r should be
comparable in latency as well.

Regarding vectorizing with misaligned loads, how does that change with a usad
expander?

[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 #85 from LIU Hao  ---
Created attachment 59666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59666&action=edit
libstdc++ fix

It is not possible to export a `__thread` variable with native TLS, because
it's not possible to access `_tls_used` of a different module.

The linker (GNU LD) shall not export such a symbol. It is exporting an unusable
symbol now, so it's a bug.

libstdc++ shall not export and import `__thread` variables. Attached is a patch
for MCF thread model about a different PR, but I think this is a good
opportunity to fix it forever, as native TLS is a hge ABI break already.

[Bug target/83397] void f() { } has zero arguments for pre C23

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|void f() { } has zero   |void f() { } has zero
   |arguments   |arguments for pre C23

--- Comment #6 from Andrew Pinski  ---
I am not sure if needs to be fixed after the switch to default to C23.

[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow

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

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

--- Comment #12 from Sam James  ---
I think that's fine. I still plan to play with that plugin experiment but I was
waiting for other patches to go in, and now occupied with C23 porting :(

[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow

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

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

--- Comment #13 from Siddhesh Poyarekar  ---
No worries, I'd be really surprised if volatile offsets show up in the testing
at all, let alone be significant enough to warrant the rewrite.

[Bug target/116444] gcc.target/arm/thumb-ifcvt-2.c fails on Cortex-M55 and misses possible Cortex-M optimization

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

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

--- Comment #8 from Torbjorn SVENSSON  ---
(In reply to avieira from comment #7)
> @Torbjorn: OK to close?

Yes, this is ok on trunk, but should it also be backported to releases/gcc-14?

[Bug target/116444] [12/13/14 regression] gcc.target/arm/thumb-ifcvt-2.c fails on Cortex-M55 and misses possible Cortex-M optimization since r11-3286-gc2bb84be4a6e58

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |12.5

[Bug target/117562] [15 Regression] 40% slowdown of 482.sphinx3 on Zen4, Zen5 since r15-5120-g9a62c149589103

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Hongtao Liu from comment #8)
> > vec_unpacks_hi_v4sf create an unintialized (reg:V4SF 853), I guess it may
> > confuse LRA to allocate a mem for it.
> 
> For simple case
> void
> foo (double* a, float* b, int n)
> {
> for (int i = 0; i != n; i++)
>   a[i] = b[i];
> }
> 
> RA works ok, there's no extra spill there.

Yeah, it needs enough register pressure to not have the extra reg here.

I think the proposed patch in comment#7 might be good on its own as it
avoids a false dependence on prior register contents (if not optimizing
for size).

It does fix the benchmark regression as well.

I do wonder about the usefulness of the memory alternative on the
sse_movhlps pattern though, there's the sse_storehps pattern which
also models the store part more precisely as V2SFmode.  Is
sse_movhlps_exp ever invoked with a memory destination?

That said, if the memory alternative stays we might want to mark it with '$'
so it's never chosen when the then memory operand needs a reload?

[Bug target/116444] gcc.target/arm/thumb-ifcvt-2.c fails on Cortex-M55 and misses possible Cortex-M optimization

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-22
 Ever confirmed|0   |1

--- Comment #7 from avieira at gcc dot gnu.org ---
@Torbjorn: OK to close?

[Bug target/117697] gcc.target/i386/avx10_2-vmovd-1.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Haochen Jiang  ---
> Testcase fixed on trunk.

Great, thanks.

> Since I do not have a Solaris machine, I could not to solve the problem on
> Solaris/x86 for:
>
>> Weirdly, adding -fomit-frame-pointer to the testcases
>> make no difference on Solaris and I don't yet see why.

There's one now in the cfarm (cfarm215), just in case you feel like it ;-)

Even more strangely, I'd tried an i686-pc-linux-gnu build with
--enable-frame-pointer (the Solaris default), which showed the testsuite
failures before your patch, but still -fomit-frame-pointer worked as
expected.

[Bug tree-optimization/116463] [15 Regression] complex multiply vectorizer detection failures after r15-3087-gb07f8a301158e5

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #21 from Tamar Christina  ---
will wait a week or so for backporting to GCC 14, looking at the complex add
failures on trunk now.  Have an idea but need to work out on paper if sound.

[Bug tree-optimization/116463] [15 Regression] complex multiply vectorizer detection failures after r15-3087-gb07f8a301158e5

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

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

--- Comment #20 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r15-5585-ga9473f9c6f2d755d2eb79dbd30877e64b4bc6fc8
Author: Tamar Christina 
Date:   Thu Nov 21 15:10:24 2024 +

middle-end:For multiplication try swapping operands when matching complex
multiply [PR116463]

This commit fixes the failures of complex.exp=fast-math-complex-mls-*.c on
the
GCC 14 branch and some of the ones on the master.

The current matching just looks for one order for multiplication and was
relying
on canonicalization to always give the right order because of the
TWO_OPERANDS.

However when it comes to the multiplication trying only one order is a bit
fragile as they can be flipped.

The failing tests on the branch are:

void fms180snd(_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
   _Complex TYPE c[restrict N]) {
  for (int i = 0; i < N; i++)
c[i] -= a[i] * (b[i] * I * I);
}

void fms180fst(_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
   _Complex TYPE c[restrict N]) {
  for (int i = 0; i < N; i++)
c[i] -= (a[i] * I * I) * b[i];
}

The issue is just a small difference in commutative operations.
we look for {R,R} * {R,I} but found {R,I} * {R,R}.

Since the DF analysis is cached, we should be able to swap operands and
retry
for multiply cheaply.

There is a constraint being checked by vect_validate_multiplication for the
data
flow of the operands feeding the multiplications.  So e.g.

between the nodes:

note:   node 0x4d1d210 (max_nunits=2, refcnt=3) vector(2) double
note:   op template: _27 = _10 * _25;
note:  stmt 0 _27 = _10 * _25;
note:  stmt 1 _29 = _11 * _25;
note:   node 0x4d1d060 (max_nunits=2, refcnt=2) vector(2) double
note:   op template: _26 = _11 * _24;
note:  stmt 0 _26 = _11 * _24;
note:  stmt 1 _28 = _10 * _24;

we require the lanes to come from the same source which
vect_validate_multiplication checks.  As such it doesn't make sense to flip
them
individually because that would invalidate the earlier linear_loads_p
checks
which have validated that the arguments all come from the same datarefs.

This patch thus flips the operands in unison to still maintain this
invariant,
but also honor the commutative nature of multiplication.

gcc/ChangeLog:

PR tree-optimization/116463
* tree-vect-slp-patterns.cc (complex_mul_pattern::matches,
complex_fms_pattern::matches): Try swapping operands on multiply.

[Bug bootstrap/46334] C++ compiler gets g++ switch even if it isn't g++

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
This is not a configuration which we can ever support. Plus things has changed
to be only compiling with C++.

[Bug target/117715] [15 regression] gcc.target/sparc/20230328-1.c etc. FAIL

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Fixing.

[Bug target/117734] New: Misses VNNI pmaddubsw qi->hi dot_prod

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

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

Bug ID: 117734
   Summary: Misses VNNI pmaddubsw qi->hi dot_prod
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Looking at x264_r mc_chroma which does

  dst[x] = ( cA*src[x]  + cB*src[x+1] + cC*srcp[x] + cD*srcp[x+1] + 32 ) >> 6;

with uchar src[]/dst[] and integer multiplies we manage to reduce the
multiplication precision to HImode but then do not see the opportunity
to use dot_prod for the QI->HI multiply and add.

One reason is x86 doesn't seem to expose [us]dot_prodvNhiv2Nqi which I
think VNNI provides.

The vectorizer also does not consider demoting c[ABCD] to [us]char,
but maybe it would (range info is there).  The vectorizer also has
the issue for this SLP opportunity (aka not reduction) that dot_prod
doesn't specify which lanes are summed, we'd have to fix this.

This PR is about the missing patterns.

[Bug tree-optimization/117735] New: SLP dot_prod opportunity in 525.x264_r

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

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

Bug ID: 117735
   Summary: SLP dot_prod opportunity in 525.x264_r
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

525.x264_r has

typedef unsigned char uint8_t;
void mc_chroma( uint8_t *dst, int i_dst_stride,
   uint8_t *src, int i_src_stride,
   int mvx, int mvy,
   int i_width, int i_height )
{
uint8_t *srcp;

int d8x = mvx&0x07;
int d8y = mvy&0x07;
int cA = (8-d8x)*(8-d8y);
int cB = d8x*(8-d8y);
int cC = (8-d8x)*d8y;
int cD = d8x*d8y;

src += (mvy >> 3) * i_src_stride + (mvx >> 3);
srcp = &src[i_src_stride];

for( int y = 0; y < i_height; y++ )
  {
for( int x = 0; x < i_width; x++ )
  dst[x] = ( cA*src[x]  + cB*src[x+1] + cC*srcp[x] + cD*srcp[x+1] + 32
) >> 6;
dst  += i_dst_stride;
src   = srcp;
srcp += i_src_stride;
  }
}

where the inner loop could use two dot_prodvNhiv2Nqi - iff we had a SLP
pattern recognizing this and iff we'd narrow the invariants to [us]char
(pattern recog demotes the multiply to HImode, range info on c[ABCD]
indicates they fit in QImode).

And iff we'd nail down which lanes get summed for dot_prod (other related
summing optabs have the same unsepcifiedness here, making them only useful
for reductions where we end up summing the result lanes).

[Bug tree-optimization/117735] SLP dot_prod opportunity in 525.x264_r

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

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

--- Comment #1 from Richard Biener  ---
Other "failures" for this loop nest is choosing an alias versioning check that
is invariant in the outer loop so we'd version that instead of just the inner
loop.  We also fail to implement (or schedule) unswitching of the outer loop
on inner loop niter checks the vectorizer inserts for costing and jumps around
vector/epilog.  For perfect nests (and outer loops without actual code) the
vectorizer could consider unswitching the initial epilog entry conditions
itself (at the expense of code size of course).

[Bug sanitizer/117732] [15 Regression] libsanitizer contains anonymous structs but built with -pedantic

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

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

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

Untested fix.  We don't develop the sanitizer code inside of GCC and all we
care about is whether it builds with GCC, don't need -pedantic to ensure it
will build also with other compilers (and it is up to LLVM people to make sure
it builds with clang).

[Bug sanitizer/117732] [15 Regression] libsanitizer contains anonymous structs but built with -pedantic

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

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

--- Comment #4 from Sam James  ---
(In reply to Andrew Pinski from comment #2)
> Introduced with:
> https://github.com/llvm/llvm-project/commit/
> ed9ef9b4f248c62022bb1bebe5e2597cb4f9d209
> 
> So a 15 regression.

I'm sure I've been seeing this for far longer on amd64.

[Bug sanitizer/117732] [15 Regression] libsanitizer contains anonymous structs but built with -pedantic

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   Last reconfirmed||2024-11-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/36503] x86 can use x >> -y for x >> 32-y

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #21972|0   |1
is obsolete||
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

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

[Bug sanitizer/117731] [15 Regression] libsanitizer builds not as c++17 even though it uses c++17 features

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/20241122012127.1377132-1-quic_apin...@quicinc.com/T/#u

[Bug target/83397] void f() { } has zero arguments for pre C23

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed|2017-12-12 00:00:00 |2024-11-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/117562] [15 Regression] 40% slowdown of 482.sphinx3 on Zen4, Zen5 since r15-5120-g9a62c149589103

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

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

--- Comment #10 from Hongtao Liu  ---

> 
> I do wonder about the usefulness of the memory alternative on the
> sse_movhlps pattern though, there's the sse_storehps pattern which
> also models the store part more precisely as V2SFmode.  Is
> sse_movhlps_exp ever invoked with a memory destination?
> 

Like this?

typedef float v4sf __attribute__((vector_size(16)));
void
foo (v4sf a, v4sf* b)
{
*b = __builtin_shufflevector (*b, a, 0, 1, 4, 5);
}


foo(float __vector(4), float __vector(4)*):
movlps  QWORD PTR [rdi+8], xmm0 # 11  [c=4 l=3]  sse_movlhps/4
ret   # 19[c=0 l=1]  simple_return_internal

[Bug tree-optimization/117733] RISC-V SPEC2017 503.bwaves Inefficient fortran multi-dimensional array access

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||riscv
  Component|middle-end  |tree-optimization
 Blocks||26163, 53947

--- Comment #2 from Richard Biener  ---
The inner loop is unrolled and we select a [2,2] VF as the group size is 5:

t.f90:12:20: note:   Detected interleaving load of size 5
t.f90:12:20: note:  _31 = (*q_18(D))[_30];
t.f90:12:20: note:  _44 = (*q_18(D))[_43];
t.f90:12:20: note:  _57 = (*q_18(D))[_56];
t.f90:12:20: note:  _70 = (*q_18(D))[_69];
t.f90:12:20: note:  _83 = (*q_18(D))[_82];

I think what's needed for your idea to work is basically re-rolling the loop,
I don't see how we can otherwise deal with this absent a vector mode
with [10,2]?  Note the re-rolling can take place "virtually" inside the
vectorizer, we'd use a fractional VF to get us to group size 1.


Referenced Bugs:

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

[Bug sanitizer/117731] [15 Regression] libsanitizer builds not as c++17 even though it uses c++17 features

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Haochen Jiang from comment #2)
> I also notice that but why the warning does not appear previously since it
> is always using gnu14?

because the merge (r15-5164-gfa321004f3f628) from upstream brought in the new
code.

[Bug target/100627] missing optimization

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

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

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

Also next time please attach the testcase or put it inline.

[Bug sanitizer/117731] [15 Regression] libsanitizer builds not as c++17 even though it uses c++17 features

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #4 from Haochen Jiang  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Haochen Jiang from comment #2)
> > I also notice that but why the warning does not appear previously since it
> > is always using gnu14?
> 
> because the merge (r15-5164-gfa321004f3f628) from upstream brought in the
> new code.

I c. Then I get the whole picture. Thanks!

[Bug target/117697] gcc.target/i386/avx10_2-vmovd-1.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
>> Even more strangely, I'd tried an i686-pc-linux-gnu build with
>> --enable-frame-pointer (the Solaris default), which showed the testsuite
>> failures before your patch, but still -fomit-frame-pointer worked as
>> expected.
>
> So if that is the case, it seems that most likely -fomit-frame-pointer did not
> work as expected only on Solaris/x86 currently?

But only in this particular case: I've used it successfully in the past
to fix several testcases, that's what makes it so weird here.

[Bug target/117165] ICE: in extract_insn, at recog.c:2311 unrecognizable insn: UNSPECV_FNSTSW with -mgeneral-regs-only and __builtin_ia32_fnstsw()

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-5587-gd6d1fdcf953a79d1e3ef2d28c99c1933d1e07d80
Author: Jakub Jelinek 
Date:   Fri Nov 22 11:33:34 2024 +0100

i386: Make __builtin_ia32_f{nstenv,ldenv,nstsw,fnclex} builtins internal
[PR117165]

As the comment says, these builtins are meant to be internal for the atomic
support and cause various ICEs when using them directly in various
conditions.
So the following patch makes them internal.
We do have also internal-fn.*, but those target specific builtins would
need to be there in generic code, so I've just added space to their name,
which is the old way to hide builtins/attributes etc.

2024-11-22  Jakub Jelinek  

PR target/117165
* config/i386/i386-builtin.def (IX86_BUILTIN_FNSTENV,
IX86_BUILTIN_FLDENV, IX86_BUILTIN_FNSTSW, IX86_BUILTIN_FNCLEX): Add
space to the end of the builtin name to make it really internal.

* gcc.target/i386/pr117165.c: New test.

[Bug target/117165] ICE: in extract_insn, at recog.c:2311 unrecognizable insn: UNSPECV_FNSTSW with -mgeneral-regs-only and __builtin_ia32_fnstsw()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug target/80881] Implement Windows native TLS

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #86 from Uroš Bizjak  ---
(In reply to Julian Waters from comment #83)

> Uros: I see, I'll try to do so. I was mainly avoiding that to break less
> code (I have a habit of doing that to anything I touch). Although, the
> resulting assembly (Barring the register selection) already seems to be as
> compact as possible for Windows, I'm not sure how using get_thread_pointer
> could make it any more optimal. This is a genuinely curious question, not
> placing doubt on whether get_thread_pointer can help optimize the resulting
> assembly

I can speak from Linux perspective - when thread pointer is modelled as UNSPEC,
then generic compiler part can optimize access to the location as shown in the
Comment #81. There are many optimizations performed, and following the current
implementation assures that your target won't be left behind when new generic
optimization is introduced.

That said, and looking at your code in Comment #83, it looks that on Windows,
TLS access can't use gs: prefixed address (similar to Linux with
-mno-tls-direct-seg-refs). If this is the case, then generating UNSPEC via
get_thread_pointer is not beneficial, since UNSPEC can't be combined into
address.

Your thread pointer is generated with:

+  tp = gen_const_mem (Pmode, GEN_INT (TARGET_64BIT ? 88 : 44));
+  set_mem_addr_space (tp, DEFAULT_TLS_SEG_REG);

which is in fact what UNSPEC_TP will be split to in split1 pass.

[Bug c++/117736] New: Internal error checking coroutine final suspend self reference

[kelbonage at gmail dot com via Gcc-bugs]

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

Bug ID: 117736
   Summary: Internal error checking coroutine final suspend self
reference
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelbonage at gmail dot com
  Target Milestone: ---

I have several similar places in coroutines:

node_t* node = new (mem) node_t(co_await factory());

it produces ICE on gcc 12-13-14

Cannot add file with preprocessed source, since its > 1000KB

[Bug c++/117736] Internal error checking coroutine final suspend self reference

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Please attach it compressed with e.g. xz -9e.

สินเชื่อsme

[Adrian via Gcc-bugs]

ขออนุญาตผู้ดูเเลเเละเจ้าของกิจการด้วยครับ
ของผมจะเป็นการเสนอเงินทุนเพื่อเจ้าของธุรกิจ
ที่มีการจดทะเบียนในรูปแบบบริษัท
หจก โรงงานอุตสาหกรรม ทั่วประเทศ
ดอกเบี้ยต่ำ เริ่มต้นที่ 1-1.5%
สอบถามฟรีพนักงานสุภาพ
0626697879 (ผู้จัดการฝ่ายการเงิน)

[Bug c/114541] Invalid gimple __BB# accepted due to usage of atoi

[heiko at hexco dot de via Gcc-bugs]

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

Heiko Eißfeldt  changed:

   What|Removed |Added

 CC||heiko at hexco dot de

--- Comment #1 from Heiko Eißfeldt  ---
can confirm ICE with invalid character after __BB#:
../PR114541.c: In function ‘foo’:
../PR114541.c:11:15: error: expected ‘;’ before ‘&’ token
   11 | goto __BB3&;
  |   ^
  |   ;
../PR114541.c:28:1: internal compiler error: Segmentation fault
   28 | }
  | ^
0x6bae251 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:518
0x25970a6 crash_signal
../../gcc/toplev.cc:323
0x11a245e bool vec_safe_reserve(vec*&, unsigned int, bool)
../../gcc/vec.h:715
0x11a245e bool vec_safe_reserve(vec*&, unsigned int, bool)
../../gcc/vec.h:712
0x11a245e edge_def** vec_safe_push(vec*&, edge_def* const&)
../../gcc/vec.h:834
0x11a245e connect_dest
../../gcc/cfg.cc:227
0x11a245e unchecked_make_edge(basic_block_def*, basic_block_def*, int)
../../gcc/cfg.cc:290
0xeafed6 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
../../gcc/c/gimple-parser.cc:301
0xe43097 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:3064
0xe8b6da c_parser_external_declaration
../../gcc/c/c-parser.cc:2066
0xe8d824 c_parser_translation_unit
../../gcc/c/c-parser.cc:1920
0xe8d824 c_parse_file()
../../gcc/c/c-parser.cc:28424
0xffcc72 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1375
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.

But that should be a different new PR, right?

[Bug c/117724] [15 regression] ICE when building libgit2 (error: ‘TYPE_CANONICAL’ is not compatible)

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

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

--- Comment #5 from uecker at gcc dot gnu.org ---
Preliminary patch (but does not cover all similar cases):

diff --git a/gcc/tree.cc b/gcc/tree.cc
index 1da06c7d4e9..453b56cc37c 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -13977,6 +13977,9 @@ gimple_canonical_types_compatible_p (const_tree t1,
const_tree t2,
  tree max1 = TYPE_MAX_VALUE (i1);
  tree max2 = TYPE_MAX_VALUE (i2);

+ if (!max1 || !max2)
+   return true;
+
  /* The minimum/maximum values have to be the same.  */
  if ((min1 == min2
   || (min1 && min2

[Bug target/117737] [15 Regression] GCC: cannot build anymore under CYGWIN, INCLUDE_MEMORY is missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2024-11-22
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I am going to remove the whole INCLUDE_MEMORY define as diagnostic.h is
included in almost all sources at this point so just have system.h include it
always.

[Bug fortran/117730] Wrong code with non_overridable typebound procedure

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
I looked at the fortran dump, and also at the verbose asm, comparing
with and w/o non_overridable.

module2 has permuted(?) vtab entries:

@@ -32,10 +32,10 @@
.quad   0
 # _deallocate:
.quad   0
-# calc:
-   .quad   __module2_MOD_child2_calc
 # reset:
.quad   __module1_MOD_child_reset
+# calc:
+   .quad   __module2_MOD_child2_calc
.text
.globl  __module2_MOD___copy_module2_Child2
.type   __module2_MOD___copy_module2_Child2, @function


Could that be related to child_reset being invoked, although it should not?

[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:9fd8cd1990e0f5bac416bafc8a588d05c735f000

commit r14-10965-g9fd8cd1990e0f5bac416bafc8a588d05c735f000
Author: Harald Anlauf 
Date:   Thu Nov 14 21:38:04 2024 +0100

Fortran: fix passing of NULL() actual argument to character dummy
[PR104819]

Ensure that character length is set and passed by the call to a procedure
when its dummy argument is NULL() with MOLD argument present, or set length
to either 0 or the callee's expected character length.  For assumed-rank
dummies, use the rank of the MOLD argument.  Generate temporaries for
passed arguments when needed.

PR fortran/104819

gcc/fortran/ChangeLog:

* trans-expr.cc (conv_null_actual): Helper function to handle
passing of NULL() to non-optional dummy arguments of non-bind(c)
procedures.
(gfc_conv_procedure_call): Use it for character dummies.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f70c1d517e09c4dde421774a8cec591ca3c479a0)

[Bug sanitizer/117732] [14/15 Regression] libsanitizer contains anonymous structs but built with -pedantic

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #59669|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Updated patch after PR117731 fix has been committed.

[Bug c++/117736] Internal error checking coroutine final suspend self reference

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

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

--- Comment #6 from Andrew Pinski  ---
Reducing. Note the preprocessed source does not work on the trunk but that is
due to an incompatibility with the older libstdc++ part rather than your code I
think.

[Bug c/117641] ICE: SIGSEGV in contains_struct_check (tree.h:3788) with __sync_fetch_and_add() on _BitInt(128) on i686

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:44984f7f7523f136085ba60fd107ba8309d4115b

commit r15-5593-g44984f7f7523f136085ba60fd107ba8309d4115b
Author: Jakub Jelinek 
Date:   Fri Nov 22 19:47:52 2024 +0100

c-family: Yet another fix for _BitInt & __sync_* builtins [PR117641]

Sorry, the last patch only partially fixed the __sync_* ICEs with
_BitInt(128) on ia32.
Even for !fetch we need to error out and return 0.  I was afraid of
APIs like __atomic_exchange/__atomic_compare_exchange, those obviously
need to be supported even on _BitInt(128) on ia32, but they actually never
sync_resolve_size, they are handled by adding the size argument and using
the library version much earlier.
For fetch && !orig_format (i.e. __atomic_fetch_* etc.) we need to return -1
so that we handle it with a manualy __atomic_load +
__atomic_compare_exchange loop in the caller, all other cases should
be rejected.

2024-11-22  Jakub Jelinek  

PR c/117641
* c-common.cc (sync_resolve_size): For size 16 with _BitInt
on targets where TImode isn't supported, use goto incompatible if
!fetch.

* gcc.dg/bitint-117.c: New test.

[Bug tree-optimization/117420] [15 regression] wrong code at -O1 on x86_64-linux-gnu since r15-4601-ge2e798b8607401

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-5594-gc25c172959e7fb424455ee6acc60571c68b72443
Author: Jakub Jelinek 
Date:   Fri Nov 22 19:50:22 2024 +0100

match.pd: Fix up the new simpliofiers using with_possible_nonzero_bits2
[PR117420]

The following testcase shows wrong-code caused by incorrect use
of with_possible_nonzero_bits2.
That matcher is defined as
/* Slightly extended version, do not make it recursive to keep it cheap. 
*/
(match (with_possible_nonzero_bits2 @0)
 with_possible_nonzero_bits@0)
(match (with_possible_nonzero_bits2 @0)
 (bit_and:c with_possible_nonzero_bits@0 @2))
and because with_possible_nonzero_bits includes the SSA_NAME case with
integral/pointer argument, both forms can actually match when a SSA_NAME
with integral/pointer type has a def stmt which is BIT_AND_EXPR
assignment with say SSA_NAME with integral/pointer type as one of its
operands (or INTEGER_CST, another with_possible_nonzero_bits case).
And in match.pd the latter actually wins if both match and so when using
(with_possible_nonzero_bits2 @0) the @0 will actually be one of the
BIT_AND_EXPR operands if that form is matched.

Now, with_possible_nonzero_bits2 and with_certain_nonzero_bits2 were added
for the
/* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0.  */
(for cmp (eq ne)
 (simplify
  (cmp:c (with_possible_nonzero_bits2 @0) (with_certain_nonzero_bits2 @1))
  (if (wi::bit_and_not (wi::to_wide (@1), get_nonzero_bits (@0)) != 0)
   { constant_boolean_node (cmp == NE_EXPR, type); })))
simplifier, but even for that one I think they do not do a good job, they
might actually pessimize stuff rather than optimize, but at least does not
result in wrong-code, because the operands are solely tested with
wi::to_wide or get_nonzero_bits, but not actually used in the
simplification.  The reason why it can pessimize stuff is say if we have
  # RANGE [irange] int ... MASK 0xb VALUE 0x0
  x_1 = ...;
  # RANGE [irange] int ... MASK 0x8 VALUE 0x0
  _2 = x_1 & 0xc;
  _3 = _2 == 2;
then if it used just with_possible_nonzero_bits@0, @0 would have
get_nonzero_bits (@0) 0x8 and (2 & ~8) != 0, so we can fold it into
  _3 = 0;
But as it uses (with_possible_nonzero_bits2 @0), @0 is x_1 rather
than _2 and get_nonzero_bits (@0) is unnecessarily conservative,
0xb rather than 0x8 and (2 & ~0xb) == 0, so we don't optimize.
Now, with_possible_nonzero_bits2 can actually improve stuff as well in that
pattern, if say value ranges aren't fully computed yet or the BIT_AND_EXPR
assignment has been added later and the lhs doesn't have range computed
yet,
get_nonzero_range on the BIT_AND_EXPR lhs will be all bits set, while
on the BIT_AND_EXPR operand might actually succeed.

I believe better would be to either modify get_nonzero_bits so that it
special cases the SSA_NAME with BIT_AND_EXPR def_stmt (but one level
deep only like with_possible_nonzero_bits2, no recursion), in that case
return bitwise and of get_nonzero_bits (non-recursive) for the lhs and
both operands, and possibly BIT_AND_EXPR itself e.g. for GENERIC
matching during by returning bitwise and of both operands.
Then with_possible_nonzero_bits2 could be needed for the GENERIC case,
perhaps have the second match #if GENERIC, but changed so that the @N
operand always is the whole thing rather than its operand which is
error-prone.  Or add get_nonzero_bits wrapper with a different name
which would do that.

with_certain_nonzero_bits2 could be changed similarly, these days
we can test known non-zero bits rather than possible non-zero bits on
SSA_NAMEs too, we record both mask and value, so possible nonzero bits
(aka. get_nonzero_bits) is mask () | value (), while known nonzero bits
is value () & ~mask (), with a new function (get_known_nonzero_bits
or get_certain_nonzero_bits etc.) which handles that.

Anyway, the following patch doesn't do what I wrote above just yet,
for that single pattern it is just a missed optimization.
But the with_possible_nonzero_bits2 uses in the 3 new simplifiers are
just completely incorrect, because they don't just use the @0 operand
in get_nonzero_bits (pessimizing stuff if value ranges are fully computed),
but also use it in the replacement, then they act as if the BIT_AND_EXPR
wasn't there at all.
While we could use (with_possible_nonzero_bits2@3 @0) and use
get_nonzero_bits (@0) and use @3 in the replacement, that would still
often be a pessimization, so I've just used with_possible_nonzero_bits@0.

2024-11-22  Jakub Jelinek  

PR tree-optimization/117420
* m

[Bug c++/117736] Internal error checking coroutine final suspend self reference

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

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

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

Compressed testcase

[Bug driver/117739] `-fhardened -Wl,-z,lazy` still passes `-z now` to the linker

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc -fhardened -Wl,-z,lazy  |`-fhardened -Wl,-z,lazy`
   |unexpectadly links binary   |still passes `-z now` to
   |with immediate binding (-z  |the linker
   |now)|

--- Comment #1 from Andrew Pinski  ---
There is code in the driver to disable adding `-z now -z relro` but it looks
like it is not working for some reason:

  if (!any_link_options_p && !static_p)
{
#if defined HAVE_LD_PIE && defined LD_PIE_SPEC
  save_switch (LD_PIE_SPEC, 0, NULL, /*validated=*/true,
/*known=*/false);
#endif
  /* These are passed straight down to collect2 so we have to break
 it up like this.  */
  if (HAVE_LD_NOW_SUPPORT)
{
  add_infile ("-z", "*");
  add_infile ("now", "*");
}
  if (HAVE_LD_RELRO_SUPPORT)
{
  add_infile ("-z", "*");
  add_infile ("relro", "*");
}
}


Oh any_link_options_p just means -r, -shared, -no-pie, -pie was passed.  It
does not include -Wl, options.

[Bug target/117737] [15 Regression] GCC: cannot build anymore under CYGWIN, INCLUDE_MEMORY is missing

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

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

--- Comment #2 from Andrew Pinski  ---
Patch posted to remove INCLUDE_MEMORY from everywhere:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669828.html

[Bug driver/117739] `-fhardened -Wl,-z,lazy` still passes `-z now` to the linker

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-22
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Marek Polacek  ---
I suppose driver_handle_option/case OPT_Wl_ could look for "lazy" and set
any_link_options_p in that case.

I think this is a bug.

[Bug sanitizer/117731] [15 Regression] libsanitizer builds not as c++17 even though it uses c++17 features

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed, PR 117732 tracks the -pedantic issue.

[Bug libcc1/105632] Canadian Cross build failure - error: attempt to use poisoned "malloc"

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Already fixed.

[Bug target/117007] Poor optimization for small vector constants needed for vector shift/rotate/mask generation

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

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

Steven Munroe  changed:

   What|Removed |Added

  Attachment #59291|0   |1
is obsolete||

--- Comment #14 from Steven Munroe  ---
Created attachment 59674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59674&action=edit
Uodates 32-bit examples showing diff behaviour across shift/rotates

Replaced vec-shift-const.c version with additional examples.

[Bug target/117007] Poor optimization for small vector constants needed for vector shift/rotate/mask generation

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

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

--- Comment #15 from Steven Munroe  ---
Found where handling of vec_splat_u32 constant shift counts are handled
differently across the various shift/rotate intrinsics.

Even for the 5-bit shift counts (the easy case) the behavior of the various
shift/rotate intrinsic are inconsistent. The compiler pays way to much
attention to how the shift count is generated but differently between shift
left/right word and different again for rotate left word.

Any reasonable person would assume that using vec_splat_u32() for any shift
value 1 to 31 (-16 to 15) will generate efficient code. And it does for
vec_vslw() which generates two instructions (vspltisw v0,-16; vslw v2,v2,v0).

But the compiler behaves differently for vec_vsrw() and vec_vsraw():
 - for values 1-15 generates:
   - vspltisw v0,15; vsrwv2,v2,v0
 - for even values between 16 - 30
   - vspltisw v0,8; vadduwm v0,v0,v0; vsrwv2,v2,v0
 - for odd values between 17 - 31 generates a load for .rodata

And positively strange for vec_vrlw():
 - for values 1-15 it generates:
   - vspltisw v0,15; vrlwv2,v2,v0
 - but for any value between 16 - 31 it gets strange:
1200 :
1200:   30 00 20 39 li  r9,48
1204:   8c 03 00 10 vspltisw v0,0
1208:   67 01 29 7c mtvrd   v1,r9
120c:   93 0a 21 f0 xxspltw vs33,vs33,1
1210:   80 0c 00 10 vsubuwm v0,v0,v1
1214:   84 00 42 10 vrlwv2,v2,v0
1218:   20 00 80 4e blr

[Bug target/117718] Inefficient address computation for d-form vector loads

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

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

--- Comment #5 from Steven Munroe  ---
(In reply to Michael Meissner from comment #3)
> No, the issue is with DQ addressing (i.e. vector load/store with offset), we
> can't guarantee that the external address will be properly aligned with the
> bottom 4 bits must be set to 0.

The specific case I seeing is loading const vectors from .rodata. These are
always quadword aligned. The compiler should know this as the offset is .TOC
(R2) relative.

That has to be case of -mcpu=power8 otherwise it could not use lvx.

So it seems reasonable to assume that this is also true for P9/P10.

[Bug modula2/115540] "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a value, in function returning 'void' [-fpermissive]" when HAVE_CFMAKERAW is defined

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

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

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

https://gcc.gnu.org/g:8701cdbf8df3f746df85882878beb8e8f897b014

commit r14-10967-g8701cdbf8df3f746df85882878beb8e8f897b014
Author: Gaius Mulley 
Date:   Fri Nov 22 19:46:44 2024 +

[PATCH] PR modula2/115540 gcc/m2/mc-boot-ch/Gtermios.cc error
return-statement with a value

This patch fixes three occurrences of cfmakeraw use in the hand built
m2 support libraries which incorrectly attempt to return a void
result.

gcc/m2/ChangeLog:

PR modula2/115540
* gm2-libs-ch/termios.c (cfmakeraw): Remove return.
* mc-boot-ch/Gtermios.cc (cfmakeraw): Remove return.
* pge-boot/Gtermios.cc (cfmakeraw): Remove return.

(cherry picked from commit d16355c72c7f7b54ecf06371d14d7ad309ea4c34)

Signed-off-by: Gaius Mulley 

[Bug c++/87850] Add fix-it hint for "invalid conversion from 'X' to 'X*'"

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

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

David Malcolm  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/piperma
   |patches/2018-11/msg00802.ht |il/gcc-patches/2024-Novembe
   |ml  |r/669830.html

--- Comment #4 from David Malcolm  ---
6 years later, a v5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669830.html

[Bug fortran/114021] ICE with allocation of scalar pointer entity where SOURCE=f() with f() returning a pointer

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-22
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Replacing

   allocate(x, source = f())

by a plain

   x => f()

works as expected.

[Bug c/117739] New: gcc -fhardened -Wl,-z,lazy unexpectadly links binary with immediate binding (-z now)

[dimitri.ledkov at surgut dot co.uk via Gcc-bugs]

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

Bug ID: 117739
   Summary: gcc -fhardened -Wl,-z,lazy unexpectadly links binary
with immediate binding (-z now)
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.ledkov at surgut dot co.uk
  Target Milestone: ---

Given a trivial c source code

# cat >hello.c <<"EOF"
  #include 
  #include 
  #include 
  int main(int argc, char* argv[]) {
  printf("hello-c");
  char buffer[5000];
  strcpy(buffer, argv[0]);
  char* dynbuffer = alloca(argc * 1000);
  strcpy(dynbuffer, argv[0]);
  return buffer[argc] + dynbuffer[argc];
  }
EOF


This compilation uses lazy binding

# /usr/bin/gcc -Wl,-z,lazy -o hello-lazy hello.c
# hardening-check hello-lazy 
hello-lazy:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: no, not found!
 Stack clash protection: unknown, no -fstack-clash-protection instructions
found
 Control flow integrity: no, not found!

Adding -fhardened negates the manually passed lazy flag. And results in a
binary with an "immediate binding: yes".

# /usr/bin/gcc -fhardened -Wl,-z,lazy -o hello-lazy hello.c
cc1: warning: '_FORTIFY_SOURCE' is not enabled by '-fhardened' because
optimizations are turned off [-Whardened]
# hardening-check hello-lazy 
hello-lazy:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: yes
 Control flow integrity: yes

Is it at all possible to use "-fhardened" and yet opt-into lazy binding?

Adding `-v` shows that there is always a trailing `-z now`, irrespective of the
order of when `-fhardened` is specified.

Note the "-z lazy /tmp/ccAfv8z8.o -z now -z relro" in the below output.

# /usr/bin/gcc -v -fhardened -Wl,-z,lazy -o hello-lazy hello.c
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --disable-nls --disable-werror
--with-pkgversion='Wolfi 14.2.0-r5' --with-glibc-version=2.39
--enable-initfini-array --disable-nls --disable-multilib --enable-host-shared
--enable-host-pie --enable-host-bind-now --enable-shared --enable-threads
--enable-tls --enable-default-pie --enable-default-ssp --with-system-zlib
--with-arch=x86-64-v2 --with-tune=sapphirerapids
--enable-languages=c,c++,fortran,jit,go --enable-bootstrap
--enable-gnu-indirect-function --enable-gnu-unique-object --enable-cet=auto
--enable-link-mutex --with-gcc-major-version-only --with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (Wolfi 14.2.0-r5) 
COLLECT_GCC_OPTIONS='-v' '-fhardened' '-o' 'hello-lazy' '-pie'
'-mtune=sapphirerapids' '-march=x86-64-v2' '-dumpdir' 'hello-lazy-'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/14/cc1 -quiet -v hello.c -quiet -dumpdir
hello-lazy- -dumpbase hello.c -dumpbase-ext .c -mtune=sapphirerapids
-march=x86-64-v2 -version -fhardened -o /tmp/ccBXY5Fa.s
GNU C17 (Wolfi 14.2.0-r5) version 14.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 14.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/include-fixed
 /usr/include
End of search list.
Compiler executable checksum: 95d77264d79a95d022166a5c691d1df2
cc1: warning: '_FORTIFY_SOURCE' is not enabled by '-fhardened' because
optimizations are turned off [-Whardened]
COLLECT_GCC_OPTIONS='-v' '-fhardened' '-o' 'hello-lazy' '-pie'
'-mtune=sapphirerapids' '-march=x86-64-v2' '-dumpdir' 'hello-lazy-'
 /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/as -v
--64 -o /tmp/ccAfv8z8.o /tmp/ccBXY5Fa.s
GNU assembler version 2.43.1 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.43.1
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/:/usr/libexec/gcc/x86_64-pc-linux-gnu/14/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/14/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/14/:/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

--- Comment #17 from Eric Botcazou  ---
There is a nasty subtlety: the pattern is not vcond_mask but vcond_mask_ with a
trailing underscore!

[Bug target/117718] Inefficient address computation for d-form vector loads

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

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

--- Comment #4 from Segher Boessenkool  ---
The address for lxv and lxvx can be anything.  The *offset* in the address for
lxv has to be a multiple of sixteen.  This isn't any different from DS-mode
(well,
multiple of 4 there), and we have DQ-mode instructions all over the place as
well
already anyway, lq is the obvious one.

So what is special about lxv?

[Bug target/117603] RISC-V: testsuite: Architecture string mutation is not robust

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Dimitar Dimitrov :

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

commit r15-5591-geeff504238aeb4a9a20a9e445307b6773adb6f01
Author: Dimitar Dimitrov 
Date:   Sat Nov 16 09:57:31 2024 +0200

testsuite: RISC-V: Fix vector flags handling [PR117603]

The DejaGnu routine "riscv_get_arch" fails to infer the correct
architecture string when GCC is built for RV32EC.  This causes invalid
architecture string to be produced by "add_options_for_riscv_v":
  xgcc: error: '-march=rv32cv': first ISA subset must be 'e', 'i' or 'g'

Fix by adding the E base ISA variant to the list of possible architecture
modifiers.

Also, the V extension is added to the machine string without checking
whether dependent extensions are available.  This results in errors when
GCC is built for RV32EC:
  Executing on host: .../xgcc ... -march=rv32ecv ...
  cc1: error: ILP32E ABI does not support the 'D' extension
  cc1: sorry, unimplemented: Currently the 'V' implementation requires the
'M' extension

Fix by disabling vector tests for RISC-V if V extension cannot be added
to current architecture.

Tested riscv32-none-elf for -march=rv32ec using GNU simulator.  Most of
the remaining failures are due to explicit addition of vector options,
yet missing "dg-require-effective-target riscv_v_ok":

=== gcc Summary ===

 # of expected passes211958
 # of unexpected failures1826
 # of expected failures  1059
 # of unresolved testcases   5209
 # of unsupported tests  15513

Ensured riscv64-unknown-linux-gnu tested with qemu has no new passing or
failing tests, before and after applying this patch:

 Running target riscv-sim/-march=rv64imafdc/-mabi=lp64d/-mcmodel=medlow
 ...
=== gcc Summary ===

 # of expected passes237209
 # of unexpected failures335
 # of expected failures  1670
 # of unresolved testcases   43
 # of unsupported tests  16767

PR target/117603

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (riscv_get_arch): Add comment about
function purpose.  Add E ISA to list of possible
modifiers.
(check_vect_support_and_set_flags): Do not advertise vector
support if V extension cannot be enabled.

Signed-off-by: Dimitar Dimitrov 

[Bug c++/117727] __builtin_bit_cast with target type nullptr_t unimplemented

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

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

--- Comment #8 from Joseph S. Myers  ---
As nullptr_t is in C23, arguably psABIs ought to define the representation of
nullptr_t as part of defining the C ABI.

[Bug c++/117736] Internal error checking coroutine final suspend self reference

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Nikl Kelbon from comment #2)
> There are preprocessed sources
> 
> https://github.com/gcc-mirror/gcc/pull/105#issuecomment-2493465483

Next time you could compress them using xz, gzip, bzip2, zip, etc if they are
too large. I attached the compressed version. Will look to see if this is a
known dup.

[Bug modula2/115536] Expression is evaluated incorrectly when encountering relops and indirection

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

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

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

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

commit r14-10966-g3adceba04eddf8c6e21fda3f7d0f8015e17bf5d8
Author: Gaius Mulley 
Date:   Fri Nov 22 18:38:51 2024 +

[PATCH] PR modula2/115536 Expression is evaluated incorrectly when
encountering relops and indirection

This fix ensures that we only call BuildRelOpFromBoolean if we are
inside a constant expression (where no indirection can be used).
The fix creates a temporary variable when a boolean is created from
a relop in other cases.
The previous pattern implementation would not work if the operands required
dereferencing during non const expressions.  Comparison of relop results
in a constant expression are resolved by constant propagation, basic
block analysis and dead code removal.  After the quadruples have been
optimized only one assignment to the boolean variable will remain for
const expressions.  All quadruple pattern checking for boolean
expressions is removed by the patch.  Thus the implementation becomes
more generic.

gcc/m2/ChangeLog:

PR modula2/115536
* gm2-compiler/M2BasicBlock.def (GetBasicBlockScope): New
procedure.
(GetBasicBlockStart): Ditto.
(GetBasicBlockEnd): Ditto.
(IsBasicBlockFirst): New procedure function.
* gm2-compiler/M2BasicBlock.mod (ConvertQuads2BasicBlock): Allow
conditional boolean quads to be removed.
(GetBasicBlockScope): Implement new procedure.
(GetBasicBlockStart): Ditto.
(GetBasicBlockEnd): Ditto.
(IsBasicBlockFirst): Implement new procedure function.
* gm2-compiler/M2GCCDeclare.def (FoldConstants): New parameter
declaration.
* gm2-compiler/M2GCCDeclare.mod (FoldConstants): New parameter
declaration.
(DeclareTypesConstantsProceduresInRange): Recreate basic blocks
after resolving constant expressions.
(CodeBecomes): Guard IsVariableSSA with IsVar.
* gm2-compiler/M2GenGCC.def (ResolveConstantExpressions): New
parameter declaration.
* gm2-compiler/M2GenGCC.mod (FoldIfLess): Remove relop pattern
detection.
(FoldIfGre): Ditto.
(FoldIfLessEqu): Ditto.
(FoldIfGreEqu): Ditto.
(FoldIfIn): Ditto.
(FoldIfNotIn): Ditto.
(FoldIfEqu): Ditto.
(FoldIfNotEqu): Ditto.
(FoldBecomes): Add BasicBlock parameter and allow conditional
boolean becomes to be folded in the first basic block.
(ResolveConstantExpressions): Reimplement.
* gm2-compiler/M2Quads.def (IsConstQuad): New procedure function.
(IsConditionalBooleanQuad): Ditto.
* gm2-compiler/M2Quads.mod (IsConstQuad): Implement new procedure
function.
(IsConditionalBooleanQuad): Ditto.
(MoveWithMode): Use GenQuadOTypetok.
(IsInitialisingConst): Rewrite using OpUsesOp1.
(OpUsesOp1): New procedure function.
(doBuildAssignment): Mark des as a VarConditional.
(ConvertBooleanToVariable): Call PutVarConditional.
(DumpQuadSummary): New procedure.
(BuildRelOpFromBoolean): Updated debugging and improved comments.
(BuildRelOp): Only call BuildRelOpFromBoolean if we are in a const
expression and both operands are boolean relops.
(GenQuadOTypeUniquetok): New procedure.
(BackPatch): Correct comment.
* gm2-compiler/SymbolTable.def (PutVarConditional): New procedure.
(IsVarConditional): New procedure function.
* gm2-compiler/SymbolTable.mod (PutVarConditional): Implement new
procedure.
(IsVarConditional): Implement new procedure function.
(SymConstVar): New field IsConditional.
(SymVar): New field IsConditional.
(MakeVar): Initialize IsConditional field.
(MakeConstVar): Initialize IsConditional field.
* gm2-compiler/M2Swig.mod (DoBasicBlock): Change parameters to
use BasicBlock.
* gm2-compiler/M2Code.mod (SecondDeclareAndOptimize): Use iterator
to FoldConstants over basic block list.
* gm2-compiler/M2SymInit.mod (AppendEntry): Replace parameters
with BasicBlock.
* gm2-compiler/P3Build.bnf (Relation): Call RecordOp for #, <> and
=.

gcc/testsuite/ChangeLog:

PR modula2/115536
* gm2/iso/const/pass/constbool4.mod: New test.
* gm2/iso/const/pass/constbool5.mod: New test.
* gm2/iso/run/pass/condtest2.mod: New test.
* gm2/iso/run/pass/condtest3.mod: New test.
* g

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #35 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:27778979c9a1e32a6ca74e5b5f377385225449b1

commit r15-5595-g27778979c9a1e32a6ca74e5b5f377385225449b1
Author: Jakub Jelinek 
Date:   Fri Nov 22 19:52:35 2024 +0100

Add -f{,no-}assume-sane-operators-new-delete options [PR110137]

The following patch adds a new option for optimizations related to
replaceable global operators new/delete.
The option isn't called -fassume-sane-operator-new (which clang++
implements), because
1) clang++ option means something different; initially it was an
   option to add malloc attribute to those declarations (but we have
   malloc attribute on all  calls already unconditionally);
   later it was changed to add noalias attribute rather than malloc,
   whatever it means, but it is certainly about the return value
   from the operator new (whether it can alias with other pointers);
   we already assume malloc-ish behavior that it doesn't alias any
   other pointers
2) the option only affects operator new, we want it affect also
   operator delete
The option basically allows to choose between pre-PR101480 behavior
(now the default, more optimistic) and post-PR101480 behavior (safer
but penalizing most of the code in the wild for rare needs).

I've tried to explain stuff in the documentation too.

2024-11-22  Jakub Jelinek  

PR c++/110137
PR middle-end/101480
gcc/
* doc/invoke.texi (-fassume-sane-operators-new-delete,
-fno-assume-sane-operators-new-delete): Document.
* gimple.cc (gimple_call_fnspec): Handle
-f{,no-}assume-sane-operators-new-delete.
* ipa-inline-transform.cc (inline_call): Also clear
flag_assume_sane_operators_new_delete on caller when inlining
-fno-assume-sane-operators-new-delete callee into
-fassume-sane-operators-new-delete caller.
gcc/c-family/
* c.opt (fassume-sane-operators-new-delete): New option.
gcc/testsuite/
* g++.dg/tree-ssa/pr110137-1.C: New test.
* g++.dg/tree-ssa/pr110137-2.C: New test.
* g++.dg/tree-ssa/pr110137-3.C: New test.
* g++.dg/tree-ssa/pr110137-4.C: New test.
* g++.dg/torture/pr10148.C: Add
-fno-assume-sane-operators-new-delete
as dg-additional-options.
* g++.dg/warn/Warray-bounds-16.C: Revert 2021-11-10 changes.

[Bug c++/101480] [11 Regression] Miscompiled code involving operator new

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

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

--- Comment #27 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:27778979c9a1e32a6ca74e5b5f377385225449b1

commit r15-5595-g27778979c9a1e32a6ca74e5b5f377385225449b1
Author: Jakub Jelinek 
Date:   Fri Nov 22 19:52:35 2024 +0100

Add -f{,no-}assume-sane-operators-new-delete options [PR110137]

The following patch adds a new option for optimizations related to
replaceable global operators new/delete.
The option isn't called -fassume-sane-operator-new (which clang++
implements), because
1) clang++ option means something different; initially it was an
   option to add malloc attribute to those declarations (but we have
   malloc attribute on all  calls already unconditionally);
   later it was changed to add noalias attribute rather than malloc,
   whatever it means, but it is certainly about the return value
   from the operator new (whether it can alias with other pointers);
   we already assume malloc-ish behavior that it doesn't alias any
   other pointers
2) the option only affects operator new, we want it affect also
   operator delete
The option basically allows to choose between pre-PR101480 behavior
(now the default, more optimistic) and post-PR101480 behavior (safer
but penalizing most of the code in the wild for rare needs).

I've tried to explain stuff in the documentation too.

2024-11-22  Jakub Jelinek  

PR c++/110137
PR middle-end/101480
gcc/
* doc/invoke.texi (-fassume-sane-operators-new-delete,
-fno-assume-sane-operators-new-delete): Document.
* gimple.cc (gimple_call_fnspec): Handle
-f{,no-}assume-sane-operators-new-delete.
* ipa-inline-transform.cc (inline_call): Also clear
flag_assume_sane_operators_new_delete on caller when inlining
-fno-assume-sane-operators-new-delete callee into
-fassume-sane-operators-new-delete caller.
gcc/c-family/
* c.opt (fassume-sane-operators-new-delete): New option.
gcc/testsuite/
* g++.dg/tree-ssa/pr110137-1.C: New test.
* g++.dg/tree-ssa/pr110137-2.C: New test.
* g++.dg/tree-ssa/pr110137-3.C: New test.
* g++.dg/tree-ssa/pr110137-4.C: New test.
* g++.dg/torture/pr10148.C: Add
-fno-assume-sane-operators-new-delete
as dg-additional-options.
* g++.dg/warn/Warray-bounds-16.C: Revert 2021-11-10 changes.

[Bug middle-end/117355] [15 regression] firebird miscompiled due to __builtin_dynamic_object_size difference at -O since r15-4396-g72ae35bbc90fea

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #14 from Siddhesh Poyarekar  ---
That should do it.

[Bug middle-end/117355] [15 regression] firebird miscompiled due to __builtin_dynamic_object_size difference at -O since r15-4396-g72ae35bbc90fea

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:684595188dea02d246edb66106d82bb7a9a22d79

commit r15-5597-g684595188dea02d246edb66106d82bb7a9a22d79
Author: Siddhesh Poyarekar 
Date:   Tue Nov 19 22:51:31 2024 -0500

tree-optimization/117355: object size for PHI nodes with negative offsets

When the object size estimate is returned for a PHI node, it is the
maximum possible value, which is fine in isolation.  When combined with
negative offsets however, it may sometimes end up in zero size because
the resultant size was larger than the wholesize, leading
size_for_offset to conclude that there's a potential underflow.  Fix
this by allowing a non-strict mode to size_for_offset, which
conservatively returns the size (or wholesize) in case of a negative
offset.

gcc/ChangeLog:

PR tree-optimization/117355
* tree-object-size.cc (size_for_offset): New argument STRICT,
return SZ if it is set to false.
(plus_stmt_object_size): Adjust call to SIZE_FOR_OFFSET.

gcc/testsuite/ChangeLog:

PR tree-optimization/117355
* g++.dg/ext/builtin-object-size2.C (test9): New test.
(main): Call it.
* gcc.dg/builtin-object-size-3.c (test10): Adjust expected size.

Signed-off-by: Siddhesh Poyarekar 

[Bug c/112841] typeof_unqual is not removing qualifiers from the element type of array types

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:84a335eb4f9641a471184d86900609dd97215218

commit r15-5598-g84a335eb4f9641a471184d86900609dd97215218
Author: Joseph Myers 
Date:   Fri Nov 22 20:33:10 2024 +

c: Fix typeof_unqual handling of qualified array types [PR112841]

As reported in bug 112841, typeof_unqual fails to remove qualifiers
from qualified array types.  In C23 (unlike in previous standard
versions), array types are considered to have the qualifiers of the
element type, so typeof_unqual should remove such qualifiers (and an
example in the standard shows that is as intended).  Fix this by
calling strip_array_types when checking for the presence of
qualifiers.  (The reason we check for qualifiers rather than just
using TYPE_MAIN_VARIANT unconditionally is to avoid, as a quality of
implementation matter, unnecessarily losing typedef information in the
case where the type is already unqualified.)

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/112841

gcc/c/
* c-parser.cc (c_parser_typeof_specifier): Call strip_array_types
when checking for type qualifiers for typeof_unqual.

gcc/testsuite/
* gcc.dg/c23-typeof-4.c: New test.

[Bug c/112841] typeof_unqual is not removing qualifiers from the element type of array types

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
  Known to work||15.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Joseph S. Myers  ---
Fixed for GCC 15.

[Bug target/117726] [avr] better optimize multi-byte shifts

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

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

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

https://gcc.gnu.org/g:939362411d0903542647dae0eff82db10a3ad78a

commit r15-5599-g939362411d0903542647dae0eff82db10a3ad78a
Author: Georg-Johann Lay 
Date:   Thu Nov 21 22:59:14 2024 +0100

AVR: target/117726 - Tweak ashiftrt:SI and lshiftrt:SI insns.

This patch is similar to r15-5569 (tweak ashift:SI) but for
ashiftrt and lshiftrt codes.  It splits constant shift offsets > 16
into a 3-operand byte shift and a 2-operand residual bit shift.
   Moreover, some of the constraint alternatives have been promoted
to 3-operand alternatives regardless of options.  For example,
ashift:HI and lshiftrt:HI can support 3 operands for offsets 9...12
without any overhead.
   Apart from that, it's a bit of code clean up for 2-byte and 4-byte
shift insns:  Use one RTL peephole with any_shift code iterator
instead of 3 individual peepholes.  It also removes some useless
split insns; presumably introduced during the cc0 -> CCmode work.

PR target/117726
gcc/
* config/avr/avr-passes.cc (avr_split_shift): Also handle
ASHIFTRT and LSHIFTRT codes for 4-byte shifts.
(constr_split_shift4): New code_attr.
(avr_emit_shift): Adjust to new shift capabilities.
* config/avr/predicates.md (scratch_or_d_register_operand):
rename to scratch_or_dreg_operand.
* config/avr/avr.md: Same.
(define_peephole2): Write the RTL scratch peephole for 2-byte and
4-byte shifts that generates *sh*3_const insns using code
iterator any_shift.
(*ashlhi3_const_split, *ashrhi3_const_split, *ashrhi3_const_split)
(*lshrsi3_const_split, *lshrhi3_const_split): Remove useless
split insns.
(define_split) [avropt_split_bit_shift]: Add splitters
for 4-byte ASHIFTRT and LSHIFTRT insns using avr_split_shift().
(ashrsi3, *ashrsi3, *ashrsi3_const): Add "r,0,C4a" and "r,r,C4a"
constraint alternatives depending on 2op, 3op.
(lshrsi3, *lshrsi3, *lshrsi3_const): Add "r,0,C4r" and "r,r,C4r"
constraint alternatives depending on 2op, 3op. Add "r,r,C15".
(lshrhi3, *lshrhi3, *lshrhi3_const, ashlhi3, *ashlhi3)
(*ashlhi3_const): Add "r,r,C7c" alternative.
(ashrpsi, *ashrpsi3): Add "r,r,C22" alternative.
(ashlqi, *ashlqi): Turn C06 alternative into "r,r,C06".
* config/avr/constraints.md (C14, C22, C30, C7c): New constraints.
* config/avr/avr.cc (ashlhi3_out, lshrhi3_out)
[case 7, 9, 10, 11, 12]: Support as 3-operand insn.
(lshrsi3_out) [case 15]: Same.
(ashrsi3_out) [case 30]: Same.
(ashrhi3_out) [case 14]: Same.
(ashrqi3_out) [case 6]: Same.
(avr_out_ashrpsi3) [case 22]: Same.
* config/avr/avr.h: Fix comment typo.
* doc/invoke.texi (AVR Options) <-msplit-bit-shift>: Document.

[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align

[tarik.ibrahimovic--- via Gcc-bugs]

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

Tarik Ibrahimović  changed:

   What|Removed |Added

 CC||tarik.ibrahimovic@chili-chi
   ||ps.xyz

--- Comment #2 from Tarik Ibrahimović  ---
Created attachment 59675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59675&action=edit
Preprocessed files concatenated

[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align

[tarik.ibrahimovic--- via Gcc-bugs]

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

--- Comment #3 from Tarik Ibrahimović  ---
Created attachment 59676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59676&action=edit
Disassembly of the program

[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align

[tarik.ibrahimovic--- via Gcc-bugs]

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

--- Comment #4 from Tarik Ibrahimović  ---
Hi,

I'm hereby providing a testcase for the reported bug. 

The bug is that there is a full-word misaligned store to address 0x1517 when
compiler optimizations are used (-02 in specific). In case of no compiler
optimizations there is no misalignment in memory accesses. Instruction causing
the misaligned access is on address 0x42c in the provided disassembly file. 

Be careful, this instruction is first executed without making any misalignment
exceptions, only the second time does it introduce a misalignment issue. Though
this bug is not proved simulating the code in an ISS simulator, this behavior
has been verified in two RISC-V CPUs.

GCC Version details:

Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv64-unknown-elf/14.2.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with:
/home/tibrahimovic/0.git-repo/riscv-gnu-toolchain/gcc/configure
--target=riscv64-unknown-elf --prefix=/opt/riscv --disable-shared
--disable-threads --enable-languages=c,c++ --with-pkgversion=g04696df0963
--with-system-zlib --enable-tls --with-newlib
--with-sysroot=/opt/riscv/riscv64-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=.././gcc --disable-multilib --with-abi=lp64d
--with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=20191213
'CFLAGS_FOR_TARGET=-Os-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os   
-mcmodel=medlow'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.2.0 (g04696df0963)


Exact command run for compilation:

riscv64-unknown-elf-gcc \
-DTCM=1  -DHARVARD=1 \
-march=rv32i \
-mabi=ilp32 \
-mstrict-align \
-mcmodel=medlow \
-Wl,--relax,-Bstatic,-T,$(SW_BLD)/main.lds,-Map,$(SW_BLD)/main.map \
\
-ffreestanding \
-fno-builtin \
-mrelax \
-fno-pic \
-nostdlib \
-static \
-Winline \
-Wno-implicit-int -Wno-implicit-function-declaration \
-g \
-fverbose-asm \
-o $(SW_BLD)/main.elf \
-O2 \
\
$(SW_SRC)/boot_crt.S \
$(SW_APP)/soc.c \
$(SW_APP)/memtest.c \
$(SW_APP)/uart.c \
$(SW_APP)/dac.c \
$(SW_APP)/adc.c \
$(SW_APP)/dhry.h \
$(SW_APP)/dhry_1.c  $(SW_APP)/dhry_2.c -lgcc

Due to the unawareness of where the bug begins, I'm concatenating all .i
preprocessed files in one and presenting them here. I also included the
disassembly which causes the error.

[Bug c++/117153] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_overloaded_fn(tree_node*)

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

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

--- Comment #4 from Marek Polacek  ---
Candidate fix:

--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -1960,7 +1960,10 @@ build_anon_union_vars (tree type, tree object)

   if (processing_template_decl)
ref = build_min_nt_loc (UNKNOWN_LOCATION, COMPONENT_REF, object,
-   DECL_NAME (field), NULL_TREE);
+   (DECL_NAME (field)
+? DECL_NAME (field)
+: make_anon_name ()),
+   NULL_TREE);
   else
ref = build_class_member_access_expr (object, field, NULL_TREE,
  false, tf_warning_or_error);

[Bug fortran/88190] compile_options.allow_std does not allow to distinguish between GFC_STD_GNU and GFC_STD_LEGACY

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #11 from Jerry DeLisle  ---
Easy to add to my list. Not easy to find the time.

[Bug c++/97477] g++ doesn't accept __restrict keyword inside array function parameter

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/107256
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-23

[Bug c/117741] GCC hangs when compiling a specific C file on the trunk version

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-23
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
I have fixed these kind of bugs before. The problem is we are still at the same
token after the error so we just repeat the error message in loop.

[Bug target/90260] function multiversioning: template functions not supported

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

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

Sam James  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   See Also||https://github.com/llvm/llv
   ||m-project/issues/40958,
   ||https://bugs.llvm.org/show_
   ||bug.cgi?id=41614

[Bug target/117603] RISC-V: testsuite: Architecture string mutation is not robust

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Should be resolved on the trunk.

[Bug rtl-optimization/103541] unnecessary spills around const functions calls

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

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

--- Comment #8 from Sam James  ---
All done?

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #22 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-5602-gdf2e832c90fe0915c0ab89e5c115bd0c6536c833
Author: Jeff Law 
Date:   Fri Nov 22 16:11:03 2024 -0700

[RISC-V][PR target/109279] Improve RISC-V constant synthesis

This is a small improvement to the constant synthesis code to capture a
case
appended to PR 109279.

The case in question has the property that the high 32 bits have the value
one
less than the low 32 bits and the highest bit in two low 32 bits is on. 
The
example used in BZ is 0xcccd which comes up computing N/10.

When we construct a constant with bit 31 on, it gets implicitly sign
extended.
So something like 0xcccd when constructed would generate
0xcccd.  The low bits are precisely what we want and the high
bits
are a "-1".  Both properties are useful.

We left shift that value by 32 positions into a temporary and add that
temporary to the original value.  Concretely:

  0xcccd
+ 0xcccd
  --
  0xcccd

Tested in my tester on rv32 and rv64, waiting on the pre-commit tester to
do its thing.

PR target/109279
gcc/
* config/riscv/riscv.cc (riscv_build_integer): Handle another
64-bit
synthesis where high half is one less than the low half and the
32-bit
sign bit is on.

gcc/testsuite/

* gcc.target/riscv/synthesis-16.c: New test.

[Bug tree-optimization/24333] missed div optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Pawel Sikora from comment #6)
> `int f( int x ) { return x / x; }' still not optimized on 4.2/4.3

Fixed by r7-4716-g5b7f6ed0b39936.


(In reply to Andrew Pinski from comment #5)
> x/x is done for fp now.

And redone by r5-4923-ga7f24614b3c58d (and friends).

So closing as fixed for GCC 7.

[Bug c/82892] Spelling hints do not take into account missing compiler options (e.g. -fopenmp)

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Working on a patch for this

[Bug gcov-profile/117740] New: libgcov-util.c should be renamed to libgcov-util.cc

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

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

Bug ID: 117740
   Summary: libgcov-util.c should be renamed to libgcov-util.cc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

libgcov-util.c is actually a C++ source and therefor should be renamed to
libgcov-util.cc.

[Bug target/117737] [15 Regression] GCC: cannot build anymore under CYGWIN, INCLUDE_MEMORY is missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/117737] [15 Regression] GCC: cannot build anymore under CYGWIN, INCLUDE_MEMORY is missing

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

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

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

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

commit r15-5603-gb3f1b9e2aa079f8ec73e3cb48143a16645c49566
Author: Andrew Pinski 
Date:   Fri Nov 22 09:31:44 2024 -0800

build: Remove INCLUDE_MEMORY [PR117737]

Since diagnostic.h is included in over half of the sources, requiring to
`#define INCLUDE_MEMORY`
does not make sense. Instead lets unconditionally include memory in
system.h.

The majority of this patch is just removing `#define INCLUDE_MEMORY` from
the sources which currently
have it.

This should also fix the mingw build issue but I have not tried it.

Bootstrapped and tested on x86_64-linux-gnu.

PR bootstrap/117737
gcc/ada/ChangeLog:

* gcc-interface/misc.cc (INCLUDE_MEMORY): Remove.
* gcc-interface/trans.cc (INCLUDE_MEMORY): Remove.
* gcc-interface/utils.cc (INCLUDE_MEMORY): Remove.

gcc/analyzer/ChangeLog:

* access-diagram.cc (INCLUDE_MEMORY): Remove.
* analysis-plan.cc (INCLUDE_MEMORY): Remove.
* analyzer-language.cc (INCLUDE_MEMORY): Remove.
* analyzer-logging.cc (INCLUDE_MEMORY): Remove.
* analyzer-pass.cc (INCLUDE_MEMORY): Remove.
* analyzer-selftests.cc (INCLUDE_MEMORY): Remove.
* analyzer.cc (INCLUDE_MEMORY): Remove.
* bar-chart.cc (INCLUDE_MEMORY): Remove.
* bounds-checking.cc (INCLUDE_MEMORY): Remove.
* call-details.cc (INCLUDE_MEMORY): Remove.
* call-info.cc (INCLUDE_MEMORY): Remove.
* call-string.cc (INCLUDE_MEMORY): Remove.
* call-summary.cc (INCLUDE_MEMORY): Remove.
* checker-event.cc (INCLUDE_MEMORY): Remove.
* checker-path.cc (INCLUDE_MEMORY): Remove.
* complexity.cc (INCLUDE_MEMORY): Remove.
* constraint-manager.cc (INCLUDE_MEMORY): Remove.
* diagnostic-manager.cc (INCLUDE_MEMORY): Remove.
* engine.cc (INCLUDE_MEMORY): Remove.
* feasible-graph.cc (INCLUDE_MEMORY): Remove.
* infinite-loop.cc (INCLUDE_MEMORY): Remove.
* infinite-recursion.cc (INCLUDE_MEMORY): Remove.
* kf-analyzer.cc (INCLUDE_MEMORY): Remove.
* kf-lang-cp.cc (INCLUDE_MEMORY): Remove.
* kf.cc (INCLUDE_MEMORY): Remove.
* known-function-manager.cc (INCLUDE_MEMORY): Remove.
* pending-diagnostic.cc (INCLUDE_MEMORY): Remove.
* program-point.cc (INCLUDE_MEMORY): Remove.
* program-state.cc (INCLUDE_MEMORY): Remove.
* ranges.cc (INCLUDE_MEMORY): Remove.
* record-layout.cc (INCLUDE_MEMORY): Remove.
* region-model-asm.cc (INCLUDE_MEMORY): Remove.
* region-model-manager.cc (INCLUDE_MEMORY): Remove.
* region-model-reachability.cc (INCLUDE_MEMORY): Remove.
* region-model.cc (INCLUDE_MEMORY): Remove.
* region.cc (INCLUDE_MEMORY): Remove.
* sm-fd.cc (INCLUDE_MEMORY): Remove.
* sm-file.cc (INCLUDE_MEMORY): Remove.
* sm-malloc.cc (INCLUDE_MEMORY): Remove.
* sm-pattern-test.cc (INCLUDE_MEMORY): Remove.
* sm-sensitive.cc (INCLUDE_MEMORY): Remove.
* sm-signal.cc (INCLUDE_MEMORY): Remove.
* sm-taint.cc (INCLUDE_MEMORY): Remove.
* sm.cc (INCLUDE_MEMORY): Remove.
* state-purge.cc (INCLUDE_MEMORY): Remove.
* store.cc (INCLUDE_MEMORY): Remove.
* supergraph.cc (INCLUDE_MEMORY): Remove.
* svalue.cc (INCLUDE_MEMORY): Remove.
* symbol.cc (INCLUDE_MEMORY): Remove.
* trimmed-graph.cc (INCLUDE_MEMORY): Remove.
* varargs.cc (INCLUDE_MEMORY): Remove.

gcc/ChangeLog:

* asan.cc (INCLUDE_MEMORY): Remove.
* attribs.cc (INCLUDE_MEMORY): Remove.
* auto-profile.cc (INCLUDE_MEMORY): Remove.
* calls.cc (INCLUDE_MEMORY): Remove.
* cfganal.cc (INCLUDE_MEMORY): Remove.
* cfgexpand.cc (INCLUDE_MEMORY): Remove.
* cfghooks.cc (INCLUDE_MEMORY): Remove.
* cfgloop.cc (INCLUDE_MEMORY): Remove.
* cgraph.cc (INCLUDE_MEMORY): Remove.
* cgraphclones.cc (INCLUDE_MEMORY): Remove.
* cgraphunit.cc (INCLUDE_MEMORY): Remove.
* collect-utils.cc (INCLUDE_MEMORY): Remove.
* collect2.cc (INCLUDE_MEMORY): Remove.
* common/config/aarch64/aarch64-common.cc (INCLUDE_MEMORY): Remove.
* common/config/arm/arm-common.cc (INCLUDE_MEMORY): Remove.
* common/config/avr/avr-common.cc (INCLUDE_MEMORY): Remove.
* config/aarch64/aarch64-cc-fusion.cc (INCLUDE_MEMORY): Remove.
* config/aarch64/aarch64-early-ra.cc (INCLUDE_MEMORY): Remove.
  

[Bug debug/82630] Bogus DW_AT_GNU_call_site_value

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/117732] [13/14/15 Regression] libsanitizer contains anonymous structs but built with -pedantic

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Target|aarch64-linux-gnu   |aarch64-linux-gnu,
   ||x86_64-linux-gnu
  Known to work||12.2.0
   Target Milestone|14.3|13.4
Summary|[14/15 Regression]  |[13/14/15 Regression]
   |libsanitizer contains   |libsanitizer contains
   |anonymous structs but built |anonymous structs but built
   |with -pedantic  |with -pedantic
  Known to fail||13.2.0

[Bug target/33532] extra escapes in ia64.md after conversion to use braced strings

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

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

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

https://gcc.gnu.org/g:4aa4162e365023896ebf6ed56bf0a00994c50639

commit r15-5606-g4aa4162e365023896ebf6ed56bf0a00994c50639
Author: Andrew Pinski 
Date:   Thu Oct 31 16:00:18 2024 -0700

md-files: Add a note about escaped quotes in braced strings in md files

While looking into PR 33532, It was noted that \" would be treated
still as " for braced strings in the md file. I think that is still
the correct thing to do. So let's just a note to the documentation
on this behavior and NOT change read-md.cc (read_braced_string).
Since this behavior has been there for the last 23 years and only
one person ran into this behavior and helped with the conversion
from using quoted strings to braced strings; that is you just need
to remove the quote around the brace rather than change all of the
code.

Build the documentation to make sure it looks correct.

gcc/ChangeLog:

* doc/rtl.texi: Add a note about quotes in braced strings.

Signed-off-by: Andrew Pinski 

[Bug target/33532] extra escapes in ia64.md after conversion to use braced strings

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
The documentation has been improved.

[Bug middle-end/117742] Inefficient code for __builtin_clear_padding

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Target||aarch64

--- Comment #2 from Andrew Pinski  ---
;; MEM  [(struct A *)&x + 1B] = {};

Is expanded from gimple to RTL using stores rather than using inserts.