[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||116578

--- Comment #1 from Richard Biener  ---
   9.23% 90826  milc_peak.amd64  milc_peak.amd64-m64-gcc42-nn  [.]
mult_su3_na
   7.43% 69530  milc_peak.amd64  milc_peak.amd64-m64-gcc42-nn  [.]
mult_su3_nn
...
   6.11% 60709  milc_base.amd64  milc_base.amd64-m64-gcc42-nn  [.]
mult_su3_na
   5.24% 49015  milc_base.amd64  milc_base.amd64-m64-gcc42-nn  [.]
mult_su3_nn
   5.10% 46303  milc_peak.amd64  milc_peak.amd64-m64-gcc42-nn  [.]
mult_su3_an
...
   0.97%  8860  milc_base.amd64  milc_base.amd64-m64-gcc42-nn  [.]
mult_su3_an

We used to vectorize these but no longer.

m_mat_an.c:39:12: note:   marking hybrid: b0r_89 = b_73(D)->e[0][j_110].real;
m_mat_an.c:39:12: note:   marking hybrid: b0i_90 = b_73(D)->e[0][j_110].imag;
m_mat_an.c:39:12: note:   marking hybrid: b2r_82 = b_73(D)->e[2][j_110].real;
m_mat_an.c:39:12: note:   marking hybrid: b2i_83 = b_73(D)->e[2][j_110].imag;
m_mat_an.c:39:12: note:   === vect_update_vf_for_slp ===
m_mat_an.c:39:12: note:   Loop contains SLP and non-SLP stmts

Note GCC 14 also considers this hybrid.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
[Bug 116578] vectorizer SLP transition issues / dependencies

[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-12-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Testcase:

typedef struct {
double real;
double imag;
} complex;
typedef struct { complex e[3][3]; } su3_matrix;
void mult_su3_an( su3_matrix *a, su3_matrix *b, su3_matrix *c )
{
  int j;
  double a0r,a0i,a1r,a1i,a2r,a2i;
  double b0r,b0i,b1r,b1i,b2r,b2i;
  for(j=0;j<3;j++)
{
  a0r=a->e[0][0].real; a0i=a->e[0][0].imag;
  b0r=b->e[0][j].real; b0i=b->e[0][j].imag;
  a1r=a->e[1][0].real; a1i=a->e[1][0].imag;
  b1r=b->e[1][j].real; b1i=b->e[1][j].imag;
  a2r=a->e[2][0].real; a2i=a->e[2][0].imag;
  b2r=b->e[2][j].real; b2i=b->e[2][j].imag;

  c->e[0][j].real = a0r*b0r + a0i*b0i + a1r*b1r + a1i*b1i + a2r*b2r +
a2i*b2i;
  c->e[0][j].imag = a0r*b0i - a0i*b0r + a1r*b1i - a1i*b1r + a2r*b2i -
a2i*b2r;

  a0r=a->e[0][1].real; a0i=a->e[0][1].imag;
  b0r=b->e[0][j].real; b0i=b->e[0][j].imag;
  a1r=a->e[1][1].real; a1i=a->e[1][1].imag;
  b1r=b->e[1][j].real; b1i=b->e[1][j].imag;
  a2r=a->e[2][1].real; a2i=a->e[2][1].imag;
  b2r=b->e[2][j].real; b2i=b->e[2][j].imag;

  c->e[1][j].real = a0r*b0r + a0i*b0i + a1r*b1r + a1i*b1i + a2r*b2r +
a2i*b2i;
  c->e[1][j].imag = a0r*b0i - a0i*b0r + a1r*b1i - a1i*b1r + a2r*b2i -
a2i*b2r;

  a0r=a->e[0][2].real; a0i=a->e[0][2].imag;
  b0r=b->e[0][j].real; b0i=b->e[0][j].imag;
  a1r=a->e[1][2].real; a1i=a->e[1][2].imag;
  b1r=b->e[1][j].real; b1i=b->e[1][j].imag;
  a2r=a->e[2][2].real; a2i=a->e[2][2].imag;
  b2r=b->e[2][j].real; b2i=b->e[2][j].imag;

  c->e[2][j].real = a0r*b0r + a0i*b0i + a1r*b1r + a1i*b1i + a2r*b2r +
a2i*b2i;
  c->e[2][j].imag = a0r*b0i - a0i*b0r + a1r*b1i - a1i*b1r + a2r*b2i -
a2i*b2r;
}
}

[Bug testsuite/117663] [15 regression] Several "old-style function definition" warnings starting with r15-5327-g55e3bd376b2214

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

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

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

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

commit r15-5862-ge36eae19f3a4cc9e5efa9ebfa31e081c7ee52fdc
Author: Jakub Jelinek 
Date:   Mon Dec 2 13:55:02 2024 +0100

testsuite: Adjust rs6000-ldouble-2.c for switch to -std=gnu23 by default
[PR117663]

-std=gnu23/-std=c23 changes LDBL_EPSILON for IBM long double, see r13-3029
and
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602738.html
for details.

That change even had a note:
"and when we move to a C2x
default, gcc.target/powerpc/rs6000-ldouble-2.c will need an
appropriate option added to keep using an older language version"

The following patch just implements it to fix rs6000-ldouble-2.c
regression.

2024-12-02  Jakub Jelinek  

PR testsuite/117663
* gcc.target/powerpc/rs6000-ldouble-2.c: Add -std=gnu17 to
dg-options.

[Bug testsuite/117663] [15 regression] Several "old-style function definition" warnings starting with r15-5327-g55e3bd376b2214

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug tree-optimization/117876] get_later_stmt used on stmts not in the same BB

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

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

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

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

commit r15-5863-g5ab3f091b3eb42795340d3c9cea8aaec2060693c
Author: Richard Biener 
Date:   Mon Dec 2 11:07:46 2024 +0100

tree-optimization/116352 - SLP scheduling and stmt order

The PR uncovers unchecked constraints on the ability to code-generate
with SLP but also latent issues with regard to stmt order checking
since loop (early-break) and BB (for quite some time) vectorization
are no longer constraint to single-BBs.  In particular get_later_stmt
simply compares UIDs of stmts, but that's only reliable when they
are in the same BB.

For the PR in question the problematical case is demoting a SLP node
to external which fails to check we can actually code generate this
in the way we do (using get_later_stmt).  The following thus adds
checking that we demote to external only when all defs are from
the same BB.

We no longer vectorize gcc.dg/vect/bb-slp-49.c but the testcase was
for a wrong-code issue and the vectorization done is a no-op.

PR tree-optimization/116352
PR tree-optimization/117876
* tree-vect-slp.cc (vect_slp_can_convert_to_external): New.
(vect_slp_convert_to_external): Call it.
(vect_build_slp_tree_2): Likewise.

* gcc.dg/vect/pr116352.c: New testcase.
* gcc.dg/vect/bb-slp-49.c: Remove vectorization check.

[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8

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

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

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

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

commit r15-5863-g5ab3f091b3eb42795340d3c9cea8aaec2060693c
Author: Richard Biener 
Date:   Mon Dec 2 11:07:46 2024 +0100

tree-optimization/116352 - SLP scheduling and stmt order

The PR uncovers unchecked constraints on the ability to code-generate
with SLP but also latent issues with regard to stmt order checking
since loop (early-break) and BB (for quite some time) vectorization
are no longer constraint to single-BBs.  In particular get_later_stmt
simply compares UIDs of stmts, but that's only reliable when they
are in the same BB.

For the PR in question the problematical case is demoting a SLP node
to external which fails to check we can actually code generate this
in the way we do (using get_later_stmt).  The following thus adds
checking that we demote to external only when all defs are from
the same BB.

We no longer vectorize gcc.dg/vect/bb-slp-49.c but the testcase was
for a wrong-code issue and the vectorization done is a no-op.

PR tree-optimization/116352
PR tree-optimization/117876
* tree-vect-slp.cc (vect_slp_can_convert_to_external): New.
(vect_slp_convert_to_external): Call it.
(vect_build_slp_tree_2): Likewise.

* gcc.dg/vect/pr116352.c: New testcase.
* gcc.dg/vect/bb-slp-49.c: Remove vectorization check.

[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #21 from Richard Biener  ---
The specific instance should be mitigated.  The underlying issue that we don't
verify scheduling is still present, of course.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 116352 Summary: [15 regression] ICE when building opencv-4.9.0 (error: 
definition in block 208 does not dominate use in block 188) since 
r15-2820-gab18785840d7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352

   What|Removed |Added

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

[Bug target/117835] wrong code with -O -favoid-store-forwarding -mno-push-args --param=store-forwarding-max-distance=0

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-12-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug target/117229] [15 regression] "libcpp, c, middle-end: Optimize initializers using #embed in C" vs. GCN '-march=gfx908'

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

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

--- Comment #9 from Jakub Jelinek  ---
Any progress on this (i.e. have you been able to narrow it down, perhaps to
newlib strstr implementation)?

[Bug rtl-optimization/117816] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2837: flow control insn inside a basic block with -O -favoid-store-forwarding -fnon-call-exceptions -fno-forward-propagate -fins

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-12-02
 Status|UNCONFIRMED |ASSIGNED

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

[helmut at subdivi dot de via Gcc-bugs]

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

--- Comment #10 from Helmut Grohne  ---
Sam James, please give the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650271.html a try. It
entirely removes LIMITS_H_TEST and defers the check to runtime. To verify the
patch, it is not sufficient to merely build gcc, but also attempt to compile
something that #includes  and observe whether it picks up the right
header. The main idea behind the patch is that the resulting compiler will have
correct search paths and that deferring the lookup to those paths will work
more reliably.

Regarding the need for a proper sysroot, I contend that what is mainly broken
here is the case of absence of a sysroot. It just happens that few people
outside the Debian ecosystem build cross toolchains without a sysroot.

[Bug sanitizer/117881] New: Emit diagnostic note wrt FPs for middle-end warnings with sanitizers

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

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

Bug ID: 117881
   Summary: Emit diagnostic note wrt FPs for middle-end warnings
with sanitizers
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org, dodji at gcc dot gnu.org,
dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org,
kcc at gcc dot gnu.org
  Target Milestone: ---

Prompted by PR117873 but there's a lot of these.

We already have a message in the docs to say that -Werror is a bad idea with
-fsanitize={address,undefined} because FPs are increased. A lot of people don't
seem to realise this.

I suspect it'd save a lot of people time if we emitted a diagnostic note for
these middle-end warnings (-Warray-bounds and so on) when a sanitizer is
enabled to note that there's an increased risk of it being an FP.

david, does this sound reasonable, or a bad idea? I just think it's a shame to
see people waste time on bug reports for these.

[Bug modula2/117555] [15 regression] libgm2 build failure after r15-5081-g95960cd473297c

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

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

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

https://gcc.gnu.org/g:89761f1f03565468eb3b15259f6ad42af0cfe198

commit r14-11019-g89761f1f03565468eb3b15259f6ad42af0cfe198
Author: Gaius Mulley 
Date:   Mon Dec 2 14:34:32 2024 +

[PATCH] PR modula2/117555: Add missing return statement after raise

This patch adds missing return statements after a call to RAISE.  Four
of the modules in libgm2 have procedure functions with missing return
statements.  These errors were exposed after the reimplementation of
parameter declaration patch and triggered by -Wreturn-type.  The patch
also adds exit statements to the M2RTS noreturn functions.

gcc/m2/ChangeLog:

PR modula2/117555
* gm2-libs-iso/EXCEPTIONS.mod (CurrentNumber): Add return
statement.
* gm2-libs-iso/IOChan.mod (ReadResult): Ditto.
(CurrentFlags): Ditto.
(DeviceError): Ditto.
* gm2-libs-iso/IOLink.mod (DeviceTablePtrValue): Ditto.
* gm2-libs-iso/LongConv.mod (ValueReal): Ditto.
* gm2-libs/M2RTS.mod (Halt): Add noreturn attribute.
Add exit (1).
(HaltC): Add exit (1).
* pge-boot/GM2RTS.cc (M2RTS_Halt): Add exit (1).
(M2RTS_HaltC): Ditto.

(cherry picked from commit e77fd9aa89c210db6006fcefb03d80bae0fae851)

Signed-off-by: Gaius Mulley 

[Bug modula2/117555] [15 regression] libgm2 build failure after r15-5081-g95960cd473297c

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

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

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

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

commit r14-11017-g9c926d8b83a8229e0b4335cc78b2bee1b85b58af
Author: Gaius Mulley 
Date:   Mon Dec 2 13:25:14 2024 +

[PATCH] PR modula2/117555: libgm2 build failure after
r15-5081-g95960cd473297c

This patch adds missing return statements to library procedure
functions.  These missing statements occur after a call to RAISE.

gcc/m2/ChangeLog:

PR modula2/117555
* gm2-libs-iso/M2EXCEPTION.mod (M2Exception): Add missing
return statement.
* gm2-libs-iso/RealConv.mod (ValueReal): Ditto.
* gm2-libs-iso/RndFile.mod (StartPos): Ditto.
(EndPos): Ditto.
(NewPos): Ditto.
* gm2-libs-iso/ShortConv.mod (ValueReal): Ditto.
* gm2-libs-iso/WholeConv.mod (ValueInt): Ditto.
(ValueCard): Ditto.

(cherry picked from commit 6d90f5d0ae928320e6e4ce9fce8e658404d8cb72)

Signed-off-by: Gaius Mulley 

[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

--- Comment #5 from Richard Biener  ---
For reference, mult_su3_na is almost the same:

typedef struct {
double real;
double imag;
} complex;
typedef struct { complex e[3][3]; } su3_matrix;
void mult_su3_na( su3_matrix *a, su3_matrix *b, su3_matrix *c )
{
  int i,j;
  double t,ar,ai,br,bi,cr,ci;
  for(i=0;i<3;i++)for(j=0;j<3;j++)
{
  ar=a->e[i][0].real; ai=a->e[i][0].imag;
  br=b->e[j][0].real; bi=b->e[j][0].imag;
  cr=ar*br; t=ai*bi; cr += t;
  ci=ai*br; t=ar*bi; ci -= t;

  ar=a->e[i][1].real; ai=a->e[i][1].imag;
  br=b->e[j][1].real; bi=b->e[j][1].imag;
  t=ar*br; cr += t; t=ai*bi; cr += t;
  t=ar*bi; ci -= t; t=ai*br; ci += t;

  ar=a->e[i][2].real; ai=a->e[i][2].imag;
  br=b->e[j][2].real; bi=b->e[j][2].imag;
  t=ar*br; cr += t; t=ai*bi; cr += t;
  t=ar*bi; ci -= t; t=ai*br; ci += t;

  c->e[i][j].real=cr;
  c->e[i][j].imag=ci;
}
}

[Bug middle-end/117243] [14/15 regression] program crash under -O3 optimization or higher

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

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

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

[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
Note I'm not necessarily suggesting to re-instantiate the unrolling.

[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

--- Comment #4 from Richard Biener  ---
Note m_mat_na.c and m_mat_nn.c are completely unrolled instead and not
vectorized by GCC 14 (nor trunk), still slower as reported (mul_su3_na/nn).
trunk seems to unroll less,

m_mat_nn.c:73:30: optimized: loop with 3 iterations completely unrolled (header
execution count 268435456)

on trunk vs.

m_mat_nn.c:73:30: optimized: loop with 3 iterations completely unrolled (header
execution count 268435456)
m_mat_nn.c:73:14: optimized: loop with 2 iterations completely unrolled (header
execution count 89478486)

on branch.  In particular cunroll on GIMPLE does not unroll the outer loop on
trunk:

Loop 1 iterates 2 times.
Loop 1 iterates at most 2 times.
Loop 1 likely iterates at most 2 times.
size: 104-4, last_iteration: 104-4
  Loop size: 104
  Estimated size after unrolling: 300
Not unrolling loop 1: number of insns in the unrolled sequence reaches --param
max-completely-peeled-insns limit.
Not peeling: upper bound is known so can unroll completely

vs branch:

Loop 1 iterates 2 times.
Loop 1 iterates at most 2 times.
Loop 1 likely iterates at most 2 times.
size: 104-4, last_iteration: 104-4
  Loop size: 104
  Estimated size after unrolling: 200

that's the r15-919-gef27b91b62c3aa change I think.  The heuristic, while
careful, doesn't accurately remember what's "innermost" in this case
though it's still correct that the body isn't simplified by 1/3 - in
this case cunroll has 306 stmts while optimized 276 (FMA disabled),
so that's purely CSE.


Testcase:

typedef struct {
double real;
double imag;
} complex;
typedef struct { complex e[3][3]; } su3_matrix;
void mult_su3_nn( su3_matrix *a, su3_matrix *b, su3_matrix *c )
{
  int i,j;
  double t,ar,ai,br,bi,cr,ci;
  for(i=0;i<3;i++)for(j=0;j<3;j++){

  ar=a->e[i][0].real; ai=a->e[i][0].imag;
  br=b->e[0][j].real; bi=b->e[0][j].imag; 
  cr=ar*br; t=ai*bi; cr -= t;
  ci=ar*bi; t=ai*br; ci += t;

  ar=a->e[i][1].real; ai=a->e[i][1].imag; 
  br=b->e[1][j].real; bi=b->e[1][j].imag;
  t=ar*br; cr += t; t=ai*bi; cr -= t; 
  t=ar*bi; ci += t; t=ai*br; ci += t;

  ar=a->e[i][2].real; ai=a->e[i][2].imag;
  br=b->e[2][j].real; bi=b->e[2][j].imag;
  t=ar*br; cr += t; t=ai*bi; cr -= t;
  t=ar*bi; ci += t; t=ai*br; ci += t;

  c->e[i][j].real=cr;
  c->e[i][j].imag=ci;
  }
}

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=854834

--- Comment #8 from Sam James  ---
The case that I hit it in was with Gentoo's crossdev but we don't use the
Debian multilib layout at all, nor do we patch anything like that in.

There's some analysis at https://bugs.gentoo.org/854834#c0 (which I ended up
rediscovering, only found that bug report this weekend):
"""
My understanding of what GCC (cross-arm-none-eabi/gcc-12.1.1_p20220625) does
when it is building itself is that it attempts to locate an existing limits.h
header, and if it does, it adds some forwarding wrappers around its own
implementation to also include the found limits.h. However, in my case GCC was
not finding newlib's limits.h header.

Debugging the GCC build process led me to the gcc/Makefile in the build
directory. In here, a check is defined by the LIMITS_H_TEST variable. Hacking
together something so I can see what that expands to at the time of the check,
I was able to identify it as the following:

[ -f /usr/arm-none-eabi/usr/include/limits.h ]

Of note, this header _does not_ exist. Newlib installed its header to
/usr/arm-none-eabi/include/limits.h (note the missing usr between the triplet
and the include). In other words, GCC is looking for the header (per the
Makefile) in the cross-compiler-prefix + /usr/include.

I haven't tried it yet, but it may be possible to fix this by telling GCC to
look in cross-compiler-prefix + /include possibly with the use of
--with-native-system-header-dir=/include . Alternatively, if it's possible to
have newlib install to /usr/arm-none-eabi/usr/, for example, GCC should pick up
the headers.

By hacking the Makefile to use `NATIVE_SYSTEM_HEADER_DIR = /include` instead of
`NATIVE_SYSTEM_HEADER_DIR = /usr/include`, I was able to get GCC to find the
newlib limits.h header and set up its own limits.h header properly.
"""

[Bug middle-end/117243] [12/13/14/15 regression] program crash under -O3 optimization or higher since r12-5300-gf98f373dd822b3

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12/13/14/15 regression]|[12/13/14/15 regression]
   |program crash under -O3 |program crash under -O3
   |optimization or higher  |optimization or higher
   ||since
   ||r12-5300-gf98f373dd822b3

--- Comment #14 from Andrew Pinski  ---
And yes it did start with r12-5300-gf98f373dd822b3 in the end. The reason is
before that we didn't allow this structure:
  |
middle-bb -|
  ||
  |   ||   |
phi<1, 2>  |   |
cond   |   |
  ||   |
  |+---|


That is before the middle-bb pred could only be the bb containing the cond.
While afterwards we allowed the middle having branches into it.

[Bug target/116799] [14/15 Regression] Miscompiled code (vim testsuite fails) on s390x at -O2 since r14-2675-gef28aadad6e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
-fdisable-rtl-loop2_unroll or -fdisable-rtl-loop2_unroll make it go away.
So must be interaction of those 2 passes or something similar.

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

[schwab--- via Gcc-bugs]

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

--- Comment #9 from Andreas Schwab  ---
The default value of BUILD_SYSTEM_HEADER_DIR assumes a properly populated
sysroot.

[Bug target/117878] RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

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

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

--- Comment #3 from Robin Dapp  ---
Generally, yes, I guess.  But I'd like to understand better what exactly is
going wrong.  Shouldn't emitting those "pre-RA" insns already be guarded
properly?  I haven't looked into it in detail - isn't there a way to not create
the wrong insn in the first place?

[Bug c/96628] Feature request: __attribute__((no_builtin("Foo")))

[ndesaulniers at google dot com via Gcc-bugs]

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

Nick Desaulniers  changed:

   What|Removed |Added

 CC||keithp at keithp dot com,
   ||ndesaulniers at google dot com

--- Comment #7 from Nick Desaulniers  ---
It looks like Keith took a stab at this back in 2021.  Guessing that didn't
land though.

https://patchwork.sourceware.org/project/gcc/patch/20211102211458.10233-1-kei...@keithp.com/

[Bug target/116447] g++.dg/cpp23/ext-floating13.C fails on Cortex-M55 due to undefined reference

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

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

--- Comment #1 from Richard Earnshaw  ---
How was the compiler configured and what's the full command line used when
building the test?

[Bug c/117878] New: RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

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

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

Bug ID: 117878
   Summary: RISC-V: ICE when build spec17 526.blender_r with -O3
-march=rv64gcv_zvl256b
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

There will be one ICE when build spec2017 with "-O3 -march=rv64gcv_zvl256b",
the ICE may looks like below:

during RTL pass: vsetvl
   
   
 dump file: tmp.c.338r.vsetvl  
   
   
 
blender/source/blender/blenloader/intern/versioning_legacy.c: In function
'blo_do_versions_pre250':  
   
  
blender/source/blender/blenloader/intern/versioning_legacy.c:3624:1: internal
compiler error: Segmentation fault
 3624 | }  
   
   
   | ^ 
   
   
  0x44c9b27
internal_error(char const*, ...)   
   
   
  
/home/pli/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic-global-context.cc:517
   
   
  0x1bc7ba1 crash_signal   
   
   
  
/home/pli/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/toplev.cc:322
   
   
 0x7e2c1004531f ???
   
   
 
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0  
   
   
 0x22e238b riscv_vector::vlmax_avl_type_p(rtx_insn*)   
   
   
 
/home/pli/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/config/riscv/riscv-v.cc:5178
   
   
  0x22e8e2a get_avl
   
   
  
/home/pli/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/config/riscv/riscv-vsetvl.cc:398
   
   
  0x22f13cd vsetvl_info::parse_insn(rtl_ssa::insn_info*)   
   
   

[Bug c++/117827] [12/13/14/15 regression] Incorrect destructor calls after array-new-expression since r12-6328-gbeaee0a871b648

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/117243] [12/13/14/15 regression] program crash under -O3 optimization or higher

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|14.3|12.5

[Bug middle-end/116749] [12/13/14/15 Regression] program crash under -O3 optimization since r12-5300-gf98f373dd822b3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
The analysis in PR 117243 is the same here too. So closing as a dup.

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

[Bug middle-end/117243] [14/15 regression] program crash under -O3 optimization or higher

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Cleaned up #c7:
void
foo (unsigned int a, unsigned char b)
{
  lbl:
  for (b = 0; b <= 7; b++)
{
  unsigned char c[1][1];
  int i, j;
  for (i = 0; i < 1; i++)
for (j = 0; j < 1; j++)
  c[i][j] = 1;
  if (b)
goto lbl;
}
}

int
main ()
{
  foo (1, 2);
}

The crash is because at cunroll time we decide to replace the loop by
__builtin_unreachable ().
And we do so because it sees clearly endless loop which has in loop structures
as upper bound of the number of iterations 8.
>From what I can see, starting with the end of ch2 pass, we have
   [local count: 265]:

   [local count: 268435456]:
lbl:

   [local count: 536870912]:
  # b_1 = PHI <0(3), 1(4)>
  if (b_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
where the innermost loop is just bb 4 and has 8 as upper bound (it comes
originally from the b = 0; b <= 7; b++ loop) and then there is an outer loop
with bb3 and bb4 which doesn't have bounded iterations.

Before phiopt3 it is still:
Loops in function: foo
loop_0 (header = 0, latch = 1)
{
  bb_2 (preds = {bb_0 }, succs = {bb_3 })
  {
 [local count: 265]:

  }
  loop_1 (header = 3, latch = 4
  iterations by profile: 99.92 (unreliable, maybe flat) entry count:265
(estimated locally, freq 1.))
  {
bb_3 (preds = {bb_2 bb_4 }, succs = {bb_4 })
{
   [local count: 268435456]:
lbl:

}
loop_2 (header = 4, latch = 4, finite_p
upper_bound 8
likely_upper_bound 8
iterations by profile: 1.00 (unreliable, maybe flat) entry
count:268435456 (estimated locally, freq 101.))
{
  bb_4 (preds = {bb_3 bb_4 }, succs = {bb_3 bb_4 })
  {
 [local count: 536870912]:
# b_1 = PHI <0(3), 1(4)>
if (b_1 != 0)
  goto ; [50.00%]
else
  goto ; [50.00%]

  }
}
  }
}
which looks correct to me (8 is way too large, that loop loops just once).
Phiopt itself then just changes that

# b_1 = PHI <0(3), 1(4)>
if (b_1 != 0)
to
# b_1 = PHI <0(3), _5(4)>
_5 = b_1 ^ 1;
if (0 != 0)

Then phiopt (well, seems TODO_cleanup_cfg at the end of it) decides to merge
the 2 blocks:
   [local count: 265]:

   [local count: 536870912]:
  # b_1 = PHI <0(2), _5(3)>
  _5 = b_1 ^ 1;
  goto ; [100.00%]
but doesn't adjust appropriately the loop structures:
Loops in function: foo
loop_0 (header = 0, latch = 1)
{
  bb_2 (preds = {bb_0 }, succs = {bb_3 })
  {
 [local count: 265]:

  }
  loop_2 (header = 3, latch = 3, finite_p
  upper_bound 8
  likely_upper_bound 8
  iterations by profile: 200.84 (unreliable) entry count:265 (estimated
locally, freq 1.))
  {
bb_3 (preds = {bb_2 bb_3 }, succs = {bb_3 })
{
   [local count: 536870912]:
  # b_1 = PHI <0(2), _5(3)>
  _5 = b_1 ^ 1;
  goto ; [100.00%]

}
  }
}
which is wrong, because the inner loop is infinite, not finite_p and doesn't
have upper_bound of 8.

Though, I'm afraid I have no idea what should adjust the loop structures here,
whether already phiopt itself which turns the conditional branch into
unconditional, or the following cfgcleanup.

[Bug rtl-optimization/117872] wrong code with -O -maccumulate-outgoing-args --param=store-forwarding-max-distance=1000 -favoid-store-forwarding

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-12-02

[Bug target/117878] RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

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

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

--- Comment #2 from Li Pan  ---
(In reply to Robin Dapp from comment #1)
> Is this related to PR117353?  Seems very similar.

Yes, very similar but ice at different pass.

The similar approach like ix86_pre_reload_split can fix the code example in
PR117353.

Does it reasonable to do riscv_pre_reload_split similar as x86 side?

[Bug modula2/116918] The -fswig option is broken as the generated interface file has incorrect syntax

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

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

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

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

commit r14-11021-gaa38196eb45bfb8a8632381ba3e277deb1b25782
Author: Gaius Mulley 
Date:   Mon Dec 2 20:25:25 2024 +

[PATCH] PR modula2/116918 -fswig correct syntax

This patch fixes the syntax for the generated swig interface file.
The % characters in fprintf require escaping.

gcc/m2/ChangeLog:

PR modula2/116918
* gm2-compiler/M2Swig.mod (AnnotateProcedure): Capitalize
the generated comment, split comment into multiple lines and
terminate the comment with ".  */".
(DoCheckUnbounded): Escape the % character with %%.
(DoWriteFile): Ditto.

(cherry picked from commit fda30a3c8a7c6b06f02be40e3fd0740f893a1b4f)

Signed-off-by: Gaius Mulley 

[Bug libstdc++/69762] Locales are not fully supported on x86_64-apple-darwin13.4.0

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2024-12-02 00:00:00 |

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> Does this still happen with modenr versions of macOS?

* modern

[Bug tree-optimization/117876] New: get_later_stmt used on stmts not in the same BB

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

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

Bug ID: 117876
   Summary: get_later_stmt used on stmts not in the same BB
   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: ---

The vectorizer uses get_later_stmt to order stmts only looking at UID but
UIDs are only comparable when the stmts are in the same BB (or there is
a total order with the particular RPO walk done when computing UIDs).

[Bug target/117874] New: [15 Regression] 17% regression for 433.milc on Zen4

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

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

Bug ID: 117874
   Summary: [15 Regression] 17% regression for 433.milc on Zen4
   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: ---

I am experiencing a 17% runtime regression for 433.milc with -Ofast
-march=native on a Zen4 machine compared to GCC 14.2

[Bug target/117666] Audit the aarch64 builtins for adding leaf and/or nothrow attribute

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> aarch64_init_pragma_builtins
>vamax/vamin

Is fixed by https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670556.html
.

[Bug libstdc++/69762] Locales are not fully supported on x86_64-apple-darwin13.4.0

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||57585
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-12-02

--- Comment #2 from Jonathan Wakely  ---
Does this still happen with modenr versions of macOS?

Bug 57585 might help, by adding a new --enable-clocale option that makes use of
POSIX.1-2008 features which should be present in OS X.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
[Bug 57585] New --enable-clocale model using POSIX 2008

[Bug middle-end/117847] wrong code with __builtin_stdc_rotate_left() on _BitInt of multiple of 64's (limb size) at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug rust/117869] rust fails to build with cargo command error

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also|https://github.com/Rust-GCC |
   |/gccrs/issues/3116  |
 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
(In reply to Eric Gallager from comment #1)
> Last time I had a rust build failure related to cargo, I got pointed to this
> GitHub issue: https://github.com/Rust-GCC/gccrs/issues/3116

That's a different matter, not related to this one here.

[Bug tree-optimization/117875] [15 Regression] 28% regression for 456.hmmer on Zen4 with -Ofast -march=native

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |tree-optimization

--- Comment #1 from Richard Biener  ---
Samples: 530K of event 'cycles:Pu', Event count (approx.): 680879110118 
Overhead   Samples  Command  Shared Object  Symbol  
  51.45%273953  hmmer_peak.amd6  hmmer_peak.amd64-m64-gcc42-nn  [.]
P7Viterbi
  38.49%202968  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.]
P7Viterbi

71 │4135c0┌─  vmovd (%r11,%rdi,4),%xmm3▒
  1361 │4135c6│   vpaddd%xmm3,%xmm0,%xmm0  ▒
 29411 │4135ca│   mov   %rdi,%r8   ▒
15 │4135cd│   vmovd %xmm0,0x4(%rdx,%rdi,4) ▒
  5826 │4135d3│   vmovd (%rax,%rdi,4),%xmm4▒
   981 │4135d8│   vmovd (%r10,%rdi,4),%xmm3◆
   725 │4135de│   vpaddd%xmm3,%xmm4,%xmm3  ▒
  3186 │4135e2│   vmovdqa   0x47346(%rip),%xmm4▒
   787 │4135ea│   vpmaxsd   %xmm4,%xmm3,%xmm3  ▒
  3801 │4135ef│   vpmaxsd   %xmm0,%xmm3,%xmm0  ▒
 28932 │4135f4│   vmovd %xmm0,0x4(%rdx,%rdi,4) ▒
  2073 │4135fa│   inc   %rdi   ▒
  3464 │4135fd├── cmp   %r8,%r9▒
11 │413600└── jne   4135c0 

vs.

   │413aa0┌─  vmovd (%r11,%rdi,4),%xmm3▒
   208 │413aa6│   mov   %rdi,%r8   ▒
   393 │413aa9│   vpaddd%xmm3,%xmm0,%xmm0  ▒
 11199 │413aad│   vmovd %xmm0,0x4(%rdx,%rdi,4) ▒
 11840 │413ab3│   vmovd (%rax,%rdi,4),%xmm5▒
  3889 │413ab8│   vmovd (%r10,%rdi,4),%xmm3▒
   340 │413abe│   vpaddd%xmm3,%xmm5,%xmm3  ▒
  2829 │413ac2│   vmovdqa   0x48656(%rip),%xmm5▒
   720 │413aca│   vpmaxsd   %xmm5,%xmm3,%xmm3  ▒
  1047 │413acf│   vpmaxsd   %xmm0,%xmm3,%xmm0  ▒
 10698 │413ad4│   vmovd %xmm0,0x4(%rdx,%rdi,4) ◆
 12478 │413ada│   inc   %rdi   ▒
  2966 │413add├── cmp   %r8,%r9▒
 1 │413ae0└── jne   413aa0 

that's the scalar epilog, -mtune-ctrl=^avx512_two_epilogues does not help.
The regression also shows up on Icelake.

For some reason we're dealing with branch misses here which we have none
for BASE for the above loop but plenty with PEAK.

This seems to be related to loop splitting - for PEAK we have two
iterating loops while for BASE there's simply fallthru code before.
-fno-split-loops fixes this.

We do not seem to realize that splitting

for (k = 1; k <= M; k++) {
  if (k < M) {
  }
}

has the k == M loop run only once.  That causes us to vectorize the
epilog loop as well.

A simplified testcase looks like

int a[1024], b[1024];
void foo (int M)
{
  for (int k = 1; k <= M; ++k)
{
  a[k] = a[k] + 1;
  if (k < M)
b[k] = b[k] + 1;
}
}

likely "caused" by the loop splitting improvements, though for the simplified
testcase above the generated code is the same.

I'll note that with GCC 14 we do

fast_algorithms.c:145:10: optimized: loop split
fast_algorithms.c:133:19: optimized: Loop 3 distributed: split to 3 loops and 0
library calls.
fast_algorithms.c:133:19: optimized: Loop 5 distributed: split to 2 loops and 0
library calls.
fast_algorithms.c:133:19: optimized: loop vectorized using 64 byte vectors
fast_algorithms.c:133:19: optimized:  loop versioned for vectorization because
of possible aliasing
fast_algorithms.c:133:19: optimized: loop vectorized using 32 byte vectors
fast_algorithms.c:133:19: optimized: loop vectorized using 64 byte vectors
fast_algorithms.c:133:19: optimized:  loop versioned for vectorization because
of possible aliasing
fast_algorithms.c:133:19: optimized: loop vectorized using 32 byte vectors
fast_algorithms.c:133:19: optimized: loop vectorized using 64 byte vectors
fast_algorithms.c:133:19: optimized:  loop versioned for vectorization because
of possible aliasing
fast_algorithms.c:133:19: optimized: loop vectorized using 32 byte vectors
fast_algorithms.c:133:19: optimized: loop with 6 iterations completely unrolled
(header execution count 7100547)
fast_algorithms.c:134:7: optimized: loop turned into non-loop; it never loops
fast_algorithms.c:133:19: optimized: loop with 6 iterations completely unrolled
(header execution count 20163246)
fast_algorithms.c:134:7: optimized: loop turned into non-loop; it never loops
fast_algorithms.c:133:19: optimized: loop with 6 iterations completely unrolled
(header execution count 16089390)
fast_algorithms.c:134:7: optimized: loop turned into non-loop; it never loops

while trunk does

fast_algorithms.c:145:10: optimized: loop split
fast_algorithms.c:133:19: optimized: Loop 3 distributed: split to 3 loops and 0
library calls.

[Bug target/117877] [14/15 Regression] internal compiler error: Floating point exception

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[RISC-V][14/15 Regression]  |[14/15 Regression] internal
   |internal compiler error:|compiler error: Floating
   |Floating point exception|point exception
 Target||riscv
   Target Milestone|--- |14.3

[Bug c++/117825] [12/13/14/15 Regression] ICE on template with -Wformat-security (error reporting routines re-entered.)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The #c0 testcase started to ICE with -std=c++1z with
r7-4431-g4a826ca6feb3c7ec3ef62
The #c3 testcase doesn't ICE for me, neither with trunk nor older snapshots.

[Bug c++/117882] New: SFINAE not respected for array parameters

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

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

Bug ID: 117882
   Summary: SFINAE not respected for array parameters
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

I think this should compile:

```
//constexpr
int i = 0;

template
void f (int(*)[i + I]) = delete;

template
void f (...) { }

void
g ()
{
  f<0>(nullptr);
}
```

but we emit:

bug.C:5:6: error: variable or field ‘f’ declared void
5 | void f (int(*)[i + I]) = delete;
  |  ^
bug.C:5:9: error: expected primary-expression before ‘int’
5 | void f (int(*)[i + I]) = delete;
  | ^~~

[Bug c++/117882] SFINAE not respected for array parameters

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Marek Polacek  ---
I don't think it's a dup

[Bug modula2/116918] The -fswig option is broken as the generated interface file has incorrect syntax

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

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

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

https://gcc.gnu.org/g:58ef1c521c15d3c7755e0f96b472b625122ab609

commit r14-11023-g58ef1c521c15d3c7755e0f96b472b625122ab609
Author: Gaius Mulley 
Date:   Mon Dec 2 21:34:38 2024 +

[PATCH] PR modula2/116918 -fswig correct syntax fixup

This patch adds a missing % escape in DoCheckUnbounded.

gcc/m2/ChangeLog:

PR modula2/116918
* gm2-compiler/M2Swig.mod (DoCheckUnbounded): Escape
the % character used in array_functions with %%.

(cherry picked from commit e2a701cd0419a1898a2a359711572a8bcf4f8eb3)

Signed-off-by: Gaius Mulley 

[Bug c++/117882] SFINAE not respected for array parameters

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #1)
> I don't think it's a dup

PR 24663.

[Bug fortran/117774] ICE passing imaginary part of complex array to assumed rank dummy

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-15, and on 14-branch.  Closing.

Thanks for the report!

[Bug c++/117882] SFINAE not respected for array parameters

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Or PR 11858.

[Bug c++/117882] SFINAE not respected for array parameters

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

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

--- Comment #4 from Marek Polacek  ---
(In reply to Marek Polacek from comment #1)
> I don't think it's a dup

This meant to say "... of PR 24663." because it's not the same problem.

[Bug middle-end/117243] [12/13/14/15 regression] program crash under -O3 optimization or higher since r12-5300-gf98f373dd822b3

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

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

--- Comment #16 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670613.html

[Bug web/117883] New: Build libgdiagnostics documentation as HTML and put on gcc.gnu.org somewhere

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

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

Bug ID: 117883
   Summary: Build libgdiagnostics documentation as HTML and put on
gcc.gnu.org somewhere
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

We're not yet building the libgdiagnostics documentation for the website;
filing this as a reminder to get this done.

[Bug c++/71377] SFINAE expression compiles, but it should not because of 14.5.5p8

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
GCC 15 emits:

71377.C: In instantiation of ‘struct S<1, 1, 0>’:
71377.C:5:12:   required from ‘struct S<0, 1>’
5 | struct S: public S { };
  |^
71377.C:11:17:   required from here
   11 | S<0, 1> c{};
  | ^
71377.C:5:12: error: no type named ‘type’ in ‘struct std::enable_if’
5 | struct S: public S { };
  |^

since r15-2761.

[Bug fortran/117774] ICE passing imaginary part of complex array to assumed rank dummy

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

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

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

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

commit r14-11022-ge81edf9d86f3647dc510784ee49a625dbaded8b5
Author: Harald Anlauf 
Date:   Mon Nov 25 22:55:10 2024 +0100

Fortran: passing inquiry ref of complex array to assumed rank dummy
[PR117774]

PR fortran/117774

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): When passing an array
to an assumed-rank dummy, terminate search for array reference of
actual argument before an inquiry reference (e.g. INQUIRY_RE,
INQUIRY_IM) so that bounds update works properly.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit eff7e72815ada5c70c974d42f6a419e29a03eb27)

[Bug sanitizer/117881] Emit diagnostic note wrt FPs for middle-end warnings with sanitizers

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117873,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84863

--- Comment #1 from Eric Gallager  ---
Yeah I had a similar idea in bug 84863

[Bug libgdiagnostics/117884] New: Wire up libgdiagnostics documentation build to top-level Makefile

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

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

Bug ID: 117884
   Summary: Wire up libgdiagnostics documentation build to
top-level Makefile
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgdiagnostics
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

We have a gcc/doc/libgdiagnostics/Makefile, but AFAIK it's not currently wired
up to the top-level Makefile.am.  Probably should do this so that package
builds can build docs.

[Bug c++/117855] [14/15 Regression] ICE with deduction guides, default template arguments and inherited deduction guides

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #6)
> I suspect this will bisect to r15-2864 (r14-10655) which was done to fix the
> inherited guide.

Yes, correct.

[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |15.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116076
 Blocks||26163


Referenced Bugs:

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

[Bug target/117875] [15 Regression] 28% regression for 456.hmmer on Zen4 with -Ofast -march=native

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||26163
   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106293
   Target Milestone|--- |15.0


Referenced Bugs:

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

[Bug target/117875] New: [15 Regression] 28% regression for 456.hmmer on Zen4 with -Ofast -march=native

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

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

Bug ID: 117875
   Summary: [15 Regression] 28% regression for 456.hmmer on Zen4
with -Ofast -march=native
   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: ---

I am observing a 28% runtime regression for 456.hmmer on Zen4 with -Ofast
-march=native when compared to GCC 14.2.

[Bug target/117877] New: [RISC-V][14/15 Regression] internal compiler error: Floating point exception

[rvismith1115 at gmail dot com via Gcc-bugs]

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

Bug ID: 117877
   Summary: [RISC-V][14/15 Regression] internal compiler error:
Floating point exception
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rvismith1115 at gmail dot com
  Target Milestone: ---

Created attachment 59762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59762&action=edit
reduced testcase

Code:
```
#include 

#define dataLen 100
uint32_t a[dataLen];
uint32_t b[dataLen];

int main(){
  for (int i=0; i 0; avl1 -= vl * 7){
vl = __riscv_vsetvl_e32m1(avl1 / 7);
vuint32m1_t va = __riscv_vle32_v_u32m1(ptr_a, vl);
vuint32m1x7_t vb = __riscv_vlseg7e32_v_u32m1x7(ptr_b, vl);
vb = __riscv_vset_v_u32m1_u32m1x7(vb, 0, va);
ptr_a += vl * 7; ptr_b += vl * 7;
  }
  return 0;
}
```

Crash Message: (when no flags are used)
```
$ /home/compiler/gcc/15-20241117/bin/gcc ice.c
ice.c: In function 'main':
ice.c:15:5: internal compiler error: Floating point exception
   15 | vb = __riscv_vset_v_u32m1_u32m1x7(vb, 0, va);
  | ^~
0x2e9e025 internal_error(char const*, ...)
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/diagnostic-global-context.cc:518
0x139bcc3 crash_signal
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/toplev.cc:323
0x7fc84aa1a31f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x18c5706 poly_int<2u, long>::is_constant() const
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/poly-int.h:560
0x18c5706 poly_int<2u, poly_result::result_kind>::type> exact_div<2u, long, long>(poly_int<2u, long> const&,
poly_int<2u, long> const&)
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/poly-int.h:2172
0x18c5706 riscv_vector::vset_def::check(riscv_vector::function_checker&) const
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/config/riscv/riscv-vector-builtins-shapes.cc:911
0x18c17cc riscv_vector::function_checker::check()
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/config/riscv/riscv-vector-builtins.cc:4415
0x18c17cc riscv_vector::check_builtin_call(unsigned int, vec, unsigned int, tree_node*, unsigned int, tree_node**)
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/config/riscv/riscv-vector-builtins.cc:4792
0xcab74a build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-typeck.cc:3844
0xcedb90 c_parser_postfix_expression_after_primary
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:13372
0xcd1afe c_parser_postfix_expression
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:12923
0xcd6a9a c_parser_unary_expression
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:10364
0xcd868b c_parser_cast_expression
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:10205
0xcd8992 c_parser_binary_expression
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:9973
0xcd9e56 c_parser_conditional_expression
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:9668
0xcda697 c_parser_expr_no_commas
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:9581
0xcda76a c_parser_expr_no_commas
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:9624
0xcdab33 c_parser_expression
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:13512
0xcdb0eb c_parser_expression_conv
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:13572
0xcff29f c_parser_statement_after_labels
   
/home/riscv-files/build-compilers/gcc-15-20241117/gcc/c/c-parser.cc:8080
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.
```

Version info:
```
$ /home/compiler/gcc/15-20241117/bin/gcc --version
gcc () 15.0.0 20241117 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

Re: School Districts Contacts 2024

[Chloe Hall]

Hi there,
We are excited to offer you a comprehensive email list of school districts that 
includes key contact information such as phone numbers, email addresses, 
mailing addresses, company revenue, size, and web addresses. Our databases also 
cover related industries such as:

  *   K-12 schools
  *   Universities
  *   Vocational schools and training programs
  *   Performing arts schools
  *   Fitness centers and gyms
  *   Child care services and providers
  *   Educational publishers and suppliers
If you're interested, we would be happy to provide you with relevant counts and 
a test file based on your specific requirements.
Thank you for your time and consideration, and please let us know if you have 
any questions or concerns.
Thanks,
Chloe Hall

To remove from this mailing reply with the subject line " LEAVE US".

Re: School Districts Contacts 2024

[Chloe Hall]

Hi there,
We are excited to offer you a comprehensive email list of school districts that 
includes key contact information such as phone numbers, email addresses, 
mailing addresses, company revenue, size, and web addresses. Our databases also 
cover related industries such as:

  *   K-12 schools
  *   Universities
  *   Vocational schools and training programs
  *   Performing arts schools
  *   Fitness centers and gyms
  *   Child care services and providers
  *   Educational publishers and suppliers
If you're interested, we would be happy to provide you with relevant counts and 
a test file based on your specific requirements.
Thank you for your time and consideration, and please let us know if you have 
any questions or concerns.
Thanks,
Chloe Hall

To remove from this mailing reply with the subject line " LEAVE US".

[Bug c++/117826] [15 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in hash, at tree.h:5958

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Not including a testcase, as mentioned, it is hard to reduce.
gengtype seems to be quite picky, it doesn't like using nor
simple_hashmap_traits used directly as template parameter.

[Bug tree-optimization/117875] [15 Regression] 28% regression for 456.hmmer on Zen4 with -Ofast -march=native

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||matz at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Manually applying the desired loop splitting in the source also fixes the
observed regression.  It's not exactly known what regressed though.

[Bug middle-end/117243] [12/13/14/15 regression] program crash under -O3 optimization or higher since r12-5300-gf98f373dd822b3

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

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

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

[Bug target/117878] RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

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

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

--- Comment #1 from Robin Dapp  ---
Is this related to PR117353?  Seems very similar.

[Bug c++/117880] [14/15 Regression] ICE with -Wduplicated-branches

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |14.3
   Keywords||ice-on-valid-code
   Last reconfirmed||2024-12-02
   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r14-4793:

commit dad311874ac3b3cf4eca1c04f67cae80c953f7b8
Author: Patrick Palka 
Date:   Fri Oct 20 10:45:00 2023 -0400

c++: remove NON_DEPENDENT_EXPR, part 1


I'll take this.

[Bug c++/117133] [15 regression] Undefined references when building stockfish-17 (incbin)

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
(In reply to Nathaniel Shead from comment #4)

I agree that the standard says this doesn't have language linkage because it
has internal linkage, but that's more about linking with a TU written in
another language.

Handling of internal linkage and interaction with extensions outside the scope
of the standard are matters for the implementation, and it seems undesirable to
break this long-standing behavior (going back to 4.3 at least) that also works
with EDG and Clang.

[Bug tree-optimization/117873] Spurious -Wmaybe-uninitialized warnings with -fsanitize=address -O3 for static const std::regex

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Spurious|Spurious
   |-Wmaybe-uninitialized   |-Wmaybe-uninitialized
   |warnings with -O3 for   |warnings with
   |static const std::regex |-fsanitize=address -O3 for
   ||static const std::regex

--- Comment #1 from Andrew Pinski  ---
 -fsanitize=address is important which is not suprising.

[Bug libgdiagnostics/117879] New: libgdiagnostics and libgccjit installed into */lib directory rather than */lib64 on multilib non-multiarch hosts

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

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

Bug ID: 117879
   Summary: libgdiagnostics and libgccjit installed into */lib
directory rather than */lib64 on multilib
non-multiarch hosts
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgdiagnostics
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

While all other libraries e.g. on x86_64-linux non-multiarch are installed into
$DESTDIR/usr/local/lib64 and $DESTDIR/usr/local/lib is used for -m32 ones,
libgdiagnostics and libgccjit are installed into $DESTDIR/usr/local/lib.
I know handling it is more complicated than target libraries (where we e.g.
know the compiler used to compile it is gcc and can unconditionally use gcc
-print-multi-os-directory, for the host shared libraries we'd probably need to
check for it during configure.

[Bug middle-end/117243] [14/15 regression] program crash under -O3 optimization or higher

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/117880] New: [14/15 Regression] ICE with -Wduplicated-branches

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

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

Bug ID: 117880
   Summary: [14/15 Regression] ICE with -Wduplicated-branches
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This test:

```
template  class Impl;
template  struct Impl {
  void InvokedAfterMove() { false ? void() : void(); }
};
```

results in an ICE:

$ ./cc1plus -quiet bz.C -Wduplicated-branches
bz.C: In member function ‘void Impl::InvokedAfterMove()’:
bz.C:3:51: internal compiler error: Segmentation fault
3 |   void InvokedAfterMove() { false ? void() : void(); }
  |   ^
0x3065397 internal_error(char const*, ...)
/home/mpolacek/src/gcc/gcc/diagnostic-global-context.cc:517
0x11939e4 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:322
0x43ef94 location_wrapper_p(tree_node const*)
/home/mpolacek/src/gcc/gcc/tree.h:4432
0x43f011 tree_strip_any_location_wrapper(tree_node*)
/home/mpolacek/src/gcc/gcc/tree.h:
0xc0b452 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
/home/mpolacek/src/gcc/gcc/fold-const.cc:3176
0xc0ceef operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
/home/mpolacek/src/gcc/gcc/fold-const.cc:3473
0xc11f3c operand_compare::verify_hash_value(tree_node const*, tree_node const*,
unsigned int, bool*)
/home/mpolacek/src/gcc/gcc/fold-const.cc:4233
0xc0b433 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
/home/mpolacek/src/gcc/gcc/fold-const.cc:3173
0xc12057 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
/home/mpolacek/src/gcc/gcc/fold-const.cc:4264
0x41d192 build_conditional_expr(op_location_t const&, tree_node*, tree_node*,
tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/call.cc:6410
0x88c25f build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/typeck.cc:8047
0x6c1214 cp_parser_question_colon_clause
/home/mpolacek/src/gcc/gcc/cp/parser.cc:10866
0x6c141e cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.cc:10932
0x6c178c cp_parser_expression
/home/mpolacek/src/gcc/gcc/cp/parser.cc:11093
0x6c7b6e cp_parser_expression_statement
/home/mpolacek/src/gcc/gcc/cp/parser.cc:13363
0x6c7316 cp_parser_statement
/home/mpolacek/src/gcc/gcc/cp/parser.cc:13140
0x6c84ab cp_parser_statement_seq_opt
/home/mpolacek/src/gcc/gcc/cp/parser.cc:13626
0x6c8025 cp_parser_compound_statement
/home/mpolacek/src/gcc/gcc/cp/parser.cc:13473
0x6e2e2d cp_parser_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.cc:26389
0x6e3173 cp_parser_ctor_initializer_opt_and_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.cc:26440

[Bug middle-end/117243] [14/15 regression] program crash under -O3 optimization or higher

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
I have a fix via disable it for phiopt for this case:
```
  /* Don't `thread` through a loop unless loop opts are done. */
  if (!(cfun->curr_properties & PROP_loop_opts_done)
  && (bb1 == bb || bb2 == bb))
continue;
```

[Bug c/78829] bit-rotten "C99 mode" references in GCC manual

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

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

--- Comment #6 from Eric Gallager  ---
Worth revisiting now that the default C standard is changing again

[Bug middle-end/117243] [13/14/15 regression] program crash under -O3 optimization or higher

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.1.0
Summary|[14/15 regression] program  |[13/14/15 regression]
   |crash under -O3 |program crash under -O3
   |optimization or higher  |optimization or higher
  Known to work|13.3.1  |

--- Comment #13 from Andrew Pinski  ---
Note the testcase in comment #10 also failed for GCC 13.1.0.

And the duplicated PR 116749 was failing in GCC 12 (that one needs -fno-tree-ch
to hit on the trunk).

[Bug target/116799] [14/15 Regression] Miscompiled code (vim testsuite fails) on s390x at -O2 since r14-2675-gef28aadad6e

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

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

--- Comment #7 from Jakub Jelinek  ---
Slightly reduced testcase:
const char *l;

__attribute__((noipa)) void
foo (const char *x, const char *y, int z)
{
  if (x != l + 1 || y != x || z)
__builtin_abort ();
}

__attribute__((noipa)) void
bar (const char *x, char *v)
{
  const char *w = x + __builtin_strlen (x);

  while (x[0] == '*' && x < w - 1)
x++;

  const char *y = w - 1;
  int z = 1;
  if (y >= x)
{
  while (y - x > 0 && *y == '*')
y--;
  z = 0;
}
  int i = 0;
  if (z)
v[i++] = 'a';
  v[i] = 'b';
  foo (x, y, z);
}

int
main ()
{
  char v[2] = { 0 };
  l = "**";
  bar (l, v);
}

[Bug c++/117827] [12/13/14/15 regression] Incorrect destructor calls after array-new-expression since r12-6328-gbeaee0a871b648

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Version|unknown |15.0
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2024-12-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jakub Jelinek  ---
Slightly adjusted testcase:

struct C {
  int c;
  static int d, e;
  C () : c (0) { ++d; }
  C (const C &) = delete;
  C &operator= (const C &) = delete;
  ~C () { ++e; }
};
int C::d, C::e;

C *
foo (C *p)
{
  delete[] p;
  throw 1;
}

int
main ()
{
  try
{
  foo (new C[1] {});
}
  catch (...)
{
}
  if (C::d != C::e)
__builtin_abort ();
}

[Bug rtl-optimization/117836] [meta-bug] favoid-store-forwarding issues

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-12-02
 Status|UNCONFIRMED |ASSIGNED

[Bug target/117874] [15 Regression] 17% regression for 433.milc on Zen4

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

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

--- Comment #3 from Richard Biener  ---
In particular

t.c:11:12: note:   Starting SLP discovery for
t.c:11:12: note: c_84(D)->e[2][j_110].real = _55;
t.c:11:12: note: c_84(D)->e[2][j_110].imag = _66;
t.c:11:12: note:   starting SLP discovery for node 0x51582a0
t.c:11:12: note:   SLP discovery for node 0x51582a0 failed 
t.c:11:12: note:   SLP discovery failed 

we fail to align

  _45 = b0r_89 * a0r_97;
  _46 = b0i_90 * a0i_98;
  _47 = _45 + _46; 
  _48 = a1r_99 * b1r_101;
  _49 = _47 + _48; 
  _50 = a1i_100 * b1i_102;
  _51 = _49 + _50; 
  _52 = b2r_82 * a2r_103;
  _53 = _51 + _52; 
  _54 = b2i_83 * a2i_104;
  _55 = _53 + _54; 
  c_84(D)->e[2][j_110].real = _55;
  _56 = b0i_90 * a0r_97;
  _57 = b0r_89 * a0i_98;
  _59 = a1r_99 * b1i_102;
  _117 = _56 + _59;
  _61 = a1i_100 * b1r_101;
  _63 = b2i_83 * a2r_103;
  _118 = _63 + _117;
  _119 = _118 - _57;
  _64 = _119 - _61;
  _65 = b2r_82 * a2i_104;
  _66 = _64 - _65; 
  c_84(D)->e[2][j_110].imag = _66;

t.c:11:12: note:   pre-sorted chains of plus_expr
plus_expr _54 plus_expr _52 plus_expr _50 plus_expr _48 plus_expr _45 plus_expr
_46
plus_expr _63 plus_expr _56 plus_expr _59 minus_expr _65 minus_expr _61
minus_expr _57
t.c:11:12: note:   starting SLP discovery for node 0x52393c0
t.c:11:12: note:   Build SLP for _54 = b2i_83 * a2i_104;
t.c:11:12: note:   precomputed vectype: vector(8) double
t.c:11:12: note:   nunits = 8
t.c:11:12: note:   Build SLP for _63 = b2i_83 * a2r_103;
t.c:11:12: note:   precomputed vectype: vector(8) double
t.c:11:12: note:   nunits = 8
t.c:11:12: note:   vect_is_simple_use: operand b_73(D)->e[2][j_110].imag, type
of def: internal
t.c:11:12: note:   vect_is_simple_use: operand a_70(D)->e[2][2].imag, type of
def: internal
t.c:11:12: note:   failed to line up SLP graph by re-associating operations in
lanes trying regular discovery

which fails quickly but not exactly verbose because we exceed the discovery
limit here.

One issue this highlights is that when we run into hybrid stmts we fail to
consider single-lane SLP as fallback.  Unfortunately "non-SLP" (aka
interleaving) isn't enough to fix the slowdown.

Doubling the discovery limit allows us to SLP vectorize with AVX but that
isn't faster either.  I don't think we did a particularly good job with
GCC 14 here, it seems we were lucky somehow.

BB vectorization ends up not profitable.

[Bug libstdc++/117560] std::views::zip incompatible with std::filesystem::directory_iterator & std::views::transform

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

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

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

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

commit r14-11029-gedbe164af12589002dec6ac5fe92304567b0ab98
Author: Jonathan Wakely 
Date:   Thu Nov 14 01:14:44 2024 +

libstdc++: Add missing parts of LWG 3480 for directory iterators [PR117560]

It looks like I only read half the resolution of LWG 3480 and decided we
already supported it. As well as making the non-member overloads of end
take their parameters by value, we need some specializations of the
enable_borrowed_range and enable_view variable templates.

libstdc++-v3/ChangeLog:

PR libstdc++/117560
* include/bits/fs_dir.h (enable_borrowed_range, enable_view):
Define specializations for directory iterators, as per LWG 3480.
* testsuite/27_io/filesystem/iterators/lwg3480.cc: New test.

(cherry picked from commit eec6e8923586b9a54e37f32cef112d26d86e8f01)

[Bug libstdc++/117822] [C++23] basic_stacktrace allocator-extended move constructor uses _Allocator instead of _AllocTraits

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:136ff35dd3413ba4b404649e5947682a7f998109

commit r14-11025-g136ff35dd3413ba4b404649e5947682a7f998109
Author: Jonathan Wakely 
Date:   Thu Nov 28 10:24:00 2024 +

libstdc++: Fix allocator-extended move ctor for std::basic_stacktrace
[PR117822]

libstdc++-v3/ChangeLog:

PR libstdc++/117822
* include/std/stacktrace (stacktrace(stacktrace&&, const A&)):
Fix typo in qualified-id for is_always_equal trait.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Test
allocator-extended constructors and allocator propagation.

(cherry picked from commit fe04901737112abb6b1a71fe645f727384dc986a)

[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:

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

commit r14-11034-ga088552e133d2cab903d9b2660c045e18b57ef65
Author: Jonathan Wakely 
Date:   Sun Oct 13 22:28:16 2024 +0100

libstdc++: Implement LWG 3798 for range adaptors [PR106676]

LWG 3798 modified the iterator_category of the iterator types for
transform_view, join_with_view, zip_transform_view and
adjacent_transform_view, to allow the iterator's reference type to be an
rvalue reference.

libstdc++-v3/ChangeLog:

PR libstdc++/106676
* include/bits/iterator_concepts.h (__cpp17_fwd_iterator): Use
is_reference instead of is_value_reference.
rvalue references.
* include/std/ranges (transform_view:__iter_cat::_S_iter_cat):
Likewise.
(zip_transform_view::__iter_cat::_S_iter_cat): Likewise.
(adjacent_transform_view::__iter_cat::_S_iter_cat): Likewise.
(join_with_view::__iter_cat::_S_iter_cat): Likewise.
* testsuite/std/ranges/adaptors/transform.cc: Check
iterator_category when the transformation function returns an
rvalue reference type.

Reviewed-by: Patrick Palka 
(cherry picked from commit 7f65f94917866c6b18d9698eec6451c1bf21e0f9)

[Bug jit/117885] New: Casting element to bitfield subparts can be constant evaluated wrongly.

[i at zhuyi dot fan via Gcc-bugs]

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

Bug ID: 117885
   Summary: Casting element to bitfield subparts can be constant
evaluated wrongly.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: i at zhuyi dot fan
  Target Milestone: ---

Created attachment 59766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59766&action=edit
Reproducer of the jit program

Short Version
=

Miscompilation when accessing subfields of a larger data type by casting it
into bitfields or storing it as a union field aside other bitfields. In the
example program, we supply constant values as expected results of such
operations, and perform a check on the equality. Although the program exits
normally when the symbol is declared with external visibility, the whole
programs folds into a trap (the failure branch) when the symbol is made
internal.


Background and Original Discussion
==

The original discussion was at
https://gist.github.com/SchrodingerZhu/84a334f8666b567800624446d354b568

The background is in mlir-gccjit, we attempt to compile the following program:

```
// RUN: %gccjit-translate -o %t.gimple %s -mlir-to-gccjit-gimple
// RUN: %filecheck --input-file=%t.gimple %s
// RUN: %gccjit-translate -o %t.exe %s -mlir-to-gccjit-executable && chmod +x
%t.exe && %t.exe

!int = !gccjit.int
!ilv = !gccjit.lvalue
!bool = !gccjit.int
!bitfields = !gccjit.struct<"Int" {
#gccjit.field<"A" !int : 17>,
#gccjit.field<"B" !int : 5>,
#gccjit.field<"C" !int : 10>
}>


module attributes { gccjit.opt_level = #gccjit.opt_level,
gccjit.allow_unreachable = true } {
gccjit.func internal @from_int_to_bitfield (!int, !int, !int, !int) {
^entry(%arg0: !ilv, %arg1: !ilv, %arg2: !ilv, %arg3: !ilv):
%0 = gccjit.as_rvalue %arg0 : !ilv to !int
%1 = gccjit.as_rvalue %arg1 : !ilv to !int
%2 = gccjit.as_rvalue %arg2 : !ilv to !int
%3 = gccjit.as_rvalue %arg3 : !ilv to !int
// CHECK: %[[V:[0-9]+]] = bitcast(%{{[0-9]+}}, struct Int);
// CHECK: %{{[0-9]+}} = %[[V]].A:17;
// CHECK: %{{[0-9]+}} = %[[V]].B:5;
// CHECK: %{{[0-9]+}} = %[[V]].C:10;
%4 = gccjit.bitcast %0 : !int to !bitfields
%5 = gccjit.access_field %4[0] : !bitfields -> !int
%6 = gccjit.access_field %4[1] : !bitfields -> !int
%7 = gccjit.access_field %4[2] : !bitfields -> !int
%eq0 = gccjit.compare eq (%5 : !int, %1 : !int) : !bool
%eq1 = gccjit.compare eq (%6 : !int, %2 : !int) : !bool
%eq2 = gccjit.compare eq (%7 : !int, %3 : !int) : !bool
%and0 = gccjit.binary logical_and (%eq0 : !bool, %eq1 : !bool) :
!bool
%and1 = gccjit.binary logical_and (%and0 : !bool, %eq2 : !bool) :
!bool
gccjit.conditional (%and1 : !bool), ^return, ^trap

^return:
gccjit.return

^trap:
gccjit.call builtin @__builtin_trap() : () -> !gccjit.void
gccjit.jump ^trap
}
gccjit.func exported @main() -> !int {
^entry:
%0 = gccjit.const #gccjit.int<-559038737> : !int
%1 = gccjit.const #gccjit.int<-16657> : !int
%2 = gccjit.const #gccjit.int<-10> : !int
%3 = gccjit.const #gccjit.int<-134> : !int
gccjit.call @from_int_to_bitfield(%0, %1, %2, %3) : (!int, !int,
!int, !int) -> ()

%ret = gccjit.const #gccjit.zero : !int
gccjit.return %ret : !int
}
}
```

with
```
./bin/gccjit-translate test.mlir -mlir-to-gccjit-assembly
```
Strangely, everything is folded into
```
.file   "fake.c"
.text
.section.text.unlikely,"ax",@progbits
.globl  main
.type   main, @function
main:
.LFB1:
.cfi_startproc
.L2:
ud2
.cfi_endproc
.LFE1:
.size   main, .-main
.ident  "GCC: (Ubuntu 14-20240412-0ubuntu1) 14.0.1 20240412
(experimental) [master r14-9935-g67e1433a94f]"
.section.note.GNU-stack,"",@progbits
```
If instead of `internal` function kind, `exported` is used, then the program
exits normally.

Gimple Version
==

One can play with mlir-gccjit:
```
./bin/gccjit-translate test.mlir -mlir-to-gccjit-gimple
```

The above program generates the following gimple:

```
struct Int;

struct Int
{
  int A:17;
  int B:5;
  int C:10;
};

static void
from_int_to_bitfield (int %arg0, int %arg1, int %arg2, int %arg3)
{
  int %0;
  int %1;
  int %2;
  int %3;
  struct Int %4;
  int %5;
  int %6;
  int %7;
  bool %8;
  bool %9;
  bool %10;
  bool %11;
  bool %12;

bb0:
  %0 = %arg0;
  %1 = %arg1;
  %2 = %arg2;
  %3 = %arg3;
  %4 = bitcast(%0, struct Int);
  %5 = %4.A:17;
  %6 = %4.B:5;
  %7 = %4.C:10;
  %8 =

[Bug jit/117886] New: GIMPLE pass asan0 no longer works after LIBGCCJIT_ABI_32

[i at zhuyi dot fan via Gcc-bugs]

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

Bug ID: 117886
   Summary: GIMPLE pass asan0 no longer works after
LIBGCCJIT_ABI_32
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: i at zhuyi dot fan
  Target Milestone: ---

Created attachment 59767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59767&action=edit
Github Action Archive

Background
==

I spotted this when building mlir-gccjit on top of commit
73e7f63ffaacf018b1fad331d2369bf891620e97. The relevant change should be
LIBGCCJIT_ABI_32.

The original scene is at:
https://github.com/Lancern/mlir-gccjit/actions/runs/12128538377/job/33815114366?pr=40

In case it get cleared by github (after a long time), I have also attached the
log archive.


Error Message
=
```
Unknown type:
  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fabf2c251f8 precision:64 min  max >
during GIMPLE pass: asan
libgccjit.so:
/home/runner/work/mlir-gccjit/mlir-gccjit/test/compile/deref_chain.mlir:177:5:
error: in tree_type_to_jit_type, at jit/dummy-frontend.cc:1305
0x7fac034bf57c internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x7fac01bb55f7 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1696
0x7fac01bd2169 tree_type_to_jit_type(tree_node*)
../../gcc/gcc/jit/dummy-frontend.cc:1305
0x7fac01bd44c8 jit_langhook_builtin_function
../../gcc/gcc/jit/dummy-frontend.cc:1340
0x7fac021821b8 initialize_sanitizer_builtins()
../../gcc/gcc/sanitizer.def:51
0x7fac021821b8 initialize_sanitizer_builtins()
../../gcc/gcc/asan.cc:3486
0x7fac02189824 asan_instrument
../../gcc/gcc/asan.cc:4351
0x7fac02189824 execute
../../gcc/gcc/asan.cc:4393
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.
```

Gimple Output
=
```
struct memref<133x723x?xf32>;

struct fake;

struct memref<133x723x?xf32>
{
  float * base;
  float * aligned;
  size_t offset;
  size_t[3] sizes;
  size_t[3] strides;
};

struct fake
{
  char c;
  float t;
};

extern void
main ()
{
  size_t %0;
  size_t %1;
  size_t %2;
  size_t %3;
  size_t %4;
  size_t %5;
  size_t %6;
  size_t %7;
  float * %8;
  size_t[3] %9;
  size_t[3] %10;
  size_t %11;
  struct memref<133x723x?xf32> %12;
  float * %13;
  void * %14;

bb0:
  %0 = (size_t)133;
  %1 = (size_t)133;
  %2 = (size_t)723;
  %3 = (size_t)1;
  %4 = %0 * %2;
  %5 = %4 * %1;
  %6 = (size_t)sizeof (float);
  %7 = %6 * %5;
  %8 = bitcast(aligned_alloc ((bitcast(&(*(struct fake *)NULL).t, size_t)), (%7
+ bitcast(&(*(struct fake *)NULL).t, size_t) - (size_t)1 - (%7 +
bitcast(&(*(struct fake *)NULL).t, size_t) - (size_t)1) % bitcast(&(*(struct
fake *)NULL).t, size_t))), float *);
  %9 = (size_t[3]) {%1, %2, %0};
  %10 = (size_t[3]) {%4, %0, %3};
  %11 = (size_t)0;
  %12 = (struct memref<133x723x?xf32>) {.base=%8, .aligned=%8, .offset=%11,
.sizes=%9, .strides=%10};
  %13 = %12.aligned;
  %14 = bitcast(%13, void *);
  (void)free (%14);
  return;
}
```

Reproducer
==

I will attach in a later comment

[Bug jit/117886] GIMPLE pass asan0 no longer works after LIBGCCJIT_ABI_32

[i at zhuyi dot fan via Gcc-bugs]

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

--- Comment #1 from Schrodinger ZHU Yifan  ---
Created attachment 59768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59768&action=edit
Reproducer

[Bug jit/117886] GIMPLE pass asan0 no longer works after LIBGCCJIT_ABI_32

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

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

--- Comment #2 from Andrew Pinski  ---
[s]bitsizetype is not handled in JIT.

[Bug web/117883] Build libgdiagnostics documentation as HTML and put on gcc.gnu.org somewhere

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Mark: is there a script for this somewhere that I need to modify?  I have vague
memories of doing this for the jit docs, but can't find the script anywhere in
the gcc source tree or in the gcc-wwwdocs tree.

[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|15.0|14.3

--- Comment #17 from Jonathan Wakely  ---
Fixed for 14.3 too

[Bug target/117878] RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

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

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

--- Comment #4 from Li Pan  ---
(In reply to Robin Dapp from comment #3)
> Generally, yes, I guess.  But I'd like to understand better what exactly is
> going wrong.  Shouldn't emitting those "pre-RA" insns already be guarded
> properly?  I haven't looked into it in detail - isn't there a way to not
> create the wrong insn in the first place?

I see, I will have a try for this.

[Bug jit/117886] GIMPLE pass asan0 no longer works after LIBGCCJIT_ABI_32

[i at zhuyi dot fan via Gcc-bugs]

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

--- Comment #3 from Schrodinger ZHU Yifan  ---
(In reply to Andrew Pinski from comment #2)
> [s]bitsizetype is not handled in JIT.

I see. But why does it work before?

[Bug web/117883] Build libgdiagnostics documentation as HTML and put on gcc.gnu.org somewhere

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
maintainer-scripts/update_web_docs_git

[Bug jit/107849] All SIMD instrinsics are missing

[i at zhuyi dot fan via Gcc-bugs]

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

Schrodinger ZHU Yifan  changed:

   What|Removed |Added

 CC||i at zhuyi dot fan

--- Comment #2 from Schrodinger ZHU Yifan  ---
I think this is now addressed by the addition of get_target_builtin.

[Bug jit/117886] [15 Regression] GIMPLE pass asan0 no longer works after r15-5528

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Last reconfirmed||2024-12-02
 Ever confirmed|0   |1
Summary|GIMPLE pass asan0 no longer |[15 Regression] GIMPLE pass
   |works after |asan0 no longer works after
   |LIBGCCJIT_ABI_32|r15-5528
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
(In reply to Schrodinger ZHU Yifan from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > [s]bitsizetype is not handled in JIT.
> 
> I see. But why does it work before?

Because tree_type_to_jit_type was only added with r15-5528-g87f0136fa46c9b .

The function seems to be written incorrectly in the first place.

[Bug jit/107849] All SIMD instrinsics are missing

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Schrodinger ZHU Yifan from comment #2)
> I think this is now addressed by the addition of get_target_builtin.

except it broke asan support, see PR 117886.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #18 from Joseph S. Myers  ---
The final normative wording in C23 says "If any additional arguments expand to
include unbalanced parentheses, or a preprocessing token that does not convert
to a token, the
behavior is undefined." (and there is Recommended practice to encourage
diagnosing uses with extra arguments that wouldn't have been valid before C23).
So as QoI we could choose to do something to diagnose that involves expanding
the extra arguments (without requiring them to be valid expressions, as long as
the pp-tokens do convert to tokens without unbalanced parentheses involved).

[Bug c++/117887] [15 regression] ICE when building qtwebengine-6.8.1 (add_extra_args, at cp/pt.cc:13682)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/117887] [15 regression] ICE when building qtwebengine-6.8.1 (add_extra_args, at cp/pt.cc:13682)

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

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

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

[Bug libstdc++/117889] New: [15 regression] Failure to build qtwebengine-6.8.1

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

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

Bug ID: 117889
   Summary: [15 regression] Failure to build qtwebengine-6.8.1
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Building qtwebengine-6.8.1 with GCC 15 gives:
```
[...]
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/type_traits: In
substitution of ‘template  requires !(is_same_v,
typename std::remove_cvref<_It2>::type>) && (is_constructible_v<_Tp, const
_Up&>) && (__construct_from_contained_value<_Up, typename std::remove_cv<
 >::type>) constexpr
std::optional::optional(const std::optional<_Tp>&) [with _Up
= blink::LayoutUnit]’:
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/type_traits:1143:25: 
 required by substitution of ‘template using
std::__is_constructible_impl = std::__bool_constant<__is_constructible(_Tp,
_Args ...)> [with _Tp = blink::LayoutUnit; _Args =
{std::optional&}]’
 1143 |   = __bool_constant<__is_constructible(_Tp, _Args...)>;
  | ^
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/type_traits:1148:12: 
 required from ‘struct std::is_constructible&>’
 1148 | struct is_constructible
  |^~~~
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/type_traits:181:35:  
required by substitution of ‘template
std::__detail::__first_t, typename
std::enable_if<(!(bool)(_Bn::value)), void>::type ...>
std::__detail::__or_fn(int) [with _Bn =
{std::is_constructible&>,
std::is_convertible&, blink::LayoutUnit>,
std::is_constructible >,
std::is_convertible, blink::LayoutUnit>,
std::is_constructible&>, std::is_convertible&, blink::LayoutUnit>,
std::is_constructible
>, std::is_convertible,
blink::LayoutUnit>}]’
  181 | 
__enable_if_t...>;
  |   ^
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/type_traits:199:41:  
required from ‘struct std::__or_&>,
std::is_convertible&, blink::LayoutUnit>,
std::is_constructible >,
std::is_convertible, blink::LayoutUnit>,
std::is_constructible&>, std::is_convertible&, blink::LayoutUnit>,
std::is_constructible
>, std::is_convertible,
blink::LayoutUnit> >’
  199 | : decltype(__detail::__or_fn<_Bn...>(0))
  |~^~~
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/optional:823:45:  
required from ‘constexpr const bool
std::optional::__construct_from_contained_value’
  823 |   = !__converts_from_optional<_Tp, _From>::value;
  |^
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/optional:881:7:  
required by substitution of ‘template  requires
!(is_same_v, typename std::remove_cvref<_It2>::type>) &&
(is_constructible_v<_Tp, const _Up&>) && (__construct_from_contained_value<_Up,
typename std::remove_cv<  >::type>) constexpr
std::optional::optional(const std::optional<_Tp>&) [with _Up
= blink::LayoutUnit]’
  881 |   && __construct_from_contained_value<_Up>
  |  ^
../../../../../qtwebengine-everywhere-src-6.8.1/src/3rdparty/chromium/third_party/blink/renderer/core/layout/table/table_constraint_space_data.h:49:11:
  required from here
   49 |   baseline(baseline),
  |   ^~
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/optional:883:2:  
required by the constraints of ‘template template 
requires !(is_same_v, typename
std::remove_cvref<_It2>::type>) && (is_constructible_v<_Tp, const _Up&>) &&
(__construct_from_contained_value<_Up, typename std::remove_cv<
 >::type>) constexpr std::optional<_Tp>::optional(const
std::optional<_From>&)’
/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15/optional:881:14:
error: satisfaction of atomic constraint ‘__construct_from_contained_value<_Up,
typename std::remove_cv<  >::type> [with _Tp = _Tp; _Up
= _Up]’ depends on itself
  881 |   && __construct_from_contained_value<_Up>
  |  ^
[...]
```

Building with 14 works, as does using 14-preprocessed sources with 15. I'll
attach both.