[Bug libstdc++/115269] New: Hardcoded links in 14.1 docs to pages from release 4.3.2

[unmobile at gmail dot com via Gcc-bugs]

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

Bug ID: 115269
   Summary: Hardcoded links in 14.1 docs to pages from release
4.3.2
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unmobile at gmail dot com
  Target Milestone: ---

A couple spots in the current-version documentation seem to spuriously point to
pages specifically from release version 4.3.2:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/doc/xml/manual/using.xml;hb=b644126237a1aa8599f767a5e0bbada1d7286f44#l10

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/doc/html/manual/using.html;hb=b644126237a1aa8599f767a5e0bbada1d7286f44#l7

These seem to result in this page containing the incorrect link:

https://gcc.gnu.org/onlinedocs/gcc-14.1.0/libstdc++/manual/manual/using.html#manual.intro.using.flags

[Bug other/115268] gcc --target --sysroot support?

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

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

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc/2010-May/192142.html

[Bug other/115268] gcc --target --sysroot support?

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is a huge project. That involves finishing up removing target macros into
target hooks. And a bunch more things. There has been many attempts over the
years in this direction but never finishes up.

[Bug other/115268] New: gcc --target --sysroot support?

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 115268
   Summary: gcc --target --sysroot support?
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

clang supports --target --sysroot which is more convenient for integrating the
concept of native and cross compared to target-gcc.

Is there any possibility of supporting that for gcc?

[Bug tree-optimization/115267] New: Undue warning about undefined behavior in

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

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

Bug ID: 115267
   Summary: Undue warning about undefined behavior in
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobi at gcc dot gnu.org
  Target Milestone: ---

This seems to be a simpler case of PR103724. I originally observed it with 4.9
but was able to reproduce it with gcc 14.

Godbolt: https://godbolt.org/z/6h8bEYsvP


=== Testcase ===
#include 
#include 

double arr[4];

void read(std::istream& is) {
for (unsigned int i = 0; i < 2; ++i) {
for (unsigned int j = i; j < 2; ++j) {
is >> arr[2*i+j];
if (i != j) {
arr[2*j+i] = arr[2*i+j];
}
}
}
}

int main()
{
std::stringstream ss("1 2 3");
read(ss);
return int(arr[0] + arr[1]);
}
===

Gives with -O3 -Wall:
=
:11:39: warning: iteration 4 invokes undefined behavior
[-Waggressive-loop-optimizations]
   11 | arr[2*j+i] = arr[2*i+j];
  |  ~^
:8:36: note: within this loop
8 | for (unsigned int j = i; j < 2; ++j) {
  |   
==
Try as I might, I don't see the undefined behavior, the matrix is also
correctly filled in, no infinite loop obtains.  Signedness of the loop index
doesn't play a role.  The original code used a Eigen::Matrix2d instead of
manually indexing the 2x2 matirx, and then the warning is about iteration 2. 
The stringstream seems to be necessary to confuse the compiler enough, but
maybe there's a way of getting the same behavior with a less complex thing
inside the loop.

[Bug testsuite/114842] rs6000: Adjust some test cases with powerpc_vsx_ok

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r15-886-gd9933e8c72364f001539247c6186ccfb3e7e95ba
Author: Kewen Lin 
Date:   Tue May 28 21:41:12 2024 -0500

testsuite, rs6000: Replace powerpc_vsx_ok with powerpc_vsx [PR114842]

As noted in PR114842, most of the test cases which require
effective target check powerpc_vsx_ok actually care about
if VSX feature is enabled, and they should adopt effective
target powerpc_vsx instead.  Otherwise, when users specifying
extra -mno-vsx like in RUNTESTFLAGS, powerpc_vsx_ok returns
true but the test is tested without VSX and the test case
would fail.  With the commit teaching powerpc_vsx consider
current_compiler_flags, dg-{additional,}-options can be taken
into account when evaluating powerpc_vsx, so this patch also
moves dg-{additional,}-options lines before lines with
dg-require-effective-target to make it effective.

PR testsuite/114842

gcc/testsuite/ChangeLog:

* g++.dg/ext/pr85503.C: Replace powerpc_vsx_ok with powerpc_vsx,
move dg-options and dg-additional-options lines before
dg-require-effective-target lines when it doesn't cause any side
effect like note message.
* g++.dg/pr69667.C: Likewise.
* g++.target/powerpc/altivec-19.C: Likewise.
* g++.target/powerpc/pr101168.C: Likewise.
* g++.target/powerpc/pr65240-1.C: Likewise.
* g++.target/powerpc/pr65240-2.C: Likewise.
* g++.target/powerpc/pr65240-3.C: Likewise.
* g++.target/powerpc/pr65240-4.C: Likewise.
* g++.target/powerpc/pr65242.C: Likewise.
* g++.target/powerpc/pr67211.C: Likewise.
* g++.target/powerpc/pr71294.C: Likewise.
* g++.target/powerpc/pr84279.C: Likewise.
* g++.target/powerpc/pr93974.C: Likewise.
* g++.target/powerpc/undef-bool-1.C: Likewise.
* gcc.dg/gomp/pr82374.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-slp-perm.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-reversed.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-store-2.c: Likewise.
* gcc.dg/vect/pr109011-1.c: Likewise.
* gcc.dg/vect/pr109011-2.c: Likewise.
* gcc.dg/vect/pr109011-3.c: Likewise.
* gcc.dg/vect/pr109011-4.c: Likewise.
* gcc.dg/vect/pr109011-5.c: Likewise.
* gcc.dg/vmx/extract-vsx.c: Likewise.
* gcc.dg/vmx/insert-vsx.c: Likewise.
* gcc.dg/vmx/ld-vsx.c: Likewise.
* gcc.dg/vmx/ldl-vsx.c: Likewise.
* gcc.dg/vmx/merge-vsx.c: Likewise.
* gcc.dg/vmx/splat-vsx.c: Likewise.
* gcc.dg/vmx/st-vsx.c: Likewise.
* gcc.dg/vmx/stl-vsx.c: Likewise.
* gcc.target/powerpc/altivec-2-runnable.c: Likewise.
* gcc.target/powerpc/altivec-37.c: Likewise.
* gcc.target/powerpc/altivec_vld_vst_addr-2.c: Likewise.
* gcc.target/powerpc/amo1.c: Likewise.
* gcc.target/powerpc/atomic-p7.c: Likewise.
* gcc.target/powerpc/atomic-p8.c: Likewise.
* gcc.target/powerpc/atomic_load_store-p8.c: Likewise.
* gcc.target/powerpc/bcd-1.c: Likewise.
* gcc.target/powerpc/bcd-2.c: Likewise.
* gcc.target/powerpc/bcd-3.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-eq-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-eq-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-eq-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-gt-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-gt-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-gt-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-lt-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-lt-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-lt-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-unordered-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-unordered-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-unordered-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-3.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-4.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-5.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-0.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-1.c: Likewise.
* 

[Bug c++/115266] [cwg2389] Agreement of deduced and explicitly-specified variable types

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

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

--- Comment #1 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2389

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #8 from Kewen Lin  ---
Should be fixed on trunk, it's not a regression, but we probably want
backporting this?

[Bug c++/115266] New: [cwg2389] Agreement of deduced and explicitly-specified variable types

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

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

Bug ID: 115266
   Summary: [cwg2389] Agreement of deduced and
explicitly-specified variable types
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 94404
  Target Milestone: ---

GCC rejects this even though it is the defect report makes this valid:
```
  struct S {
static int i;
  };
  auto S::i = 23;
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

Kewen Lin  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-May/651
   ||025.html

--- Comment #18 from Kewen Lin  ---
A formal patch had been sent out as URL field shows, still waiting for review.

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r15-884-ge5fc5d42d25c86ae48178db04ce64d340a834614
Author: Kewen Lin 
Date:   Tue May 28 21:13:40 2024 -0500

rs6000: Don't clobber return value when eh_return called [PR114846]

As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value.  Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.

PR target/114846

gcc/ChangeLog:

* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr114846.c: New test.

[Bug fortran/115265] New: Generic function for constructor not invoked for same-name derived type with procedure pointer component

[mkrupcale at gmail dot com via Gcc-bugs]

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

Bug ID: 115265
   Summary: Generic function for constructor not invoked for
same-name derived type with procedure pointer
component
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkrupcale at gmail dot com
  Target Milestone: ---

Created attachment 58303
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58303=edit
Derived type constructor with or without procedure pointer component test case

The attached code results in a SIGSEGV while trying to assign to y_ when
compiled with gfortran (at least since v5.5) and the type t contains a
procedure pointer component [1]. Instead of calling the generic function
constructor, it seems that the implicit structure constructor is being invoked,
which will not allocate y_. This does not segfault when compiled with Intel ifx
or LLVM flang, with or without the procedure pointer component.

[1] https://godbolt.org/z/Yq81cx4zz

[Bug fortran/102619] [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215 since r9-6493-g0e3088806577e805

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle2 at gmail dot com

--- Comment #7 from Jerry DeLisle  ---
Interestingly, real :: x(:,:) works vs real :: x(..) in the function
declaration with your partial patch.

[Bug bootstrap/115077] bootstrap fails with in-tree isl-0.25/6

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-29

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

[Bug tree-optimization/115004] [11/12/13/14/15 Regression] Missed optimization for Dead Code Elimination

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-29
  Known to fail||8.1.0
  Known to work|8.1.0   |7.5.0
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed. Both front-ends regress in GCC 8. But it was fixed in GCC 14 when
using the C front-end.

[Bug target/67325] Optimize shift (aka subreg) of load to simple load

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #7 from Hongtao Liu  ---
Fixed in GCC15.

[Bug target/67325] Optimize shift (aka subreg) of load to simple load

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:1d6199e5f8c1c08083eeb0279f71333234fe14ad

commit r15-882-g1d6199e5f8c1c08083eeb0279f71333234fe14ad
Author: liuhongt 
Date:   Mon Feb 19 13:57:24 2024 +0800

Reduce cost of MEM (A + imm).

For MEM, rtx_cost iterates each subrtx, and adds up the costs,
so for MEM (reg) and MEM (reg + 4), the former costs 5,
the latter costs 9, it is not accurate for x86. Ideally
address_cost should be used, but it reduce cost too much.
So current solution is make constant disp as cheap as possible.

gcc/ChangeLog:

PR target/67325
* config/i386/i386.cc (ix86_rtx_costs): Reduce cost of MEM (A
+ imm) to "cost of MEM (A)" + 1.

gcc/testsuite/ChangeLog:

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 106265 Summary: RISC-V SPEC2017 507.cactu code bloat due to address 
generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265

   What|Removed |Added

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

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

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

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

Vineet Gupta  changed:

   What|Removed |Added

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

--- Comment #12 from Vineet Gupta  ---
Two years hence and we are a little wiser.

The root-cause of spills is sched1
[PR/114729](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729).

The recent sum of two s12 patch does make the spill codegen better by having 1
less insn to materialize the stack access. And that shaves off 10% of cactu
dynamic icounts which should be enough to close this PR.

commit 4bfc4585c9935fbde75ccf04e44a15d24f42cde9
Author: Vineet Gupta 
Date:   Mon May 13 11:45:55 2024 -0700

RISC-V: avoid LUI based const materialization ... [part of PR/106265]

... if the constant can be represented as sum of two S12 values.
The two S12 values could instead be fused with subsequent ADD insn.
The helps
 - avoid an additional LUI insn
 - side benefits of not clobbering a reg

e.g.
w/o patch w/ patch
long  | |
plus(unsigned long i) | li  a5,4096 |
{ | addia5,a5,-2032 | addi a0, a0, 2047
   return i + 2064;   | add a0,a0,a5| addi a0, a0, 17
} | ret | ret

NOTE: In theory not having const in a standalone reg might seem less
  CSE friendly, but for workloads in consideration these mat are
  from very late LRA reloads and follow on GCSE is not doing much
  currently.

The real benefit however is seen in base+offset computation for array
accesses and especially for stack accesses which are finalized late in
optim pipeline, during LRA register allocation. Often the finalized
offsets trigger LRA reloads resulting in mind boggling repetition of
exact same insn sequence including LUI based constant materialization.

This shaves off 290 billion dynamic instrustions (QEMU icounts) in
SPEC 2017 Cactu benchmark which is over 10% of workload. In the rest of
suite, there additional 10 billion shaved, with both gains and losses
in indiv workloads as is usual with compiler changes.

 500.perlbench_r-0 |  1,214,534,029,025 | 1,212,887,959,387 |
 500.perlbench_r-1 |740,383,419,739 |   739,280,308,163 |
 500.perlbench_r-2 |692,074,638,817 |   691,118,734,547 |
 502.gcc_r-0   |190,820,141,435 |   190,857,065,988 |
 502.gcc_r-1   |225,747,660,839 |   225,809,444,357 | <- -0.02%
 502.gcc_r-2   |220,370,089,641 |   220,406,367,876 | <- -0.03%
 502.gcc_r-3   |179,111,460,458 |   179,135,609,723 | <- -0.02%
 502.gcc_r-4   |219,301,546,340 |   219,320,416,956 | <- -0.01%
 503.bwaves_r-0|278,733,324,691 |   278,733,323,575 | <- -0.01%
 503.bwaves_r-1|442,397,521,282 |   442,397,519,616 |
 503.bwaves_r-2|344,112,218,206 |   344,112,216,760 |
 503.bwaves_r-3|417,561,469,153 |   417,561,467,597 |
 505.mcf_r |669,319,257,525 |   669,318,763,084 |
 507.cactuBSSN_r   |  2,852,767,394,456 | 2,564,736,063,742 | <+ 10.10%
 508.namd_r|  1,855,884,342,110 | 1,855,881,110,934 |
 510.parest_r  |  1,654,525,521,053 | 1,654,402,859,174 |
 511.povray_r  |  2,990,146,655,619 | 2,990,060,324,589 |
 519.lbm_r |  1,158,337,294,525 | 1,158,337,294,529 |
 520.omnetpp_r |  1,021,765,791,283 | 1,026,165,661,394 |
 521.wrf_r |  1,715,955,652,503 | 1,714,352,737,385 |
 523.xalancbmk_r   |849,846,008,075 |   849,836,851,752 |
 525.x264_r-0  |277,801,762,763 |   277,488,776,427 |
 525.x264_r-1  |927,281,789,540 |   926,751,516,742 |
 525.x264_r-2  |915,352,631,375 |   914,667,785,953 |
 526.blender_r |  1,652,839,180,887 | 1,653,260,825,512 |
 527.cam4_r|  1,487,053,494,925 | 1,484,526,670,770 |
 531.deepsjeng_r   |  1,641,969,526,837 | 1,642,126,598,866 |
 538.imagick_r |  2,098,016,546,691 | 2,097,997,929,125 |
 541.leela_r   |  1,983,557,323,877 | 1,983,531,314,526 |
 544.nab_r |  1,516,061,611,233 | 1,516,061,407,715 |
 548.exchange2_r   |  2,072,594,330,215 | 2,072,591,648,318 |
 549.fotonik3d_r   |  1,001,499,307,366 | 1,001,478,944,189 |
 554.roms_r|  1,028,799,739,111 | 1,028,780,904,061 |
 557.xz_r-0|363,827,039,684 |   363,057,014,260 |
 557.xz_r-1|906,649,112,601 |   905,928,888,732 |
 557.xz_r-2|509,023,898,187 |   508,140,356,932 |
 997.specrand_fr   |402,535,577 |   403,052,561 |
 999.specrand_ir   |402,535,577 |   403,052,561 |

This should still be 

[Bug testsuite/114982] New test g++.dg/tree-ssa/cxa_atexit-6.C fails on Darwin.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Status|ASSIGNED|RESOLVED
Version|14.0|15.0
 Resolution|--- |FIXED

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

[Bug target/115169] [14/15 regression] ICE in loongarch bootstrap with checking: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #10 from matoro  ---
(In reply to Xi Ruoyao from comment #9)
> Fixed.
> 
> For the SIGILL issue note that in GCC 14 the default of -march is raised
> from loongarch64 to la64v1.0 which implies LSX.  So I'd suggest to check if
> CPU_HAS_LSX is enabled in the kernel configuration first.

Thank you, that indeed was it!  I'll make sure we get this kernel check sorted
out downstream.

[Bug c++/114245] Defaulted virtual destructors that do no work overwrite the vtable with `-O0`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115050
 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Andrew Pinski  ---
So I just debugged a bug report where the vtable storing in the deconstructor
found the bug in their code (PR 115050). It just happens with that store, it
causes a seg fault at runtime. Without the store the code seemly worked but
only on accident and I had to show that a deconstructor was called twice.

Having this store is definitely helpful for debugging code at -O0 and catching
undefined code early on.

So closing as won't fix. removing the vtable store is an optimization rather
than needed for correctness and having the vtable store there is very very
useful for debugabity of programs.

[Bug target/115263] ARM general-regs-only attribute does not exist?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
   Severity|enhancement |normal

[Bug target/115263] ARM general-regs-only attribute does not exist?

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm*-*-*
   Severity|normal  |enhancement

[Bug c++/115050] Segfault when compiled with -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
There is a copy of Tester involved before F's constructor fully happens so we
call ~FBase (on the unwind) which then calls the bad (vtable) deconstructor.
Why it happens at -O0 only is just by accident. At -O1 we do some
de-virtualization which allows the (right) deconstructor to be called. Note
GCC's VTable::~VTable sets the vtable to be VTable's vtable which exposes the
bug. This only happens at -O0 because at -O1 and above it is considered a dead
store.

This is definitely undefined code without the following change because you
might get ~VTable being called twice.



Note if you change VTable to:
```
class VTable
{
  public:
virtual void func(int x) = 0; // #1 this line affects behavior
virtual ~VTable() {__builtin_printf("~vtable\n");}
};
```

You will see there is 2 calls to ~VTable which is incorrect.



Changing FBase/F to this:
```

struct FBase
{
static constexpr int S = sizeof(void*) + sizeof(VTable);
bool constructed = false;
std::byte _data[S];

~FBase() { if (!constructed) return;
static_cast(static_cast(&_data[0]))->~VTable(); } // #2 this
line affects behavior
};

struct F : FBase
{
template 
F(T&& t) {
static_assert(sizeof(Handler>) <= S);
::new (&_data[0]) Handler>(std::forward(t));
constructed = true;
}

~F() = default;
};
```

Fixes the issue and only one call to ~VTable happens.

[Bug target/115264] New: RISC-V: yet another instance of poor codegen related to stack (glibc tmpnam.c)

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

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

Bug ID: 115264
   Summary: RISC-V: yet another instance of poor codegen related
to stack (glibc tmpnam.c)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, kito.cheng at gmail dot com
  Target Milestone: ---

When working on sum of two s12 optim for function prologue/epilogue noticed
that glibc tempnam.c generates really poor code (as compared to llvm trunk)

--->8-
typedef long unsigned int size_t;

extern int __gen_tempname (char *__tmpl, int __suffixlen, int __flags, int
__kind);
extern char *__strdup (const char *__string);
extern int __path_search (char *__tmpl, size_t __tmpl_len,
 const char *__dir, const char *__pfx, int __try_tempdir);

char *
tempnam (const char *dir, const char *pfx)
{
  char buf[4096];

  if (__path_search (buf, 4096, dir, pfx, 1))
return ((void *)0) ;

  if (__gen_tempname (buf, 0, 0, 2))
return ((void *)0) ;

  return __strdup (buf);
}

--->8-

- There's two copies of epilogue (for no seemingly obvious benefit)
- s0 is needlessly being spilled (likely one of RA passes generate the refs but
subsequent passes failing to eliminate) - sum of two s12 making it worse.

[Bug target/115263] New: ARM general-regs-only attribute does not exist?

[gcc at hazardy dot de via Gcc-bugs]

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

Bug ID: 115263
   Summary: ARM general-regs-only attribute does not exist?
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at hazardy dot de
  Target Milestone: ---

When I add the interrupt attribute to a function I get the warning:
"warning: FP registers might be clobbered despite 'interrupt' attribute:
compile with '-mgeneral-regs-only' [-Wattributes]

The documentation states that there is a general-regs-only attribute, but that
does not compile, converting it to general_regs_only doesn't help. Using
target("general-regs-only") may or may not work, but does not silence the
warning.

See https://gcc.godbolt.org/z/7Kf3zobWz

[Bug rtl-optimization/115182] [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

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

commit r15-877-g84b4ed45ea81ed5c4fb656a17846b26071c23e7d
Author: Hans-Peter Nilsson 
Date:   Tue May 28 23:15:57 2024 +0200

resource.cc (mark_target_live_regs): Don't look past target insn, PR115182

The PR115182 regression is that a delay-slot for a conditional branch,
is no longer filled with an insn that has been "sunk" because of
r15-518-g99b1daae18c095, for cris-elf w. -O2 -march=v10.

There are still sufficient "nearby" dependency-less insns that the
delay-slot shouldn't be empty.  In particular there's one candidate in
the loop, right after an off-ramp branch, off the loop: a move from
$r9 to $r3.

beq .L2
nop
move.d $r9,$r3

But, the resource.cc data-flow-analysis incorrectly says it collides
with registers "live" at that .L2 off-ramp.  The off-ramp insns
(inlined from simple_rand) look like this (left-to-right direction):

.L2:
move.d $r12,[_seed.0]
move.d $r13,[_seed.0+4]
ret
movem [$sp+],$r8

So, a store of a long long to _seed, a return instruction and a
restoring multi-register-load of r0..r8 (all callee-saved registers)
in the delay-slot of the return insn.  The return-value is kept in
$r10,$r11 so in total $r10..$r13 live plus the stack-pointer and
return-address registers.  But, mark_target_live_regs says that
$r0..$r8 are also live because it *includes the registers live for the
return instruction*!  While they "come alive" after the movem, they
certainly aren't live at the "off-ramp" .L2 label.

The problem is in mark_target_live_regs: it consults a hash-table
indexed by insn uid, where it tracks the currently live registers with
a "generation" count to handle when it moves around insn, filling
delay-slots.  As a fall-back, it starts with registers live at the
start of each basic block, calculated by the comparatively modern df
machinery (except that it can fail finding out which basic block an
insn belongs to, at which times it includes all registers film at 11),
and tracks the semantics of insns up to each insn.

You'd think that's all that should be done, but then for some reason
it *also* looks at insns *after the target insn* up to a few branches,
and includes that in the set of live registers!  This is the code in
mark_target_live_regs that starts with the call to
find_dead_or_set_registers.  I couldn't make sense of it, so I looked
at its history, and I think I found the cause; it's a thinko or
possibly two thinkos.  The original implementation, gcc-git-described
as r0-97-g9c7e297806a27f, later moved from reorg.c to resource.c in
r0-20470-gca545bb569b756.

I believe the "extra" lookup was intended to counter flaws in the
reorg.c/resource.c register liveness analysis; to inspect insns along
the execution paths to exclude registers that, when looking at
subsequent insns, weren't live.  That guess is backed by a sentence in
the updated (i.e. deleted) part of the function head comment for
mark_target_live_regs: "Next, scan forward from TARGET looking for
things set or clobbered before they are used.  These are not live."
To me that sounds like flawed register-liveness data.

An epilogue expanded as RTX (i.e. not just assembly code emitted as
text) is introduced in basepoints/gcc-0-1334-gbdac5f5848fb, so before
that time, nobody would notice that saved registers were included as
live registers in delay-slots in "next-to-last" basic blocks.

Then in r0-24783-g96e9c98d59cc40, the intersection ("and") was changed
to a union ("or"), i.e. it added to the set of live registers instead
of thinning it out.  In the gcc-patches archives, I see the patch
submission doesn't offer a C test-case and only has RTX snippets
(apparently for SPARC).  The message does admit that the change goes
"against what the comments in the code say":
https://gcc.gnu.org/pipermail/gcc-patches/1999-November/021836.html
It looks like this was related to a bug with register liveness info
messed up when moving a "delay-slotted" insn from one slot to another.
But, I can't help but thinking it's just papering over a register
liveness bug elsewhere.

I think, with a reliable "DF_LR_IN", the whole thing *after* tracking
from start-of-bb up to the target insn should be removed; thus.

This patch also removes the now-unused find_dead_or_set_registers
function.

At r15-518, it fixes the issue for CRIS and improves coremark scores
at -O2 -march=v10 a tiny bit (about 0.05%).

PR rtl-optimization/115182
* resource.cc (mark_target_live_regs): Don't look for

[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||9.5.0
   Last reconfirmed||2024-05-28
   Priority|P3  |P4
  Known to fail||10.5.0, 11.4.0, 12.3.0,
   ||13.3.0, 14.1.0, 15.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||wrong-code

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

The tree-dump suggests that the unpack frees the component arrays data, idata
so that the final prints access freed memory.

In the testcase this only happens for the explicit-size dummies when they
are intent(inout), but not for intent(in).

[Bug c++/115048] warning "operator delete called on pointer '' with nonzero offset"

[urisimchoni at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uri Simchoni  ---
Is this a false-positive of the compiler or an actual issue with libstdc++ or
the compiler compiles it?

[Bug fortran/102619] [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215 since r9-6493-g0e3088806577e805

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 58302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58302=edit
Partial patch

This change prevents the ICE and leads to a correct shape of the function
result for the following testcase:

program p
  implicit none
  real :: w(2,3)
  real, allocatable :: y(:)
  y = h(w)
  print *, size (y) ! Should print 6
  print *, y
  deallocate (y)
contains
  function h(x) result (g)
real :: x(..)
real :: g(product(shape(x)))
integer :: i
print *, shape (x)
print *, size (g)
g = [(real(i),i=1,size(g))]
print *, g
  end
end

After the patch this prints:

   2   3
   6
   1.   2.   3.   4.  
5.   6.
   1
   1.

So the function result is not allocated correctly.

[Bug c++/109396] Winit-self doesn't warn when std::move()-d

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/109396] Winit-self doesn't warn when std::move()-d

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/109396] Winit-self doesn't warn when std::move()-d

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r15-871-gefaaae49b307fcc7e771518da3edae49f92c19db
Author: Marek Polacek 
Date:   Thu May 23 15:49:42 2024 -0400

c++: extend -Wself-move for mem-init-list [PR109396]

We already warn for:

  x = std::move (x);

which triggers:

  warning: moving 'x' of type 'int' to itself [-Wself-move]

but bug 109396 reports that this doesn't work for a
member-initializer-list:

  X() : x(std::move (x))

so this patch amends that.

PR c++/109396

gcc/cp/ChangeLog:

* cp-tree.h (maybe_warn_self_move): Declare.
* init.cc (perform_member_init): Call maybe_warn_self_move.
* typeck.cc (maybe_warn_self_move): No longer static.  Change the
return type to bool.  Also warn when called from
a member-initializer-list.  Drop the inform call.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wself-move2.C: New test.

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368) since r15-80-g0ade358cd72ffa

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r15-870-g5ada486079d6aa20c64985a20681573f4ac1c86e
Author: Andrew MacLeod 
Date:   Mon May 27 11:00:57 2024 -0400

Do not invoke SCEV if it will use a different range query.

SCEV always uses the current range_query object.
Ranger's cache uses a global value_query when propagating cache values to
avoid re-invoking ranger during simple vavhe propagations.
when folding a PHI value, SCEV can be invoked, and since it alwys uses
the current range_query object, when ranger is active this causes the
undesired re-invoking of ranger during cache propagation.

This patch checks to see if the fold_using_range specified range_query
object is the same as the one SCEV uses, and does not invoke SCEV if
they do not match.

PR tree-optimization/115221
gcc/
* gimple-range-fold.cc (range_of_ssa_name_with_loop_info): Do
not invoke SCEV is range_query's do not match.
gcc/testsuite/
* gcc.dg/pr115221.c: New.

[Bug c++/114707] Mark TARGET_EXPRs for function arguments eliding

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Done.

[Bug c++/114707] Mark TARGET_EXPRs for function arguments eliding

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r15-868-g5bc731b83b51910dc7f7cacddb4257a16d62ee38
Author: Marek Polacek 
Date:   Wed May 22 16:28:02 2024 -0400

c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

Coming back to our discussion in
:
TARGET_EXPRs that initialize a function argument are not marked
TARGET_EXPR_ELIDING_P even though gimplify_arg drops such TARGET_EXPRs
on the floor.  To work around it, I added a pset to
replace_placeholders_for_class_temp_r, but it would be best to just rely
on TARGET_EXPR_ELIDING_P.

PR c++/114707

gcc/cp/ChangeLog:

* call.cc (convert_for_arg_passing): Call set_target_expr_eliding.
* typeck2.cc (replace_placeholders_for_class_temp_r): Don't use
pset.
(digest_nsdmi_init): Call cp_walk_tree_without_duplicates instead
of
cp_walk_tree.

Reviewed-by: Jason Merrill 

[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095

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

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

Dimitar Dimitrov  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Dimitar Dimitrov  ---
Closing

[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095

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

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

Dimitar Dimitrov  changed:

   What|Removed |Added

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

--- Comment #3 from Dimitar Dimitrov  ---
Fixed in GNU linker by
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a606ff9b090a88b19eaf95914618274041f164c4

[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be fixed by the above patch.  As noted above, I was able to bootstrap
with this patch on cfarm119.

Marking this as resolved; thanks for your help.

[Bug target/105733] riscv: Poor codegen for large stack frames

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

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

Vineet Gupta  changed:

   What|Removed |Added

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

--- Comment #6 from Vineet Gupta  ---
Fixed with aforementioned commit for gcc-15.

[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above patch; marking as resolved.

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #14 from Uroš Bizjak  ---
Also fixed for 11.5+ and 12.4+.

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Uros Bizjak :

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

commit r11-11454-gd8985ea10c911c994e00dbd6a08dcae907ebc1f7
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.c (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

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

commit r12-10477-gda9b7a507ef38287cc16bc88e808293019f9f531
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)

[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:2dbb1c124c1e585dc413132d7a8d4be62c6b7baa

commit r15-866-g2dbb1c124c1e585dc413132d7a8d4be62c6b7baa
Author: David Malcolm 
Date:   Tue May 28 13:04:26 2024 -0400

diagnostics: disable localization of events in selftest paths [PR115203]

gcc/ChangeLog:
PR analyzer/115203
* diagnostic-path.h
(simple_diagnostic_path::disable_event_localization): New.
(simple_diagnostic_path::m_localize_events): New field.
* diagnostic.cc
(simple_diagnostic_path::simple_diagnostic_path): Initialize
m_localize_events.
(simple_diagnostic_path::add_event): Only localize fmt if
m_localize_events is true.
* tree-diagnostic-path.cc
(test_diagnostic_path::test_diagnostic_path): Call
disable_event_localization.

Signed-off-by: David Malcolm 

[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r15-865-gb544ff88560e100e53ed8966d38f172c5bafce8d
Author: David Malcolm 
Date:   Tue May 28 13:04:25 2024 -0400

Fix bootstrap on AIX by adding c-family/c-type-mismatch.cc [PR115167]

PR bootstrap/115167 reports a bootstrap failure on AIX triggered by
r15-636-g770657d02c986c whilst building f951 in stage 2, due to
the linker not being able to find symbols for:

  vtable for range_label_for_type_mismatch
  range_label_for_type_mismatch::get_text(unsigned int) const

The only users of the class range_label_for_type_mismatch are in the
C/C++ frontends, each of which supply their own implementation of:

  range_label_for_type_mismatch::get_text(unsigned int) const

i.e. we had a cluster of symbols that was disconnnected from any
users on f951.

The above patch added a new range_label::get_effects vfunc to the
base class.  My hunch is that we were getting away with not defining
the symbol for Fortran with AIX's linker before (since none of the
users are used), but adding the get_effects vfunc has somehow broken
things (possibly because there's an empty implementation in the base
class in the *header*).

The following patch moves all of the code in
gcc/gcc-rich-location.[cc,h,o} defining and using
range_label_for_type_mismatch to a new
gcc/c-family/c-type-mismatch.{cc,h,o}, to help the linker ignore this
cluster of symbols when it's disconnected from users.

I was able to reproduce the failure without the patch, and then
successfully bootstrap with this patch on powerpc-ibm-aix7.3.1.0
(cfarm119).

gcc/ChangeLog:
PR bootstrap/115167
* Makefile.in (C_COMMON_OBJS): Add c-family/c-type-mismatch.o.
* gcc-rich-location.cc
(maybe_range_label_for_tree_type_mismatch::get_text): Move to
c-family/c-type-mismatch.cc.
(binary_op_rich_location::binary_op_rich_location): Likewise.
(binary_op_rich_location::use_operator_loc_p): Likewise.
* gcc-rich-location.h (class range_label_for_type_mismatch):
Likewise.
(class maybe_range_label_for_tree_type_mismatch): Likewise.
(class op_location_t): Likewise for forward decl.
(class binary_op_rich_location): Likewise.

gcc/c-family/ChangeLog:
PR bootstrap/115167
* c-format.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
* c-type-mismatch.cc: New file, taking material from
gcc-rich-location.cc.
* c-type-mismatch.h: New file, taking material from
gcc-rich-location.h.
* c-warn.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".

gcc/c/ChangeLog:
PR bootstrap/115167
* c-objc-common.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
* c-typeck.cc: Likewise.

gcc/cp/ChangeLog:
PR bootstrap/115167
PR bootstrap/115167
* call.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
* error.cc: Likewise.
* typeck.cc: Likewise.

Signed-off-by: David Malcolm 

[Bug fortran/115150] [12/13/14 Regression] SHAPE of zero-sized array yields a negative value

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #7 from Tobias Burnus  ---
FIXED on all affected branches.

[Bug fortran/115150] [12/13/14 Regression] SHAPE of zero-sized array yields a negative value

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Tobias Burnus
:

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

commit r12-10476-ge0b2c4f90f908a9bca4038c7ae0d8ca6ee157d8f
Author: Tobias Burnus 
Date:   Mon May 20 08:34:48 2024 +0200

Fortran: Fix SHAPE for zero-size arrays

PR fortran/115150

gcc/fortran/ChangeLog:

* trans-intrinsic.cc (gfc_conv_intrinsic_bound): Fix SHAPE
for zero-size arrays

gcc/testsuite/ChangeLog:

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

(cherry picked from commit b701306a9b38bd74cdc26c7ece5add22f2203b56)

[Bug testsuite/115262] New: [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1

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

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

Bug ID: 115262
   Summary: [15 regression] gcc.target/powerpc/pr66144-3.c  fails
after r15-831-g05daf617ea22e1
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:05daf617ea22e1d818295ed2d037456937e23530, r15-831-g05daf617ea22e1
make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr66144-3.c"
FAIL: gcc.target/powerpc/pr66144-3.c scan-assembler \\mxxsel\\M

This is probably just a test case that needs assembler instruction counts
updated.

commit 05daf617ea22e1d818295ed2d037456937e23530 (HEAD)
Author: Jeff Law 
Date:   Sat May 25 12:39:05 2024 -0600

[committed] [v2] More logical op simplifications in simplify-rtx.cc

[Bug c++/115052] rejected lambda while capturing a constexpr array

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC rejects it also with the similar error message as GCC:
(5): error C3493: 'a2' cannot be implicitly captured because no default
capture mode has been specified


While EDG accepts it.

So it is 2 compilers that accept it and 2 compilers that reject it.

[Bug c++/107361] Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?

[pkasting at google dot com via Gcc-bugs]

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

Peter Kasting  changed:

   What|Removed |Added

 CC||pkasting at google dot com

--- Comment #3 from Peter Kasting  ---
This warning fired in Chromium on safe code that clang doesn't warn about, for
similar reasons as the reporter here complains about.

I think the linked patch was too aggressive. At the very least, `memcpy()` from
some instance `t1` of a `T` into another instance `t2` of a `T` should only
require that `T` is trivially-copyable. Since we can assume that `t1`'s
invariants held before the statement, after it `t2`'s invariants must hold (or
the coder should not have allowed trivial copyability, which is a distinct
bug).

I do agree with the original patch author that `memset()` probably requires the
type to be trivial rather than just trivially-copyable.

We can work around with cast-to-`void*` prior to `memcpy()`, which feels
unfortunate given that the intent of that is less obvious to a reader, and it's
probably easier to introduce dangerous behavior later.

[Bug target/112434] unexpected error when compiling for riscv64: invalid 'asm': invalid use of '%c'

[rsworktech at outlook dot com via Gcc-bugs]

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

--- Comment #3 from Levi Zim  ---
This bug still occurs in gcc 14.1.1

[Bug fortran/115150] [12/13/14 Regression] SHAPE of zero-sized array yields a negative value

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:3185cfe495944e6e5d000ccd820bed2e6f10cd6c

commit r13-8805-g3185cfe495944e6e5d000ccd820bed2e6f10cd6c
Author: Tobias Burnus 
Date:   Mon May 20 08:34:48 2024 +0200

Fortran: Fix SHAPE for zero-size arrays

PR fortran/115150

gcc/fortran/ChangeLog:

* trans-intrinsic.cc (gfc_conv_intrinsic_bound): Fix SHAPE
for zero-size arrays

gcc/testsuite/ChangeLog:

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

(cherry picked from commit b701306a9b38bd74cdc26c7ece5add22f2203b56)

[Bug target/115258] [14/15 Regression] register swaps for vector perm in some cases after r14-6290

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

Though the register allocation before was also just "lucky".
(define_insn_and_split "aarch64_combinev16qi"
  [(set (match_operand:V2x16QI 0 "register_operand" "=w")
(unspec:V2x16QI [(match_operand:V16QI 1 "register_operand" "w")
 (match_operand:V16QI 2 "register_operand" "w")]
UNSPEC_CONCAT))]
  "TARGET_SIMD"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  aarch64_split_combinev16qi (operands);
  DONE;
}
[(set_attr "type" "multiple")]
)


It seems like for little-endian the constraint on 1 should include 0. But I
could be wrong.

[Bug rtl-optimization/115261] New: FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c

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

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

Bug ID: 115261
   Summary: FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

After r11-5821-gebdfd1606da6b5 multiple BIT_INSERT_EXPRs are vectorized which
as a side-effect leads to the usage of V2SI which seems to be the culprit of an
extra stack slot.  For s390/vector/vec-abi-vararg-1.c we end up with

(insn 11 10 12 2 (set (subreg:V2SI (reg:V4SI 73 [ _3 ]) 0)
(plus:V2SI (mem:V2SI (plus:DI (reg/f:DI 32 %ap)
(const_int 16 [0x10])) [0 MEM[(v2si * {ref-all})_26 +
16B]+0 S8 A64])
(mem:V2SI (plus:DI (reg/f:DI 32 %ap)
(const_int 40 [0x28])) [0 MEM[(v2si * {ref-all})_26 +
40B]+0 S8 A64]))) "vec-abi-vararg-1.c":44:16 581 {addv2si3}
 (nil))

which reload needs to fix

11: r79:V2SI=r80:V2SI+r81:V2SI
 Inserting insn reload before:
26: r80:V2SI=[%ap:DI+0x170]
27: r81:V2SI=[%ap:DI+0x188]
 Inserting insn reload after:
25: r73:V4SI#0=r79:V2SI
...
12: r74:V2DI=sign_extend(vec_select(r82:V4SI,parallel))
   REG_DEAD r73:V4SI
 Inserting insn reload before:
28: r82:V4SI=r73:V4SI

which materializes as:

(insn 10 14 24 2 (set (reg:V4SI 16 %f0 [orig:73 _3 ] [73])
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])) "vec-abi-vararg-1.c":44:16 410 {movv4si}
  (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(nil)))
(insn 24 10 26 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [4 %sfp+-48 S16 A64])
(reg:V4SI 16 %f0 [orig:73 _3 ] [73])) "vec-abi-vararg-1.c":44:16 410
{movv4si}
 (nil))
(insn 26 24 27 2 (set (reg:V2SI 16 %f0 [80])
(mem:V2SI (plus:DI (reg/f:DI 15 %r15)
(const_int 384 [0x180])) [0 MEM[(v2si * {ref-all})_26 + 16B]+0
S8 A64])) "vec-abi-vararg-1.c":44:16 426 {movv2si}
 (nil))
(insn 27 26 11 2 (set (reg:V2SI 17 %f2 [81])
(mem:V2SI (plus:DI (reg/f:DI 15 %r15)
(const_int 408 [0x198])) [0 MEM[(v2si * {ref-all})_26 + 40B]+0
S8 A64])) "vec-abi-vararg-1.c":44:16 426 {movv2si}
 (nil))
(insn 11 27 25 2 (set (reg:V2SI 16 %f0 [79])
(plus:V2SI (reg:V2SI 16 %f0 [80])
(reg:V2SI 17 %f2 [81]))) "vec-abi-vararg-1.c":44:16 581 {addv2si3}
 (nil))
(insn 25 11 28 2 (set (mem/c:V2SI (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [4 %sfp+-48 S8 A64])
(reg:V2SI 16 %f0 [79])) "vec-abi-vararg-1.c":44:16 426 {movv2si}
 (nil))
(insn 28 25 12 2 (set (reg:V4SI 16 %f0 [orig:73 _3 ] [73])
(mem/c:V4SI (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [4 %sfp+-48 S16 A64]))
"vec-abi-vararg-1.c":44:16 410 {movv4si}
 (nil))
(insn 12 28 29 2 (set (reg:V2DI 16 %f0 [orig:74 _29 ] [74])
(sign_extend:V2DI (vec_select:V2SI (reg:V4SI 16 %f0 [orig:73 _3 ] [73])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
] "vec-abi-vararg-1.c":44:16 1345 {vec_unpacks_hi_v4si}
 (nil))

Insn 25 and 28 convert a V2SI into a V4SI via stack.  It is a bit unfortunate
since the resulting V4SI vector is used for unpacking which ignores the
rightmost half, i.e., zeroing out the rightmost half by going over the stack is
unnecessary.

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-May/652
   ||912.html

--- Comment #8 from Rainer Orth  ---
Patch posted.

[Bug tree-optimization/115060] Probable an issue around usage of vect_look_through_possible_promotion in tree-vect-patterns.cc

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Feng Xue :

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

commit r15-863-ga3aeff4ce95bd616a2108dc2363d9cbaba53b170
Author: Feng Xue 
Date:   Thu May 23 15:25:53 2024 +0800

vect: Use vect representative statement instead of original in patch recog
[PR115060]

Some utility functions (such as vect_look_through_possible_promotion) that
are
to find out certain kind of direct or indirect definition SSA for a value,
may
return the original one of the SSA, not its pattern representative SSA,
even
pattern is involved. For example,

   a = (T1) patt_b;
   patt_b = (T2) c;// b = ...
   patt_c = not-a-cast;// c = ...

Given 'a', the mentioned function will return 'c', instead of 'patt_c'.
This
subtlety would make some pattern recog code that is unaware of it mis-use
the
original instead of the new pattern statement, which is inconsistent wth
processing logic of the pattern formation pass. This patch corrects the
issue
by forcing another utility function (vect_get_internal_def) return the
pattern
statement information to caller by default.

2024-05-23 Feng Xue 

gcc/
PR tree-optimization/115060
* tree-vect-patterns.cc (vect_get_internal_def): Return statement
for
vectorization.
(vect_widened_op_tree): Call vect_get_internal_def instead of
look_def
to get statement information.
(vect_recog_widen_abd_pattern): No need to call
vect_stmt_to_vectorize.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed then.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

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

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

commit r15-862-gd8d70b783765361a8acef70fc9b54db526cd6ff5
Author: Richard Biener 
Date:   Tue May 28 15:55:59 2024 +0200

target/115254 - fix gcc.dg/vect/vect-gather-4.c dump scanning

The dump scanning is supposed to check that we do not merge two
sligtly different gathers into one SLP node but since we now
SLP the store scanning for "ectorizing stmts using SLP" is no
longer good.  Instead the following makes us look for
"stmt 1 .* = .MASK" which would be how the second lane of an SLP
node looks like.  We have to handle both .MASK_GATHER_LOAD (for
targets with ifun mask gathers) and .MASK_LOAD (for ones without).

Tested on x86_64-linux with and without native gather and on GCN
where this now avoids a FAIL.

PR target/115254
* gcc.dg/vect/vect-gather-4.c: Adjust dump scan.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

--- Comment #7 from Thomas Schwinge  ---
(In reply to Richard Biener from comment #6)
> The following works for me - does it work for you?

> --- a/gcc/testsuite/gcc.dg/vect/vect-gather-4.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-gather-4.c

> -/* { dg-final { scan-tree-dump-not "vectorizing stmts using SLP" vect } } */
> +/* We do not want to see a two-lane .MASK_LOAD or .MASK_GATHER_LOAD since
> +   the gathers are different on each lane.  This is a bit fragile and
> +   should possibly be turned into a runtime test.  */
> +/* { dg-final { scan-tree-dump-not "stmt 1 \[^\r\n\]* = .MASK" vect } } */

Yes:

PASS: gcc.dg/vect/vect-gather-4.c (test for excess errors)
PASS: gcc.dg/vect/vect-gather-4.c scan-tree-dump-not vect "stmt 1 [^\r\n]*
= .MASK"

But indeed, "a bit fragile".  ;-)

[Bug ipa/113907] [11/12/13/14/15 regression] ICU miscompiled on x86 since r14-5109-ga291237b628f41

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

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

--- Comment #79 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:72f6b7ec3915f0b5b3517dffa19e3b34c8af687d

commit r12-10475-g72f6b7ec3915f0b5b3517dffa19e3b34c8af687d
Author: Martin Jambor 
Date:   Tue May 28 13:33:02 2024 +0200

ipa: Compare jump functions in ICF (PR 113907)

This is a manual backport of r14-9840-g1162861439fd3c from master.
Manual because the bits and value range representation in jump
functions have changes during the gcc 14 development cycle.

In PR 113907 comment #58, Honza found a case where ICF thinks bodies
of functions are equivalent but becaise of difference in aliases in a
memory access, different aggregate jump functions are associated with
supposedly equivalent call statements.  This patch adds a way to
compare jump functions and plugs it into ICF to avoid the issue.

gcc/ChangeLog:

2024-05-14  Martin Jambor  

PR ipa/113907
* ipa-prop.h (ipa_jump_functions_equivalent_p): Declare.
(values_equal_for_ipcp_p): Likewise.
* ipa-prop.cc (ipa_agg_pass_through_jf_equivalent_p): New function.
(ipa_agg_jump_functions_equivalent_p): Likewise.
(ipa_jump_functions_equivalent_p): Likewise.
* ipa-cp.cc (values_equal_for_ipcp_p): Make function public.
* ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h,
sreal.h,
ipa-cp.h and ipa-prop.h.
(func_checker::compare_gimple_call): Comapre jump functions.

gcc/testsuite/ChangeLog:

2024-05-10  Martin Jambor  

PR ipa/113907
* gcc.dg/lto/pr113907_0.c: New.
* gcc.dg/lto/pr113907_1.c: Likewise.
* gcc.dg/lto/pr113907_2.c: Likewise.

(cherry picked from commit 1db45e83021a8a87f41e22053910fcce6e8e2c2c)

[Bug fortran/115260] New: Corruption of derived type data when array temporarys of type occur

[steve.mullerworth at metoffice dot gov.uk via Gcc-bugs]

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

Bug ID: 115260
   Summary: Corruption of derived type data when array temporarys
of type occur
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steve.mullerworth at metoffice dot gov.uk
  Target Milestone: ---

Created attachment 58301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58301=edit
Compile with -Og or more to illustrate issue

I have a 2D (or more than 2D) array of a derived type. The derived type
contains one or more allocatable arrays of reals or integers.

If I call a subroutine with a part of the 2D array *such that an array
temporary is created* then data in the arrays within the derived type are
corrupted on return: the first few items of data in each array are corrupted.

The example program demonstrates calling subroutines in a way that don't use
temporary arrays and then in a way that does use temporary arrays, printing the
arrays as it progresses. On return from the final call that results in array
temporaries, the issue is that the arrays of reals and integers have different
values in the first few elements.

The amount of corruption in the allocatable arrays appears to be a certain
number of bits, so a real64 has half the corruption of an integer32. The number
of bits seems platform dependent. Mosty 128 bits on Godbolt Compiler Explorer
and my desktop old-ish Intel (Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz). But
256 bits on ARM Genoa (AMD EPYC 7763 64-Core) for some reason – it’s another
64-bit CPU.

Started happening from gcc10.2 up to head of trunk (according to the Compiler
Explorer). Affects -Og or above. -O0 is fine. Use -fcheck=all to show up
creation of array temporaries at last call.

Link to Compiler Explorer example:

https://godbolt.org/z/971evY8sn

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Thomas Schwinge from comment #5)
[..]
> (In reply to Richard Biener from comment #2)
> > Note for gcc.dg/vect/vect-gather-4.c with -mgather and gather support in the
> > ISA on x86_64 I get two 'vectorizing stmts using SLP', for f1 and f2 only.
> > 
> > Does that match GCN?
> 
> In addition to 'f1', 'f2', GCN target ('-march=gfx908') apparently can do
> 'f3', too:
> 
> [...]/gcc.dg/vect/vect-gather-4.c:37:21: note:   vectorizing stmts using
> SLP.
> 
> Attaching that 'vect-gather-4.c.179t.vect'.

Yeah, so GCN can handle all gathers.

> > We unfortunately cannot handle masked gathers as "emulated".
> > 
> > And we don't have good dejagnu target selectors for this either.

Which we'd need to "fix" this - note we didn't check at all that the
loops are vectorized!  What we did want to check is that we do not
mangle both feeding masked gathers into the same SLP branch, but we
have really no indicator for this now.

I suppose we could change this to scan

note:   node 0x4300808 (max_nunits=64, refcnt=1) vector(64) int
note:op template: patt_34 = .MASK_GATHER_LOAD ((sizetype) _71, _5, 4, 0,
_37);
note:stmt 0 patt_34 = .MASK_GATHER_LOAD ((sizetype) _71, _5, 4, 0, _37);
note:children 0x4300560 0x43004d8

specifically _not_

note:stmt 1 ... = .MASK_GATHER_LOAD

but then on x86-64 you'd not see .MASK_GATHER_LOAD, neither for emulated
gather discovery.  And you _do_ have a 'stmt 1' for the SLP store.
On x86-64 with native gather support there's .MASK_LOAD, so I suppose
given we know we cannot emulate a mask gather we can change it to
a scan-not of 'stmt 1 .* = .MASK'

The following works for me - does it work for you?

diff --git a/gcc/testsuite/gcc.dg/vect/vect-gather-4.c
b/gcc/testsuite/gcc.dg/vect/vect-gather-4.c
index d18094d6982..edd9a6783c2 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-gather-4.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-gather-4.c
@@ -45,4 +45,7 @@ f3 (int *restrict y, int *restrict x, int *restrict indices)
 }
 }

-/* { dg-final { scan-tree-dump-not "vectorizing stmts using SLP" vect } } */
+/* We do not want to see a two-lane .MASK_LOAD or .MASK_GATHER_LOAD since
+   the gathers are different on each lane.  This is a bit fragile and
+   should possibly be turned into a runtime test.  */
+/* { dg-final { scan-tree-dump-not "stmt 1 \[^\r\n\]* = .MASK" vect } } */

[Bug tree-optimization/115256] [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7

[admin at levyhsu dot com via Gcc-bugs]

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

--- Comment #3 from Levy Hsu  ---
FYI we tried serval combinations, -funroll-loops didn't cause the issue, The
link-time optimization -flto may caused the issue, we can pass with the option
[-march=native -Ofast -funroll-loops].

But compiling with -flto makes it harder to minimize a test case. So we're
still not clear what exactly the issue is.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

--- Comment #5 from Thomas Schwinge  ---
Created attachment 58300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58300=edit
GCN target ('-march=gfx908') 'vect-gather-4.c.179t.vect'

(In reply to GCC Commits from comment #3)
> commit r15-859-geaaa4b88038d4d6eda1b20ab662f1568fd9be31f

> * gcc.dg/vect/slp-cond-2-big-array.c: Expect 4 times SLP.
> * gcc.dg/vect/slp-cond-2.c: Likewise.

ACK, again PASS for GCN target ('-march=gfx908'), thanks!


(In reply to Richard Biener from comment #4)
> The gcc.dg/vect/vect-gather-4.c FAIL should be still present.

Yes.

(In reply to Richard Biener from comment #2)
> Note for gcc.dg/vect/vect-gather-4.c with -mgather and gather support in the
> ISA on x86_64 I get two 'vectorizing stmts using SLP', for f1 and f2 only.
> 
> Does that match GCN?

In addition to 'f1', 'f2', GCN target ('-march=gfx908') apparently can do 'f3',
too:

[...]/gcc.dg/vect/vect-gather-4.c:37:21: note:   vectorizing stmts using
SLP.

Attaching that 'vect-gather-4.c.179t.vect'.

> We unfortunately cannot handle masked gathers as "emulated".
> 
> And we don't have good dejagnu target selectors for this either.

[Bug target/115259] [15 Regressions] GCN vs. "tree-optimization/115144 - improve sinking destination choice"

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |15.0

--- Comment #1 from Richard Biener  ---
Possibly.  Did you pick up the followup fix?  It might go unnoticed and produce
wrong-code.  r15-850-gf9fbb47987efc8, that is.

There's no debug counter in sinking to more easily bisect what goes wrong in
libgfortran.  Did you already find a single responsible TU in libgfortran?

[Bug fortran/115150] [12/13/14 Regression] SHAPE of zero-sized array yields a negative value

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

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

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

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

commit r14-10251-gdbeb3d127da07963ecaa26680da62a255199e9c2
Author: Tobias Burnus 
Date:   Mon May 20 08:34:48 2024 +0200

Fortran: Fix SHAPE for zero-size arrays

PR fortran/115150

gcc/fortran/ChangeLog:

* trans-intrinsic.cc (gfc_conv_intrinsic_bound): Fix SHAPE
for zero-size arrays

gcc/testsuite/ChangeLog:

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

(cherry picked from commit b701306a9b38bd74cdc26c7ece5add22f2203b56)

[Bug target/115259] New: [15 Regressions] GCN vs. "tree-optimization/115144 - improve sinking destination choice"

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

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

Bug ID: 115259
   Summary: [15 Regressions] GCN vs. "tree-optimization/115144 -
improve sinking destination choice"
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

Per bisecting, I found commit r15-815-g5b9b3bae33cae7fca2e3c3e3028be6b8bee9b698
"tree-optimization/115144 - improve sinking destination choice" responsible for
a number of GCN target (tested '-march=gfx908) execution test regressions.  As
it seems, it's a mis-compilation of libgfortran code.  (That is, have to
rebuilt target libgfortran to make the issue appear/go away.)  Given that we're
not seeing such failures in any other configuration, it might be a latent issue
in GCC/GCN?

PASS: gfortran.dg/all_bounds_1.f90   -O0  (test for excess errors)
PASS: gfortran.dg/all_bounds_1.f90   -O0  execution test
[-PASS:-]{+FAIL:+} gfortran.dg/all_bounds_1.f90   -O0  output pattern test
PASS: gfortran.dg/all_bounds_1.f90   -O1  (test for excess errors)
PASS: gfortran.dg/all_bounds_1.f90   -O1  execution test
[-PASS:-]{+FAIL:+} gfortran.dg/all_bounds_1.f90   -O1  output pattern test
PASS: gfortran.dg/all_bounds_1.f90   -O2  (test for excess errors)
PASS: gfortran.dg/all_bounds_1.f90   -O2  execution test
[-PASS:-]{+FAIL:+} gfortran.dg/all_bounds_1.f90   -O2  output pattern test
PASS: gfortran.dg/all_bounds_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
PASS: gfortran.dg/all_bounds_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
[-PASS:-]{+FAIL:+} gfortran.dg/all_bounds_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
PASS: gfortran.dg/all_bounds_1.f90   -O3 -g  (test for excess errors)
PASS: gfortran.dg/all_bounds_1.f90   -O3 -g  execution test
[-PASS:-]{+FAIL:+} gfortran.dg/all_bounds_1.f90   -O3 -g  output pattern
test
PASS: gfortran.dg/all_bounds_1.f90   -Os  (test for excess errors)
PASS: gfortran.dg/all_bounds_1.f90   -Os  execution test
[-PASS:-]{+FAIL:+} gfortran.dg/all_bounds_1.f90   -Os  output pattern test

Fortran runtime error: Incorrect extent in return value of ALL intrinsic in
dimension 1: is 3, should be 140127603031922

Fortran runtime error: Incorrect extent in return value of ALL intrinsic in
dimension 1: is 3, should be 17179869188

Fortran runtime error: Incorrect extent in return value of ALL intrinsic in
dimension 1: is 3, should be 5648507875369387964

[Etc.]

Should match:
Fortran runtime error: Incorrect extent in return value of ALL intrinsic in
dimension 1: is 3, should be 2

(..., that is, the "should be" value is wrong?!)


PASS: gfortran.dg/allocated_4.f90   -O0  (test for excess errors)
PASS: gfortran.dg/allocated_4.f90   -O0  execution test
PASS: gfortran.dg/allocated_4.f90   -O1  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/allocated_4.f90   -O1  execution test
PASS: gfortran.dg/allocated_4.f90   -O2  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/allocated_4.f90   -O2  execution test
PASS: gfortran.dg/allocated_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/allocated_4.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: gfortran.dg/allocated_4.f90   -O3 -g  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/allocated_4.f90   -O3 -g  execution test
PASS: gfortran.dg/allocated_4.f90   -Os  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/allocated_4.f90   -Os  execution test

Operating system error: Not enough space
Integer overflow in xmallocarray


PASS: gfortran.dg/any_all_1.f90   -O0  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/any_all_1.f90   -O0  execution test
PASS: gfortran.dg/any_all_1.f90   -O1  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/any_all_1.f90   -O1  execution test
PASS: gfortran.dg/any_all_1.f90   -O2  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/any_all_1.f90   -O2  execution test
PASS: gfortran.dg/any_all_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/any_all_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: 

[Bug c++/93740] Template base classes parametrized by pointer-to-member are amibiguous

[3y3p4tch at protonmail dot com via Gcc-bugs]

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

Saurav Yadav <3y3p4tch at protonmail dot com> changed:

   What|Removed |Added

 CC||3y3p4tch at protonmail dot com

--- Comment #8 from Saurav Yadav <3y3p4tch at protonmail dot com> ---
It seems like bug 104678 might be related to this

[Bug tree-optimization/114948] [15 Regression] ICE on valid code at -O3 with "-fno-tree-ccp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Richard Biener  ---
can't reproduce on trunk either ... the godbold link is also fine.

[Bug tree-optimization/115236] [15 regression] Wrong code at -O1 and above with -fno-tree-fre and volatile pointers since r15-579-ga9251ab3c91c8c

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Should now finally be fixed.  Thanks for the report.

[Bug tree-optimization/115236] [15 regression] Wrong code at -O1 and above with -fno-tree-fre and volatile pointers since r15-579-ga9251ab3c91c8c

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

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

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

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

commit r15-861-gc08b0d3f7b3539b26031de31d88dea6b94474577
Author: Richard Biener 
Date:   Mon May 27 10:41:02 2024 +0200

tree-optimization/115236 - more points-to *ANYTHING = x fixes

The stored-to ANYTHING handling has more holes, uncovered by treating
volatile accesses as ANYTHING.  We fail to properly build the
pred and succ graphs, in particular we may not elide direct nodes
from receiving from STOREDANYTHING.

PR tree-optimization/115236
* tree-ssa-structalias.cc (build_pred_graph): Properly
handle *ANYTHING = X.
(build_succ_graph): Likewise.  Do not elide direct nodes
from receiving from STOREDANYTHING.

* gcc.dg/pr115236.c: New testcase.

[Bug fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

[Bug fortran/90069] Polymorphic Return Type Memory Leak Without Intermediate Variable

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

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

--- Comment #3 from Andre Vehreschild  ---
Created attachment 58299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58299=edit
Fix memory leak.

Waiting for review.

[Bug fortran/90069] Polymorphic Return Type Memory Leak Without Intermediate Variable

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug rtl-optimization/115258] [14 Regression][aarch64] Additional XORs generated after r14-6290-g9f0f7d802482a8958d6cdc72f1fe0c8549db2182

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.2

[Bug tree-optimization/115256] [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7

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

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

--- Comment #2 from Richard Biener  ---
Confirmed on Zen3 btw, fails with the test input already.  Note that this may
still be a latent issue in 502.gcc_r.  -funroll-loops isn't neccessary,
-O3 -flto was enough to reproduce (no specific sub-architecture required).

-fno-strict-aliasing avoids the issue. 

--param dse-max-object-size=0 doesn't help (turn off live byte tracking)

The patch itself likely adds quite some extra DSE so that's too much to
track down.  DSE doesn't have a debug counter at the moment,
but "bisecting" --param dse-max-alias-queries-per-store shows the issue
still happens with 64 but not with 48.

The issue still reproduces with -flto-partition=1to1 (if one wants to
try per-TU compile flags) and with -flto-partition=one (if you want to
add a debug counter and bisect the bad store, but =one is slow).

We ICE in cfgloopmanip.c:create_preheader here:

basic_block
create_preheader (struct loop *loop, int flags)
{
  edge e, fallthru;
  basic_block dummy;
  int nentry = 0;
  bool irred = false;
  bool latch_edge_was_fallthru;
  edge one_succ_pred = NULL, single_entry = NULL;
  edge_iterator ei;

  FOR_EACH_EDGE (e, ei, loop->header->preds)
{ 
  if (e->src == loop->latch)
continue;
  irred |= (e->flags & EDGE_IRREDUCIBLE_LOOP) != 0;
  nentry++;
  single_entry = e;
  if (single_succ_p (e->src))
one_succ_pred = e;
}
  gcc_assert (nentry);
^^^

placing noinline on the above function still reproduces the issue.  We
seem to run the above for the loop tree root but call from create_preheaders
which does

1425  FOR_EACH_LOOP (li, loop, 0)
1426create_preheader (loop, flags);

(note absence of LI_INCLUDE_ROOT) so somehow the loop iterator setup
is broken.

[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Fixed for 13.4 and 14.2

[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete

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

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

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

https://gcc.gnu.org/g:67434fec24bef0faeec0eb402f82ca7e43a4a112

commit r13-8804-g67434fec24bef0faeec0eb402f82ca7e43a4a112
Author: Jonathan Wakely 
Date:   Wed May 22 10:32:43 2024 +0100

libstdc++: Guard use of sized deallocation [PR114940]

Clang does not enable -fsized-deallocation by default, which means it
can't compile our  header.

Make the __cpp_lib_generator macro depend on the compiler-defined
__cpp_sized_deallocation macro, and change  to use unsized
deallocation when __cpp_sized_deallocation isn't defined.

libstdc++-v3/ChangeLog:

PR libstdc++/114940
* include/std/stacktrace (_GLIBCXX_SIZED_DELETE): New macro.
(basic_stacktrace::_Impl::_M_deallocate): Use it.

(cherry picked from commit b2fdd508d7e63158e9d2a6dd04f901d02900def3)

[Bug c++/115216] operator auto() gets instantiatied too eagerly

[olaf.krzikalla at dlr dot de via Gcc-bugs]

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

--- Comment #3 from Olaf Krzikalla  ---
(In reply to Andrew Pinski from comment #2)
> MSVC and ICC (EDG in GCC compat mode) also rejects the code for the same
> reason as GCC. Are you sure this is not a clang issue?

To be honest I don't know. I have no idea, if a compiler is allowed to convert
a type before applying a operator, if there is already such an operator
available in the genuine class. Someone who knows the respective details in the
standard is required.

[Bug rtl-optimization/115258] New: [14 Regression][aarch64] Additional XORs generated after r14-6290-g9f0f7d802482a8958d6cdc72f1fe0c8549db2182

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

Bug ID: 115258
   Summary: [14 Regression][aarch64] Additional XORs generated
after
r14-6290-g9f0f7d802482a8958d6cdc72f1fe0c8549db2182
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manolis.tsamis at vrull dot eu
  Target Milestone: ---

For the following testcase:

  typedef int veci __attribute__ ((vector_size (4 * sizeof (int;
  void fun (veci *a, veci *b, veci *c) {
*c = __builtin_shufflevector (*a, *b, 0, 5, 2, 7);
  }

After this commit we generate (at -O2)

adrpx3, .LC0
ldr q30, [x1]
ldr q31, [x0]
ldr q29, [x3, #:lo12:.LC0]
eor v31.16b, v31.16b, v30.16b
eor v30.16b, v31.16b, v30.16b
eor v31.16b, v31.16b, v30.16b
tbl v30.16b, {v30.16b - v31.16b}, v29.16b
str q30, [x2]
ret

Instead of

adrpx3, .LC0
ldr q30, [x0]
ldr q31, [x1]
ldr q29, [x3, #:lo12:.LC0]
tbl v30.16b, {v30.16b - v31.16b}, v29.16b
str q30, [x2]
ret

The 3 newly introduced eor instructions just swap the values of v30 and v31,
which are loaded in the reverse order compared to the old code.

[Bug c++/115257] New: Error when compiling a program with module and println and auto

[paalon1936 at gmail dot com via Gcc-bugs]

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

Bug ID: 115257
   Summary: Error when compiling a program with module and println
and auto
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paalon1936 at gmail dot com
  Target Milestone: ---

When I tried to make a following program with module and  and autos,
failed to compile.

$ g++-14 -std=c++23 -fmodules-ts -x c++-system-header print
$ g++-14 -std=c++23 -fmodules-ts -Wall -Wextra -save-temps hello.cpp main.cpp
-o main
In file included from /usr/local/Cellar/gcc/14.1.0/include/c++/14/print:41,
of module /usr/local/Cellar/gcc/14.1.0/include/c++/14/print, imported at
hello.cpp:3,
of module hello, imported at main.cpp:1:
/usr/local/Cellar/gcc/14.1.0/include/c++/14/format: In instantiation of 'struct
std::__format::_Runtime_format_string':
/usr/local/Cellar/gcc/14.1.0/include/c++/14/print:129:19:   required from 'void
std::println(format_string<_Args ...>, _Args&& ...) [with _Args = {const char
(&)[4]}; format_string<_Args ...> = basic_format_string]'
  129 | { std::println(stdout, __fmt, std::forward<_Args>(__args)...); }
  |   ^~~
hello.cpp:7:21:   required from 'auto hello::greeting@hello(const auto:1&)
[with auto:1 = char [4]]'
7 | std::println("Hello, {}!", x);
  | ^
main.cpp:4:20:   required from here
4 | hello::greeting("C++");
  | ~~~^~~
/usr/local/Cellar/gcc/14.1.0/include/c++/14/format:74:55: internal compiler
error: Segmentation fault: 11
   74 |   template struct
basic_format_string;
  |  
^~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
$ cat main-hello.ii
# 0 "hello.cpp"
# 0 ""
# 0 ""
# 1 "hello.cpp"
export  module  hello;

import  "/usr/local/Cellar/gcc/14.1.0/include/c++/14/print";

export namespace hello {
auto greeting(auto const & x) {
std::println("Hello, {}!", x);
}
}
$ cat main-main.ii
# 0 "main.cpp"
# 0 ""
# 0 ""
# 1 "main.cpp"
import  hello;

int main() {
hello::greeting("C++");
}

If I don't use module, but use `#include` then it works, and
if I don't use std::println of  and use std::cout of , then it
works, and
if I don't use autos, and specify the types `void` and `char const *`, then it
works.

I'm using macOS Ventura 13.6.7, and GCC 14.1.0.
$ g++-14 --version
g++-14 (Homebrew GCC 14.1.0) 14.1.0
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.

[Bug tree-optimization/115256] [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-28
   Target Milestone|--- |15.0
   Keywords||needs-reduction, wrong-code
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

--- Comment #4 from Richard Biener  ---
The gcc.dg/vect/vect-gather-4.c FAIL should be still present.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

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

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

commit r15-859-geaaa4b88038d4d6eda1b20ab662f1568fd9be31f
Author: Richard Biener 
Date:   Fri Sep 29 15:12:54 2023 +0200

tree-optimization/115254 - don't account single-lane SLP against discovery
limit

The following avoids accounting single-lane SLP to the discovery
limit.  As the two testcases show this makes discovery fail,
unfortunately even not the same across targets.  The following
should fix two FAILs for GCN as a side-effect.

PR tree-optimization/115254
* tree-vect-slp.cc (vect_build_slp_tree): Only account
multi-lane SLP to limit.

* gcc.dg/vect/slp-cond-2-big-array.c: Expect 4 times SLP.
* gcc.dg/vect/slp-cond-2.c: Likewise.

[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete

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

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

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

https://gcc.gnu.org/g:89dff1488ef3fde11f6451e5f9817e14bcd6a873

commit r14-10250-g89dff1488ef3fde11f6451e5f9817e14bcd6a873
Author: Jonathan Wakely 
Date:   Wed May 22 10:32:43 2024 +0100

libstdc++: Guard use of sized deallocation [PR114940]

Clang does not enable -fsized-deallocation by default, which means it
can't compile our  and  headers.

Make the __cpp_lib_generator macro depend on the compiler-defined
__cpp_sized_deallocation macro, and change  to use unsized
deallocation when __cpp_sized_deallocation isn't defined.

libstdc++-v3/ChangeLog:

PR libstdc++/114940
* include/bits/version.def (generator): Depend on
__cpp_sized_deallocation.
* include/bits/version.h: Regenerate.
* include/std/stacktrace (_GLIBCXX_SIZED_DELETE): New macro.
(basic_stacktrace::_Impl::_M_deallocate): Use it.

(cherry picked from commit b2fdd508d7e63158e9d2a6dd04f901d02900def3)

[Bug tree-optimization/115256] New: [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7

[admin at levyhsu dot com via Gcc-bugs]

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

Bug ID: 115256
   Summary: [15 Regression] 502.gcc_r Run failed with
'-march=native -Ofast -funroll-loops -flto' since
r15-571-g1e0ae1f52741f7
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: admin at levyhsu dot com
  Target Milestone: ---

Bisect down to r15-571-g1e0ae1f52741f7
(1e0ae1f52741f7e0133661659ed2d210f939a398)

tree-optimization/79958 - make DSE track multiple paths
DSE currently gives up when the path we analyze forks.  This leads
to multiple missed dead store elimination PRs.  The following fixes
this by recursing for each path and maintaining the visited bitmap
to avoid visiting CFG re-merges multiple times.  The overall cost
is still limited by the same bound, it's just more likely we'll hit
the limit now.  The patch doesn't try to deal with byte tracking
once a path forks but drops info on the floor and only handling
fully dead stores in that case.

PR tree-optimization/79958
PR tree-optimization/109087
PR tree-optimization/100314
PR tree-optimization/114774
* tree-ssa-dse.cc (dse_classify_store): New forwarder.
(dse_classify_store): Add arguments cnt and visited, recurse
to track multiple paths when we end up with multiple defs.

* gcc.dg/tree-ssa/ssa-dse-48.c: New testcase.
* gcc.dg/tree-ssa/ssa-dse-49.c: Likewise.
* gcc.dg/tree-ssa/ssa-dse-50.c: Likewise.
* gcc.dg/tree-ssa/ssa-dse-51.c: Likewise.
* gcc.dg/graphite/pr80906.c: Avoid DSE of last data reference
in loop.
* g++.dg/ipa/devirt-24.C: Adjust for extra DSE.
* g++.dg/warn/Wuninitialized-pr107919-1.C: Use more important
-O2 optimization level, -O1 regresses.

Observed on 
Ice Lake
Cascade Lake
AlderLake
Zen3 Server/Client
Also failed on Aarch64 (But didn't bisect)

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

--- Comment #2 from Richard Biener  ---
Note for gcc.dg/vect/vect-gather-4.c with -mgather and gather support in the
ISA on x86_64 I get two 'vectorizing stmts using SLP', for f1 and f2 only.

Does that match GCN?

We unfortunately cannot handle masked gathers as "emulated".

And we don't have good dejagnu target selectors for this either.

[Bug target/115254] [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-28
   Target Milestone|--- |15.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
For gcc.dg/vect/slp-cond-2-big-array.c 4 is indeed expected.  We run into

slp-cond-2-big-array.c:39:17: note:   SLP discovery limit exceeded

for f3 on x86-64.  I have a patch to cherry-pick to avoid this.

gcc.dg/vect/slp-cond-2.c is the same testcase.

gcc.dg/vect/vect-gather-4.c is a bad written testcase, we now indeed expect
to SLP here.

I'll see to pick the change that should help a bit.

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-28

--- Comment #3 from Andrew Pinski  ---
This can't be reproduced without modifying GCC so putting in a waiting state
since this not what GCC's bugzilla is designed for.

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

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

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

--- Comment #2 from Andrew Pinski  ---
> 0xaa996b df_bb_verify
> ../../gcc/gcc/df-scan.cc:4138

THis line is blank in the current trunk (seems like you are testing before
r15-752-g7f35863ebbf7ba which is an over week old now).

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

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

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

--- Comment #1 from Andrew Pinski  ---
Are you sure this is not an issue with your musttail patches?

[Bug target/115255] New: sibcall at -O0 causes ICE in df_refs_verify on arm

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Bug ID: 115255
   Summary: sibcall at -O0 causes ICE in df_refs_verify on arm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

Note to trigger this bug need to modify tree-tailcall to run at -O0 (which is
done for musttail), e.g. by the patches here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/thread.html#652312

On ARM targets with -O0 I see

int __attribute__((noinline,noclone,noipa))callee (int i);

int __attribute__((noinline,noclone,noipa))
caller (int i)
{
  [[gnu::musttail]] return callee (i + 1);
}

../musttail1.c: In function ‘caller’:
../musttail1.c:14:1: internal compiler error: in df_refs_verify, at
df-scan.cc:4022
   14 | }
  | ^
0x87d483 df_refs_verify
../../gcc/gcc/df-scan.cc:4022
0xaa7d56 df_insn_refs_verify
../../gcc/gcc/df-scan.cc:4101
0xaa996b df_bb_verify
../../gcc/gcc/df-scan.cc:4138
0xaa9ce7 df_scan_verify()
../../gcc/gcc/df-scan.cc:4259
0xa979c2 df_verify()
../../gcc/gcc/df-core.cc:1834
0xa97a2a df_analyze_1
../../gcc/gcc/df-core.cc:1221
0xa97c31 df_analyze()
../../gcc/gcc/df-core.cc:1305
0x12607f0 thumb2_reorg
../../gcc/gcc/config/arm/arm.cc:19392
0x127522b arm_reorg
../../gcc/gcc/config/arm/arm.cc:19611
0xea6eab execute
../../gcc/gcc/reorg.cc:3931


arm_reorg is just before sched2.

The assert happens because the REG/REGNO of the new df chain changes when it is
rebuilt (differs by one from the old). Presumably changed by ipa or reload
since there are very few passes at -O0. I'm not fully sure which data structure
is stale.

I tried to add the df_analyze in the same position on x86, but the problem is
not triggered there.

[Bug d/115249] [14/15 regression] gdc.test/runnable/test34.d etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|15.0|14.2

--- Comment #2 from Rainer Orth  ---
It started to regress on the gcc-14 branch indeed.  However, for simple
testsuite
failures, I often don't care about backports, provided the issue is fixed on
trunk.

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

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

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

--- Comment #14 from YunQiang Su  ---
Ohh, sorry for my misunderstanding. Your patch is correct.

The real problem is that, $3 is used by `mips_output_function_prologue`,
which is the final for output asm source code, and thus the IRA pass
cannot be aware that $3 is used.


So we have to emit some clobbers before IRA.

We have 2 choice:

1. Your choice, aka emit clobbers just before the the call function
2. the entrance every function that need to use GP

@@ -3329,6 +3331,8 @@ mips16_gp_pseudo_reg (void)
   rtx set = gen_load_const_gp (cfun->machine->mips16_gp_pseudo_rtx);
   rtx_insn *insn = emit_insn_after (set, scan);
   INSN_LOCATION (insn) = 0;
+  emit_clobber (MIPS16_PIC_TEMP);
+  emit_clobber (MIPS_PROLOGUE_TEMP (Pmode));

   pop_topmost_sequence ();
 }

[Bug target/115254] New: [15 Regression] GCN regressions from "Avoid splitting store dataref groups during SLP discovery"

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

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

Bug ID: 115254
   Summary: [15 Regression] GCN regressions from "Avoid splitting
store dataref groups during SLP discovery"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

If my tracking is to be believed, the recent commit
r15-812-gc71886f2ca2e46ce1449c7064d6f1b447d02fcba "Avoid splitting store
dataref groups during SLP discovery" is causing the following regressions for
GCN target testing (tested '-march=gfx908'):

PASS: gcc.dg/vect/slp-cond-2-big-array.c (test for excess errors)
PASS: gcc.dg/vect/slp-cond-2-big-array.c execution test
[-PASS:-]{+FAIL:+} gcc.dg/vect/slp-cond-2-big-array.c scan-tree-dump-times
vect "vectorizing stmts using SLP" 3

gcc.dg/vect/slp-cond-2-big-array.c: pattern found 4 times


PASS: gcc.dg/vect/slp-cond-2.c (test for excess errors)
PASS: gcc.dg/vect/slp-cond-2.c execution test
[-PASS:-]{+FAIL:+} gcc.dg/vect/slp-cond-2.c scan-tree-dump-times vect
"vectorizing stmts using SLP" 3

gcc.dg/vect/slp-cond-2.c: pattern found 4 times


PASS: gcc.dg/vect/vect-gather-4.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-gather-4.c scan-tree-dump-not vect
"Loop contains only SLP stmts"

Per commit 85e2ce10f76aee93e43aab6558cf8e39cec911e4 "Fix
gcc.dg/vect/vect-gather-4.c for cascadelake", that one later additionally
changed:

FAIL: gcc.dg/vect/vect-gather-4.c scan-tree-dump-not vect [-"Loop contains
only SLP stmts"-]{+"vectorizing stmts using SLP"+}

..., but that's not relevant for the original regression.


In other words, if I locally revert that patch, these all PASS again.

[Bug tree-optimization/115214] tree-ssa-pre.c(ICE in find_or_generate_expression, at tree-ssa-pre.c:2780)

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

jiawei  changed:

   What|Removed |Added

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

--- Comment #2 from jiawei  ---
Fixed on upstream. 

https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652806.html

[Bug tree-optimization/115243] error: stmt with wrong VUSE

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Looks fixed to me.

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
 Target||arm