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

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords|needs-bisection |
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 CC||ppalka at gcc dot gnu.org

[Bug driver/117968] running "cpp" with malformed arguments can cause input file deletion

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

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

Richard Sandiford  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #6 from Richard Sandiford  ---
(In reply to Jonathan Wakely from comment #5)
> The implied -o for cpp does seem to make it a bit easier to accidentally
> lose a file - I didn't know about it and so found the effects of this "bug"
> surprising.
Yeah, +1  Although the current behaviour is valid, it seems worth making things
more friendly anyway.  It reminds me of tar's “Cowardly refusing to create an
empty archive”, which has saved me multiple times…

[Bug go/118152] [12/13/14/15 regression] libgo sync/atomic fails since g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm

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

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

Sam James  changed:

   What|Removed |Added

  Known to work||11.5.0
Summary|libgo sync/atomic fails |[12/13/14/15 regression]
   |since   |libgo sync/atomic fails
   |g:8a8a7d332d5d01db5aea7336a |since
   |36d9fd71a679fb1 on arm  |g:8a8a7d332d5d01db5aea7336a
   ||36d9fd71a679fb1 on arm
  Known to fail||12.1.0, 15.0
   Target Milestone|--- |12.5
   Keywords||testsuite-fail, wrong-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117999

[Bug target/118150] New: Failure to fold NOT+PTEST to NOTS for SVE

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

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

Bug ID: 118150
   Summary: Failure to fold NOT+PTEST to NOTS for SVE
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: aarch64-sve, missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

#include 
int
foo (svbool_t x, int y, int z)
{
  return svptest_any(svptrue_b8(), svnot_z(svptrue_b8(), x)) ? y : z;
}

generates:

foo:
ptrue   p3.b, all
not p0.b, p3/z, p0.b
ptest   p3, p0.b
cselw0, w1, w0, none
ret

instead of LLVM's:

foo:
ptrue   p1.b
notsp0.b, p1/z, p0.b
cselw0, w0, w1, ne
ret

because we don't have any combiner patterns for NOT+PTEST.

[HT to Tamar for the spot]

[Bug ipa/110378] IPA-SRA for destructors

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

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

--- Comment #11 from Martin Jambor  ---
IIUC only the simplest testcase of the three was fixed.  I'll try to re-check
soon-ish.

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop) since r15-5563

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

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

Sam James  changed:

   What|Removed |Added

 CC||cmuellner at gcc dot gnu.org

--- Comment #7 from Sam James  ---
Sounds good. Any objections Christoph?

[Bug tree-optimization/118149] New: [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop)

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

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

Bug ID: 118149
   Summary: [15 regression] ICE when building lsp-plugins-1.2.14
(mmap: Cannot allocate memory in forwprop)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

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

```
$ g++ -c generic.ii -O2 -march=znver2
during GIMPLE pass: forwprop
In file included from main/generic/generic.cpp:70:
/var/tmp/portage/media-libs/lsp-plugins-1.2.14/work/lsp-plugins/modules/lsp-dsp-lib/include/private/dsp/arch/generic/fastconv.h:
In function ‘void lsp::generic::fastconv_parse(float*, const float*, size_t)’:
/var/tmp/portage/media-libs/lsp-plugins-1.2.14/work/lsp-plugins/modules/lsp-dsp-lib/include/private/dsp/arch/generic/fastconv.h:33:14:
internal compiler error: in operator[], at vec.h:910
   33 | void fastconv_parse(float *dst, const float *src, size_t rank)
  |  ^~
mmap: Cannot allocate memory
0x7e3e27b59746 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7e3e27b597f6 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

---

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 15.0. p, commit
bf22395e91b68cb0cb464f72e08949ddd7ded9bf' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241219 (experimental)
23df3c3a4aa33a08e82ac8b98d7ff6e7f1b65b63 (Gentoo Hardened 15.0. p, commit
bf22395e91b68cb0cb464f72e08949ddd7ded9bf)
```

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop)

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

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

--- Comment #1 from Sam James  ---
Created attachment 59933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59933&action=edit
generic.ii.xz

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop)

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code

[Bug target/118131] [15 regression] ICE in gcc.c-torture/execute/loop-13.c after g:4f4e13dd235bba9c706948a3ecb3e530dd68aad1

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #3 from Christophe Lyon  ---
Should be fixed.

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop) since r15-5563

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

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

--- Comment #6 from Jakub Jelinek  ---
Seems r15-6387-geee2891312a9b42acabcc82739604c9fa8421757 fixed it.
So just commit the reduced testcase & close?

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Please preprocess with -D_GLIBCXX_DO_NOT_USE_BUILTIN_TRAITS if that still
reproduces.
Builtin traits are a nightmare for bisection.

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop)

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

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

--- Comment #3 from Sam James  ---
Created attachment 59934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59934&action=edit
generic-no-builtin-traits.ii.xz

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop)

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

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

--- Comment #4 from Sam James  ---
Reduced:
```
float *fastconv_parse_dst;
void fastconv_parse() {
  float r3k = fastconv_parse_dst[1] - fastconv_parse_dst[3],
i0k = fastconv_parse_dst[4] + fastconv_parse_dst[6],
i1k = fastconv_parse_dst[4] - fastconv_parse_dst[6],
i2k = fastconv_parse_dst[5] + fastconv_parse_dst[7];
  fastconv_parse_dst[1] = fastconv_parse_dst[0];
  fastconv_parse_dst[4] = fastconv_parse_dst[5] = i0k - i2k;
  fastconv_parse_dst[6] = fastconv_parse_dst[7] = i1k + r3k;
}
```

Just '-O2' is enough.

[Bug driver/117968] running "cpp" with malformed arguments can cause input file deletion

[schwab--- via Gcc-bugs]

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

--- Comment #7 from Andreas Schwab  ---
cpp --help doesn't mention this implicit -o.

[Bug go/118152] [12/13/14/15 regression] libgo sync/atomic fails since g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm

[ian at airs dot com via Gcc-bugs]

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

--- Comment #2 from Ian Lance Taylor  ---
Not sure what is happening here and not sure I have access to a 32-bit arm
machine to test on.

This test is supposed to crash.  We are testing that the crash is correctly
recovered.  I don't know why it is using a misaligned memory address.  It is
expected to try to store a value to address 0.

I also don't know what the revision you mention has to do with this.  I
wouldn't expect this code to use that at all.

It might be helpful to see the dissassembled code of
sync/atomic_test.TestNilDeref..func30.

[Bug fortran/118120] Wrong aliasing assumptions for Fortran POINTERs

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r15-6395-gaed4a2689dbc8ea7e60c1fab9e7f455d99e632b7
Author: Harald Anlauf 
Date:   Thu Dec 19 22:22:52 2024 +0100

Fortran: potential aliasing of complex pointer inquiry references
[PR118120]

PR fortran/118120
PR fortran/113928

gcc/fortran/ChangeLog:

* trans-array.cc (symbols_could_alias): If one symbol refers to a
complex type and the other to a real type of the same kind, do not
a priori exclude the possibility of aliasing.

gcc/testsuite/ChangeLog:

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

[Bug libstdc++/118156] New: flat_set::insert_range cannot handle non-common ranges

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 118156
   Summary: flat_set::insert_range cannot handle non-common ranges
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 
#include 

int main() {
  std::flat_set m;
  m.insert_range(std::views::iota(0) | std::views::take(5));
}

https://godbolt.org/z/Wzah6Ms67

[Bug tree-optimization/118154] New: [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since 15-5117-g0b27a7dd050

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 118154
   Summary: [15 Regression] RISC-V: Miscompile with -march=rv64gcv
-O3 since 15-5117-g0b27a7dd050
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
long a;
signed char b;
long long d;
signed char c[22][22][484];
void m(long long *l, int n) { *l ^= n + (*l >> 2); }
int main() {
  signed char l = 35;
  for (signed char f = 4; f; f++) {
for (signed g = 0; g < 022; g += 4)
  for (signed char h = 0; h < 022; h++) {
c[9][g][h * 22 + h] = l;
a = ({ a > 4095 ? a : 4095; });
  }
for (int i = 0; i < 22; i += 3)
  for (signed char j = 1; j; j++)
for (signed char k = 0; k < 022; k++)
  b = ({ b > 19 ? b : 19; });
  }
  for (long f = 0; f < 22; ++f)
for (long g = 0; g < 22; ++g)
  for (long h = 0; h < 22; ++h)
for (long i = 0; i < 22; ++i)
  m(&d, c[f][g][h * 2 + i]);
  if (d != 38)
return 1;
}

Commands:
/scratch/tc-testing/tc-compiler-fuzz-bisect/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
-march=rv64gcv -O3 test.c -o user-config.out -fno-strict-aliasing -fwrapv
QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve32x=true,zve64d=true,zve64f=true,zve64x=true
timeout --verbose -k 0.1 4
/scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64
user-config.out

Found via fuzzer

First bad commit: r15-5117-g0b27a7dd050

[Bug target/118133] Consider alternative ways of writing aarch64-simd-pragma-builtins.def

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

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

--- Comment #3 from Richard Sandiford  ---
The reason I went for m4 is that it means we don't need to write a parser, or
come up with a DSL.  I was hoping that the scaffolding would be pretty much
write-and-forget, with only the main (declarative)
aarch64-simd-pragma-builtins.m4 changing.

Personally I agree that requiring python for development should be fine.  But
if we did use python, I think the script should generate the output directly,
rather than parse some ad-hoc DSL.  In other words, the definition file would
be imperative rather than declarative and would have full access to python
features.

[Bug tree-optimization/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/118155] New: Extend -Wtautological-compare for pointer addition

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

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

Bug ID: 118155
   Summary: Extend -Wtautological-compare for pointer addition
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

For

```
using size_t = decltype(sizeof(0));
bool incorrect_overflow_check(const char *ptr, size_t index) {
return ptr + index < ptr; // warning
}
```

clang++ now emits:

q.C:3:24: warning: pointer comparison always evaluates to false
[-Wtautological-compare]
3 | return ptr + index < ptr; // warning
  |^

We should consider implementing this for GCC 16.

See https://github.com/llvm/llvm-project/pull/120222/files for more details.

[Bug fortran/113928] Aliasing of pointer in expression

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r15-6395-gaed4a2689dbc8ea7e60c1fab9e7f455d99e632b7
Author: Harald Anlauf 
Date:   Thu Dec 19 22:22:52 2024 +0100

Fortran: potential aliasing of complex pointer inquiry references
[PR118120]

PR fortran/118120
PR fortran/113928

gcc/fortran/ChangeLog:

* trans-array.cc (symbols_could_alias): If one symbol refers to a
complex type and the other to a real type of the same kind, do not
a priori exclude the possibility of aliasing.

gcc/testsuite/ChangeLog:

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

[Bug fortran/118120] Wrong aliasing assumptions for Fortran POINTERs

[szakharin at nvidia dot com via Gcc-bugs]

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

--- Comment #14 from Slava Zakharin  ---
Thank you for the quick fix!

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

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

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

--- Comment #21 from Andrew Pinski  ---
(In reply to David Binderman from comment #20)
> From the See also bug report, # 118138,
> I tried out -fno-inline and, for the two test cases here,
> the problem seemed to go away.

Try -fno-ipa-cp

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

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #22 from David Binderman  ---
(In reply to Andrew Pinski from comment #21)
> Try -fno-ipa-cp

As expected, that avoids the problem too:

foundBugs $ ../results/bin/gcc -O1 -w bug1071.c && ./a.out 1 > /tmp/0
foundBugs $ ../results/bin/gcc -O2 -w bug1071.c && ./a.out 1 > /tmp/1
foundBugs $ ../results/bin/gcc -O2 -fno-ipa-cp -w bug1071.c && ./a.out 1 >
/tmp/2
foundBugs $ ls -l /tmp/?
-rw-r--r--. 1 dcb40b dcb40b 18267 Dec 20 09:03 /tmp/0
-rw-r--r--. 1 dcb40b dcb40b 18272 Dec 20 09:03 /tmp/1
-rw-r--r--. 1 dcb40b dcb40b 18267 Dec 20 09:03 /tmp/2
foundBugs $ diff /tmp/0 /tmp/2

foundBugs $ ../results/bin/gcc -O1 -w bug1071B.c && ./a.out 1 > /tmp/0
foundBugs $ ../results/bin/gcc -O2 -w bug1071B.c && ./a.out 1 > /tmp/1
foundBugs $ ../results/bin/gcc -O2 -fno-ipa-cp -w bug1071B.c && ./a.out 1 >
/tmp/2
foundBugs $ ls -l /tmp/?
-rw-r--r--. 1 dcb40b dcb40b 44153 Dec 20 09:05 /tmp/0
-rw-r--r--. 1 dcb40b dcb40b 44156 Dec 20 09:05 /tmp/1
-rw-r--r--. 1 dcb40b dcb40b 44153 Dec 20 09:05 /tmp/2
foundBugs $ diff /tmp/0 /tmp/2
foundBugs $

[Bug fortran/116254] new test case gfortran.dg/class_transformational_2.f90 from r15-2739-g4cb07a38233aad fails

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
(In reply to Richard Sandiford from comment #10)
> A bit more info: valgrind succeeds for -O0.  But with optimisation enabled
> (-O is enough), it flags:
> 
> ==12989== Conditional jump or move depends on uninitialised value(s)
> ==12989==at 0x49B47A0: _gfortran_spread (spread_generic.c:278)
> ==12989==by 0x401227: check_spread (class_transformational_2.f90:56)
> ==12989==by 0x401227: MAIN__ (class_transformational_2.f90:20)
> ==12989==by 0x4035C3: main (class_transformational_2.f90:24)
> 
> It seems that the _data._desc field of the spread results are being copied
> from uninitialised memory.  .gimple has:
> 
> __attribute__((fn spec (". ")))
> void check_spread ()
> {
>   …
>   {
> …
> struct array02_character(kind=1) atmp.98;
> struct __class_MAIN___T_2_0a ctmp.99;
> …
> try
>   {
> …
> ctmp.99 = b;
> ctmp.99._data = atmp.98;
> ctmp.99._data.span = D.3687;
> ctmp.99._data.data = 0B;
> ctmp.99._data.offset = 0;
> _gfortran_spread (&ctmp.99._data, D.3682, D.3684, D.3686);
> 
> where nothing has initialised atmp.98 before the copy.

Hi Richard, Thanks for tracking that down. I'm on to it. Paul

[Bug c++/118074] [coroutine] Possible over optimization of co_return

[newsigma at 163 dot com via Gcc-bugs]

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

--- Comment #7 from Weibo He  ---
Thanks, @Yanzuo Liu

It seems there are three issues with the bug:

1. [GCC 15 Regression]: Bad interaction with NRV for the trunk

2. [GCC 15 Regression]: Return object is being prematurely converted

Clang community resolved a similar issue:
https://github.com/llvm/llvm-project/issues/56532

https://godbolt.org/z/aE7jMxoE5

Expected Output(GCC 10 ~ 14):
return_void
final suspend
A&&

Wrong Output(GCC 15):
A&&
return_void
final suspend

3. [Undefined behaviour]: When should the result object is initialized?

(1) According to
CWG2563(https://github.com/GorNishanov/await/blob/master/2023_Issaquah/cwg2563-response.md),
for the third common pattern of coroutine:

> get_return_object returns a proxy, coroutine body executes, conversion to 
> return type happens when coroutine return the caller.
> Need coroutine body to execute before initialising the return-value since 
> coroutine body produces the result.

which says conversion occurs when a coroutine returns to the caller. Referring
to cppreference, we can conclude that conversion happens after await_suspend()
if and only if it returns to the caller/resumer.

> if await_suspend returns void, control is immediately returned to the 
> caller/resumer of the current coroutine (this coroutine remains suspended), 
> otherwise
> if await_suspend returns bool,
> the value true returns control to the caller/resumer of the current 
> coroutine
> the value false resumes the current coroutine.
> if await_suspend returns a coroutine handle for some other coroutine, that 
> handle is resumed (by a call to handle.resume()) (note this may chain to 
> eventually cause the current coroutine to resume).
> if await_suspend throws an exception, the exception is caught, the coroutine 
> is resumed, and the exception is immediately re-thrown.

Note that return_value() happens before final_suspend(), I consider the
behavior is well defined.

(2) Agree with your second point:

9.5.4 [dcl.fct.def.coroutine] paragraph 11 reads:

> The coroutine state is destroyed when control flows off the end of the 
> coroutine
> or the destroy member function ([coroutine.handle.resumption]) of a coroutine 
> handle ([coroutine.handle]) that refers to the coroutine is invoked.

If I am not misunderstanding, 'flows off the end of the coroutine' occurs
before 'returning to the caller'. It is unclear whether return value
initialization happens before or after destruction. And the wording 'flows off
the end of the coroutine' seems too strict. I suggest the following change:

> The coroutine state is destroyed when returns from the await_resume() of 
> final_suspend
> or the destroy member function ([coroutine.handle.resumption]) of a coroutine 
> handle ([coroutine.handle]) that refers to the coroutine is invoked.

Note that initialization will be done before destruction of coroutine state.

Maybe we should seperate this bug into three.

[Bug tree-optimization/117830] [15 Regression] Miscompilation of 464.h264ref at -O2 -march=generic since r15-5563-g1c4d39ada33d36

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

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

Christoph Müllner  changed:

   What|Removed |Added

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

--- Comment #7 from Christoph Müllner  ---
The patch was approved and has been pushed to master:
 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=eee2891312a9b42acabcc82739604c9fa8421757

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

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

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

Bug 117830 Summary: [15 Regression] Miscompilation of 464.h264ref at -O2 
-march=generic since r15-5563-g1c4d39ada33d36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117830

   What|Removed |Added

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

[Bug c/118148] New: Miscompilation at -Os

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

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

Bug ID: 118148
   Summary: Miscompilation at -Os
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

This code prints 256 at -Os and 0 at -O0/1/2/3:

```c
int printf(const char *, ...);
short a;
int b;
short *c = &a;
static int(d)(int e, unsigned f) { return e < 0 || f ? e : 0; }
static char g(long e, unsigned char f) {
  f++;
  b = d(f, e);
  *c = b;
  return 0;
}
int main() {
  g(4073709551609, 255);
  printf("%d\n", a);
}

```

Bisected to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=96fb71883d438bdb241fdf9c7d12f945c5ba0c7f

Compiler Explorer: https://godbolt.org/z/3d8bWv9Kc

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

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #20 from David Binderman  ---
>From the See also bug report, # 118138,
I tried out -fno-inline and, for the two test cases here,
the problem seemed to go away.

foundBugs $ ../results/bin/gcc -O1 -w bug1071.c && ./a.out 1 > /tmp/0
foundBugs $ ../results/bin/gcc -O2 -w bug1071.c && ./a.out 1 > /tmp/1
foundBugs $ ../results/bin/gcc -O2 -fno-inline -w bug1071.c && ./a.out 1 >
/tmp/2
foundBugs $ ls -l /tmp/?
-rw-r--r--. 1 dcb40b dcb40b 18267 Dec 20 08:07 /tmp/0
-rw-r--r--. 1 dcb40b dcb40b 18272 Dec 20 08:07 /tmp/1
-rw-r--r--. 1 dcb40b dcb40b 18267 Dec 20 08:07 /tmp/2
foundBugs $ diff /tmp/0 /tmp/2
foundBugs $ diff /tmp/0 /tmp/1 | head -3
5,18c5,18
< ...checksum after hashing g_90 : F239C101
< ...checksum after hashing g_117 : 1EC91E0E
foundBugs $ 


foundBugs $ ../results/bin/gcc -O1 -w bug1071B.c && ./a.out 1 > /tmp/0
foundBugs $ ../results/bin/gcc -O2 -w bug1071B.c && ./a.out 1 > /tmp/1
foundBugs $ ../results/bin/gcc -O2 -fno-inline -w bug1071B.c && ./a.out 1 >
/tmp/2
foundBugs $ ls -l /tmp/?
-rw-r--r--. 1 dcb40b dcb40b 44153 Dec 20 08:12 /tmp/0
-rw-r--r--. 1 dcb40b dcb40b 44156 Dec 20 08:12 /tmp/1
-rw-r--r--. 1 dcb40b dcb40b 44153 Dec 20 08:13 /tmp/2
foundBugs $ diff /tmp/0 /tmp/2
foundBugs $ diff /tmp/0 /tmp/1 | head -3
573,584c573,584
< ...checksum after hashing g_412.f4 : 4390B748
< ...checksum after hashing g_453.f0 : D80F7CF1
foundBugs $

[Bug ipa/118148] [15 regression] Miscompilation at -Os since r15-6294-g96fb71883d438b

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

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

Sam James  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
Summary|Miscompilation at -Os   |[15 regression]
   ||Miscompilation at -Os since
   ||r15-6294-g96fb71883d438b
   Keywords||wrong-code
  Component|c   |ipa
   Target Milestone|--- |15.0

[Bug c++/110345] [C++26] P2552R3 - On the ignorability of standard attributes

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

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

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

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

commit r15-6384-gcd647514a539943ade6461efbf056a7c3f4305c6
Author: Jakub Jelinek 
Date:   Fri Dec 20 10:12:08 2024 +0100

c++: Disallow [[deprecated]] on types other than class/enum definitions
[PR110345]

For C++ 26 P2552R3 I went through all the spots (except modules) where
attribute-specifier-seq appears in the grammar and tried to construct
a testcase in all those spots, for now for [[deprecated]] attribute.

The patch below contains that testcase.  One needed change for this
particular attribute was that currently we handle [[deprecated]]
exactly the same as [[gnu::deprecated]], but for the latter unlike C++14
or later we allow it also on almost all types, while the standard
is strict and allows it only on
https://eel.is/c++draft/dcl.attr#deprecated-2
The attribute may be applied to the declaration of a class, a typedef-name,
a variable, a non-static data member, a function, a namespace,
an enumeration, an enumerator, a concept, or a template specialization.

The following patch just adds a pedwarn for the cases that gnu::deprecated
allows but C++14 disallows, so integral/floating/boolean types,
pointers/references, array types, function types etc.
Basically, for TYPE_P, if the attribute is applied in place (which means
the struct/union/class/enum definition), it is allowed, otherwise
pedwarned.

I've tried to compile it also with latest clang and there is agreement in
most of the diagnostics, just at block scope (inside of foo) it doesn't
diagnose
  auto e = new int [n] [[deprecated]];
  auto e2 = new int [n] [[deprecated]] [42];
  [[deprecated]] lab:;
and at namespace scope
[[deprecated]];
I think that all feels like clang++ bug.

Also this pedwarns on
  [[deprecated]] int : 0;
at class scope, that isn't a non-static data member...

I guess to mark the paper as implemented (or what has been already voted
into C++23 earlier) we'll need to add similar testcase for all the other
standard attributes and make sure we check what the attributes can
appertain
to and what they can't.

2024-12-19  Jakub Jelinek  

PR c++/110345
* parser.cc (cp_parser_std_attribute): Don't transform
[[deprecated]] into [[gnu::deprecated]].
* tree.cc (handle_std_deprecated_attribute): New function.
(std_attributes): Add deprecated entry.

* g++.dg/cpp0x/attr-deprecated1.C: New test.

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

https://gcc.gnu.org/g:92216cbc59b3a4566d49de5dfa059b70b03d639a

commit r15-6385-g92216cbc59b3a4566d49de5dfa059b70b03d639a
Author: Jakub Jelinek 
Date:   Fri Dec 20 10:17:56 2024 +0100

c++: Fix up maybe_unused attribute handling [PR110345]

When adding test coverage for maybe_unused attribute, I've run into
several things:
1) similarly to deprecated attribute, the attribute shouldn't pedantically
   appertain to types other than class/enumeration definitions
2) similarly to deprecated attribute, the attribute shouldn't pedantically
   appertain to unnamed bit-fields
3) the standard says that it can appertain to identifier labels, but
   we handled it silently also on case and default labels
4) I've run into a weird spurious error on
   int f [[maybe_unused]];
   int & [[maybe_unused]] i = f;
   int && [[maybe_unused]] j = 0;
   The problem was that we create an attribute variant for the int &
   type, then create an attribute variant for the int && type, and
   the type_canon_hash hashing just thought those 2 are the same,
   so used int & [[maybe_unused]] type for j rather than
   int && [[maybe_unused]].  As TYPE_REF_IS_RVALUE is a flag in the
   generic code, it was easily possible to hash that flag and compare
   it

2024-12-19  Jakub Jelinek  

PR c++/110345
gcc/
* tree.cc (type_hash_canon_hash): Hash TYPE_REF_IS_RVALUE for
REFERENCE_TYPE.
(type_cache_hasher::equal): Compare TYPE_REF_IS_RVALUE for
REFERENCE_TYPE.
gcc/cp/
* tree.cc (handle_maybe_unused_attribute): New function.
(std_attributes): Use handle_maybe_unused_attribute instead
of handle_unused_attribute for maybe_unused attribute.
gcc/testsuite/
* g++.dg/cpp0x/attr-maybe_unused1.C: New test.
* g++.dg/cpp0x/alignas21.C: Add test for int && alignas (int).

[Bug c++/110345] [C++26] P2552R3 - On the ignorability of standard attributes

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

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

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

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

commit r15-6384-gcd647514a539943ade6461efbf056a7c3f4305c6
Author: Jakub Jelinek 
Date:   Fri Dec 20 10:12:08 2024 +0100

c++: Disallow [[deprecated]] on types other than class/enum definitions
[PR110345]

For C++ 26 P2552R3 I went through all the spots (except modules) where
attribute-specifier-seq appears in the grammar and tried to construct
a testcase in all those spots, for now for [[deprecated]] attribute.

The patch below contains that testcase.  One needed change for this
particular attribute was that currently we handle [[deprecated]]
exactly the same as [[gnu::deprecated]], but for the latter unlike C++14
or later we allow it also on almost all types, while the standard
is strict and allows it only on
https://eel.is/c++draft/dcl.attr#deprecated-2
The attribute may be applied to the declaration of a class, a typedef-name,
a variable, a non-static data member, a function, a namespace,
an enumeration, an enumerator, a concept, or a template specialization.

The following patch just adds a pedwarn for the cases that gnu::deprecated
allows but C++14 disallows, so integral/floating/boolean types,
pointers/references, array types, function types etc.
Basically, for TYPE_P, if the attribute is applied in place (which means
the struct/union/class/enum definition), it is allowed, otherwise
pedwarned.

I've tried to compile it also with latest clang and there is agreement in
most of the diagnostics, just at block scope (inside of foo) it doesn't
diagnose
  auto e = new int [n] [[deprecated]];
  auto e2 = new int [n] [[deprecated]] [42];
  [[deprecated]] lab:;
and at namespace scope
[[deprecated]];
I think that all feels like clang++ bug.

Also this pedwarns on
  [[deprecated]] int : 0;
at class scope, that isn't a non-static data member...

I guess to mark the paper as implemented (or what has been already voted
into C++23 earlier) we'll need to add similar testcase for all the other
standard attributes and make sure we check what the attributes can
appertain
to and what they can't.

2024-12-19  Jakub Jelinek  

PR c++/110345
* parser.cc (cp_parser_std_attribute): Don't transform
[[deprecated]] into [[gnu::deprecated]].
* tree.cc (handle_std_deprecated_attribute): New function.
(std_attributes): Add deprecated entry.

* g++.dg/cpp0x/attr-deprecated1.C: New test.

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

https://gcc.gnu.org/g:92216cbc59b3a4566d49de5dfa059b70b03d639a

commit r15-6385-g92216cbc59b3a4566d49de5dfa059b70b03d639a
Author: Jakub Jelinek 
Date:   Fri Dec 20 10:17:56 2024 +0100

c++: Fix up maybe_unused attribute handling [PR110345]

When adding test coverage for maybe_unused attribute, I've run into
several things:
1) similarly to deprecated attribute, the attribute shouldn't pedantically
   appertain to types other than class/enumeration definitions
2) similarly to deprecated attribute, the attribute shouldn't pedantically
   appertain to unnamed bit-fields
3) the standard says that it can appertain to identifier labels, but
   we handled it silently also on case and default labels
4) I've run into a weird spurious error on
   int f [[maybe_unused]];
   int & [[maybe_unused]] i = f;
   int && [[maybe_unused]] j = 0;
   The problem was that we create an attribute variant for the int &
   type, then create an attribute variant for the int && type, and
   the type_canon_hash hashing just thought those 2 are the same,
   so used int & [[maybe_unused]] type for j rather than
   int && [[maybe_unused]].  As TYPE_REF_IS_RVALUE is a flag in the
   generic code, it was easily possible to hash that flag and compare
   it

2024-12-19  Jakub Jelinek  

PR c++/110345
gcc/
* tree.cc (type_hash_canon_hash): Hash TYPE_REF_IS_RVALUE for
REFERENCE_TYPE.
(type_cache_hasher::equal): Compare TYPE_REF_IS_RVALUE for
REFERENCE_TYPE.
gcc/cp/
* tree.cc (handle_maybe_unused_attribute): New function.
(std_attributes): Use handle_maybe_unused_attribute instead
of handle_unused_attribute for maybe_unused attribute.
gcc/testsuite/
* g++.dg/cpp0x/attr-maybe_unused1.C: New test.
* g++.dg/cpp0x/alignas21.C: Add test for int && alignas (int).

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

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

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

--- Comment #23 from Sam James  ---
I'm giving reduction a go too.

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

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

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

--- Comment #24 from Sam James  ---
Created attachment 59932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59932&action=edit
pr118097-sam-partial.c

Still going but here's a checkpoint.

[Bug c++/110345] [C++26] P2552R3 - On the ignorability of standard attributes

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
I think at this point this is mostly implemented, except that tests for
nodiscard/noreturn/no_unique_address
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
weren't reviewed yet.  But those only add tests, don't change the
FE/middle-end.

[Bug tree-optimization/116813] std::vector index check not optimized out with -O2

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |needs-reduction

--- Comment #4 from Sam James  ---
(In reply to Sam James from comment #3)
> Looks like this is OK on trunk now. Probably honza's fixes sorted this.

Actually, it was fixed by a library change: r15-4475-g7ed561f63e7955. So needs
a reduction that is standalone (from before that change).

[Bug lto/118136] Linking start code built with -flto with application where main signature does not match causes warning

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|INVALID |---
   Last reconfirmed||2024-12-20
 Ever confirmed|0   |1
 Status|RESOLVED|NEW

--- Comment #11 from Richard Earnshaw  ---
Appealing to the C standard for claiming the startup code is not conforming is
a straw-man.  The standard does not specify how startup code works: it's an
implementation detail.  

Nevertheless, the compiler has to support building such code somehow, which
means it needs to support being able to call both forms of main specified by
the standard.

So this is not about what the standard says about functions that call main but
about how /GCC/ can support building startup code.

[Bug c++/118124] [15 Regression] ICE in in expand_expr_real_2, at expr.cc:9761 on nss-3.101.2

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

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

--- Comment #3 from Sergei Trofimovich  ---
Proposed change fixed `nss-3.101.2` build for me. Thank you!

[Bug target/118140] [14/15 Regression] RISC-V: Miscompile with -march=rv64gcv_zvl256b -O3 since r14-5076-g01c18f58d37

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

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

--- Comment #8 from Robin Dapp  ---
The optimized tree looks good apart from 'd' and the return value :)

   [local count: 76665171]:
  e_lsm.8_12 = e;
  _55 = .MASK_LEN_LOAD (&MEM <_Bool[17]> [(void *)&f + 4B], 8B, { -1, ... },
_54(D), 13, 0);
  vect__10.16_59 = .VCOND_MASK_LEN ({ -1, ... }, _55, { 0, ... }, 13, 0);
  _61 = .REDUC_PLUS (vect__10.16_59);
  _62 = e_lsm.8_12 + _61;
  d = 1;
  e = _62;
  return 1;

Already during/after vectorization we have:

...
  # prephitmp_41 = PHI <1(3)>
  # vect__10.16_60 = PHI 
  _61 = .REDUC_PLUS (vect__10.16_60);
  _62 = _61 + e_lsm.8_12;
  # .MEM_29 = VDEF <.MEM_46>
  dD.2785 = prephitmp_41;
  # .MEM_30 = VDEF <.MEM_29>
  eD.2786 = _62;
  # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
  _13 = (intD.1) prephitmp_41;
  # VUSE <.MEM_30>
  return _13;

where prephitmp_41 seems just wrong.

[Bug fortran/118159] [Docs][Link rot] Fortran coco is now an online casino

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-12-21

--- Comment #2 from Andrew Pinski  ---
[apinski@xeond2 fortran]$ git diff invoke.texi
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index ff4040732d8..ab708db89b6 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -662,8 +662,7 @@ include code for these additional kind types:
@code{__GFC_INT_1__},
 While CPP is the de-facto standard for preprocessing Fortran code,
 Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
 Conditional Compilation, which is not widely used and not directly
-supported by the GNU Fortran compiler.  You can use the program coco
-to preprocess such files (@uref{http://www.daniellnagle.com/coco.html}).
+supported by the GNU Fortran compiler.

 The following options control preprocessing of Fortran code:

[Bug fortran/51820] [doc] underscoring documentation incorrect

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
Thanks Sandra

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #5)
> Yes the original C++20 standard was written that way but was changed by LWG
> DR 2937 : https://cplusplus.github.io/LWG/issue2937 .

C++17 said (is_other(s1) && is_other(s2)) was an error. LWG 2937 was approved
in July 2017, so the resolution was always in C++20.

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-12-20
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Do you have a testcase?

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

--- Comment #2 from Sam James  ---
(also, what platform?)

[Bug rtl-optimization/117999] [15 regression] libgo failures on arm

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #10 from Sam James  ---
Thanks. Given Vlad has fixed the newer issues, let's close this one, and we can
open another bug for the other, older ones I mentioned if someone wants.

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

--- Comment #3 from Andrew Pinski  ---
So it does this equivalent does:
  if (is_other(s1) && is_other(s2))
{
  ec = std::__unsupported();
  return false;
}


Where is_other is defined as:
  [[nodiscard]]
  inline bool
  is_other(file_status __s) noexcept
  {
return exists(__s) && !is_regular_file(__s) && !is_directory(__s)
  && !is_symlink(__s);
  }

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Andrew Pinski  ---
Looks like https://cplusplus.github.io/LWG/issue2937 changed the wording and
removes the "(is_other(s1) && is_other(s2))" part

[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files

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

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

--- Comment #5 from Andrew Pinski  ---
>Is there a reason for this limitation?

Yes the original C++20 standard was written that way but was changed by LWG DR
2937 : https://cplusplus.github.io/LWG/issue2937 .

[Bug go/118152] [12/13/14/15 regression] libgo sync/atomic fails since g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm

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

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

--- Comment #3 from Christophe Lyon  ---


> It might be helpful to see the dissassembled code of
> sync/atomic_test.TestNilDeref..func30.

Sorry for the naive question: where can I find it?

In my build tree, I have:

armv8l-unknown-linux-gnueabihf/libgo/sync/
atomic/  atomic_c.lo  atomic_c.o  atomic.gox  atomic.lo  atomic.lo.dep 
atomic.o  atomic.s-gox  check-testlog  check-testsum

and then
armv8l-unknown-linux-gnueabihf/libgo/sync/atomic/
check-testlog  check-testsum

I looked into armv8l-unknown-linux-gnueabihf/libgo/sync/atomic.o but could not
find this symbol

and libgo.log does not contain the compilation command, unlike gcc.log for
instance.

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

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

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

Bug 51820 Summary: [doc] underscoring documentation incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/51820] [doc] underscoring documentation incorrect

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
 CC||sandra at gcc dot gnu.org

--- Comment #7 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug web/118159] [Docs][Link rot] Fortran coco is now an online casino

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Last Wayback Machine snapshot of the page is from March 15, 2023:
http://web.archive.org/web/20230315022712/http://www.daniellnagle.com/coco.html

[Bug go/118152] [12/13/14/15 regression] libgo sync/atomic fails since g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm

[ian at airs dot com via Gcc-bugs]

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

--- Comment #4 from Ian Lance Taylor  ---
Oh, sorry, it's a test.  It's not left behind in the tree.  In the
armv8l-unknown-linux-gnueabihf/libgo directory you can run

make GOTESTFLAGS=--keep sync/atomic/check

That will leave behind a temporary directory gotestN.  In the subdirectory
of that directory named "test" the program named "a.out" is the test program
that is run.  In that program there should be a function named
sync_1atomic__test.TestNilDeref..func30.  That is the function that is
crashing, according to the backtrace you showed.  A disassembly of that
function may or may not help.  Thanks.

[Bug target/118142] libatomic fails to build for AARCH64:ILP32

[zhangtianhao6 at huawei dot com via Gcc-bugs]

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

--- Comment #4 from zhangtianhao (F)  ---
(In reply to Andrew Pinski from comment #3)
> As I mentioned glibc support for ILP32 is not upstream so there is no
> defined HWCAPS for ILP32.
> 
> Are you going to submit Kernel/glibc patches for ILP32 any time soon? I have
> no interest them any more even though I was the original developer of it
> even.

But now libatomic fails to build for aarch64 ilp32, how to disposal?

[Bug target/117952] host_detect_local_cpu returns NULL when built with Clang

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

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

--- Comment #4 from Andrew Pinski  ---
Note cpuid.h is already in use.
Including it will cause to use the GCC version I think.

That might be part of the issue.

[Bug target/80813] [12/13/14/15 Regression] x86: std::vector::operator[] could be somewhat faster using BT instead of SHL

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

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

--- Comment #5 from Jan Hubicka  ---
Combine constructs:

(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:DI (mem:DI (plus:DI (mult:DI (reg:DI 111 [ _8 ])
(const_int 8 [0x8]))
(reg/f:DI 112 [
v_2(D)->D.25666._M_impl.D.25135._M_start.D.16486._M_p ])) [3 *_10+0 S8 A64])
(const_int 1 [0x1])
(subreg:QI (reg:SI 116 [ _12 ]) 0))
(const_int 0 [0])))

While bt pattern is:


(define_insn "*bt"
  [(set (reg:CCC FLAGS_REG)
(compare:CCC
  (zero_extract:SWI48
(match_operand:SWI48 0 "nonimmediate_operand" "r,m")
(const_int 1)
(match_operand:QI 1 "nonmemory_operand" "q,"))
  (const_int 0)))]
  ""
{
  switch (get_attr_mode (insn))
{
case MODE_SI:
  return "bt{l}\t{%k1, %k0|%k0, %k1}";

case MODE_DI:
  return "bt{q}\t{%q1, %0|%0, %q1}";

default:
  gcc_unreachable ();
}
} 
  [(set_attr "type" "alu1")
   (set_attr "prefix_0f" "1")
   (set (attr "mode")
(if_then_else
  (and (match_test "CONST_INT_P (operands[1])")
   (match_test "INTVAL (operands[1]) < 32"))
  (const_string "SI")
  (const_string "")))])

It fails since BT produces carry while we want zero flag...

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

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

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

commit r15-6391-g6ecb365d4c3f36eaf684c38fc5d9008a1409c725
Author: Tamar Christina 
Date:   Fri Dec 20 14:25:50 2024 +

AArch64: Disable `omp declare variant' tests for aarch64 [PR96342]

These tests are x86 specific and shouldn't be run for aarch64.

gcc/testsuite/ChangeLog:

PR target/96342
* c-c++-common/gomp/declare-variant-14.c: Make i?86 and x86_64
target
only test.
* gfortran.dg/gomp/declare-variant-14.f90: Likewise.

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

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

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

commit r15-6392-gd7d3dfe7a2a26e370805ddf835bfd00c51d32f1b
Author: Tamar Christina 
Date:   Fri Dec 20 14:27:25 2024 +

AArch64: Add SVE support for simd clones [PR96342]

This patch finalizes adding support for the generation of SVE simd clones
when
no simdlen is provided, following the ABI rules where the widest data type
determines the minimum amount of elements in a length agnostic vector.

gcc/ChangeLog:

PR target/96342
* config/aarch64/aarch64-protos.h (add_sve_type_attribute):
Declare.
* config/aarch64/aarch64-sve-builtins.cc (add_sve_type_attribute):
Make
visibility global and support use for non_acle types.
* config/aarch64/aarch64.cc
(aarch64_simd_clone_compute_vecsize_and_simdlen): Create VLA simd
clone
when no simdlen is provided, according to ABI rules.
(simd_clone_adjust_sve_vector_type): New helper function.
(aarch64_simd_clone_adjust): Add '+sve' attribute to SVE simd
clones
and modify types to use SVE types.
* omp-simd-clone.cc (simd_clone_mangle): Print 'x' for VLA simdlen.
(simd_clone_adjust): Adapt safelen check to be compatible with VLA
simdlen.

gcc/testsuite/ChangeLog:

PR target/96342
* gcc.target/aarch64/declare-simd-2.c: Add SVE clone scan.
* gcc.target/aarch64/vect-simd-clone-1.c: New test.
* g++.target/aarch64/vect-simd-clone-1.C: New test.

Co-authored-by: Victor Do Nascimento 
Co-authored-by: Tamar Christina 

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

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

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

commit r15-6393-g89b2c7dc96c4944c306131b665a4738a8a99413e
Author: Tamar Christina 
Date:   Fri Dec 20 14:34:32 2024 +

AArch64: Implement vector concat of partial SVE vectors [PR96342]

This patch adds support for vector constructor from two partial SVE vectors
into
a full SVE vector. It also implements support for the standard vec_init
obtab to
do this.

gcc/ChangeLog:

PR target/96342
* config/aarch64/aarch64-protos.h
(aarch64_sve_expand_vector_init_subvector): New.
* config/aarch64/aarch64-sve.md (vec_init): New.
(@aarch64_pack_partial): New.
* config/aarch64/aarch64.cc
(aarch64_sve_expand_vector_init_subvector): New.
* config/aarch64/iterators.md (SVE_NO2E): New.
(VHALF, Vhalf): Add SVE partial vectors.

gcc/testsuite/ChangeLog:

PR target/96342
* gcc.target/aarch64/vect-simd-clone-2.c: New test.

[Bug target/80813] [12/13/14/15 Regression] x86: std::vector::operator[] could be somewhat faster using BT instead of SHL

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

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

--- Comment #3 from Jan Hubicka  ---
OK, so the horrid codegen is because bvector's [] operator is imlemented using
iterator:
  return begin()[__n];
iterator's [] operator is implemented using:

_GLIBCXX20_CONSTEXPR
void
_M_incr(ptrdiff_t __i)
{
  _M_assume_normalized();
  difference_type __n = __i + _M_offset;
  _M_p += __n / int(_S_word_bit);
  __n = __n % int(_S_word_bit);
  if (__n < 0)
{
  __n += int(_S_word_bit);
  --_M_p;
}
  _M_offset = static_cast(__n);
}


So the conditional is a check for negative __n which makes sense for iterator's
[], but not for vector's [].  We could add __builtin_unreachable hint that __n
is at most max_size, but since [] is such a common operation on vectors, I
think it makes sense to make life of compiler easier and micro-optimize it in
the array.

diff --git a/libstdc++-v3/include/bits/stl_bvector.h
b/libstdc++-v3/include/bits/stl_bvector.h
index 341eee33b21..43a07bc3e55 100644
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -1132,7 +1141,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   operator[](size_type __n)
   {
__glibcxx_requires_subscript(__n);
-   return begin()[__n];
+   return _Bit_reference (this->_M_impl._M_start._M_p
+  + __n / int(_S_word_bit),
+  __n % int(_S_word_bit));
   }

   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
@@ -1140,7 +1151,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   operator[](size_type __n) const
   {
__glibcxx_requires_subscript(__n);
-   return begin()[__n];
+   return _Bit_reference (this->_M_impl._M_start._M_p
+  + __n / int(_S_word_bit),
+  __n % int(_S_word_bit));
   }

 protected:

With this I now get:
.LFB1248:
.cfi_startproc
movq(%rdi), %rax
movq%rsi, %rdx
shrq$6, %rdx
andq(%rax,%rdx,8), %rsi
andl$63, %esi
setne   %al
ret
that is certainly better. Still does not use BT.
Not sure if _M_incr can be tweaked for less horrid codegen.

[Bug target/80813] [12/13/14/15 Regression] x86: std::vector::operator[] could be somewhat faster using BT instead of SHL

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

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

--- Comment #4 from Jan Hubicka  ---
Bit_reference constructor takes mask and not bit position.
  _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
  reference
  operator[](size_type __n)
  { 
__glibcxx_requires_subscript(__n);
return _Bit_reference (this->_M_impl._M_start._M_p
   + __n / int(_S_word_bit),
   1UL << __n % int(_S_word_bit));
  }

  _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
  const_reference
  operator[](size_type __n) const
  { 
__glibcxx_requires_subscript(__n);
return _Bit_reference (this->_M_impl._M_start._M_p
   + __n / int(_S_word_bit),
   1UL << __n % int(_S_word_bit));
  }
this gets us back to original code:
_Z1fRKSt6vectorIbSaIbEEm:
.LFB1248:
.cfi_startproc
movq%rdi, %rax
movq%rsi, %rdi
movl%esi, %ecx
movq(%rax), %rdx
shrq$6, %rdi
movl$1, %eax
salq%cl, %rax
andq(%rdx,%rdi,8), %rax
setne   %al
ret

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop) since r15-5563

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

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

Christoph Müllner  changed:

   What|Removed |Added

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

--- Comment #8 from Christoph Müllner  ---
Thanks for reporting!

I've analyzed this, and indeed, this got fixed with the recent fix for
PR117830.

When calculating the lane allocation for the blended sequence, we did:
  while (lane_assignment[l] != 0)
l++;
That got fixed so that we won't access out of bounds.

I've sent a patch that adds the reduced testcase to the test suite.

[Bug target/116347] [13/14/15 only] RISC-V: Duplicate entries for -mtune in --target-help

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

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

Christoph Müllner  changed:

   What|Removed |Added

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

--- Comment #4 from Christoph Müllner  ---
Patch was accepted and has been pushed on master:
 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8af296c290216e03bc20e7291e64c19e0d94cfd6

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop) since r15-5563

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[15 regression] ICE when|[15 regression] ICE when
   |building lsp-plugins-1.2.14 |building lsp-plugins-1.2.14
   |(mmap: Cannot allocate  |(mmap: Cannot allocate
   |memory in forwprop) |memory in forwprop) since
   ||r15-5563

--- Comment #5 from Jakub Jelinek  ---
In any case, the ICE started with
r15-5563-g1c4d39ada33d3655db088a0e5c90a296da794a55
And will need to verify if it hasn't been fixed with r15-6387

[Bug ipa/118138] [15 Regression] wrong code at -O3 with "-fno-inline" on x86_64-linux-gnu since r15-6294-g96fb71883d438b

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

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

--- Comment #3 from Martin Jambor  ---
I'll have a look, though I may not be able to do so in December.

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

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #25 from Martin Jambor  ---
At this point I strongly suspect that this is the same problem as PR 118138. 
As I wrote, there, I will have a look, although I may only be able to do so in
January.

[Bug rtl-optimization/118067] [15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1860 (unable to find a register to spill) {*lshrhi3_1} with -O -fno-split-wide-types -mavx512f

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 59935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59935&action=edit
Target-dependant patch

SImode and DImode moves involving mask registers are valid only with AVX512BW,
so mark relevant alternatives in *movsi_internal and *movdi_internal as such.

Even with the patch, the testcase still fails, but now with:

pr118067.c: In function ‘foo’:
pr118067.c:13:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
   13 | }
  | ^
0x2c3b581 internal_error(char const*, ...)
../../git/gcc/gcc/diagnostic-global-context.cc:517
0xb68938 lra_constraints(bool)
../../git/gcc/gcc/lra-constraints.cc:5411
0xb51a0d lra(_IO_FILE*, int)
../../git/gcc/gcc/lra.cc:2449
0xaf9f4d do_reload
../../git/gcc/gcc/ira.cc:5977
0xafa462 execute
../../git/gcc/gcc/ira.cc:6165

which is now suspiciously close (or even duplicate of) PR118017.

So, keep the PR as RA problem.

[Bug target/118017] [15 Regression] ICE: maximum number of generated reload insns per insn achieved (90) with -Og -frounding-math -mno-80387 -mno-mmx since r15-1619-g3b9b8d6cfdf593

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-12-20

[Bug target/118151] New: Relax the SVE PTEST matching conditions for any/none (ne/eq)

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

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

Bug ID: 118151
   Summary: Relax the SVE PTEST matching conditions for any/none
(ne/eq)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: aarch64-sve, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

All our current PTEST combiner patterns are for the general CC_NZC case, where
the eventual condition could be first/not-first/last/not-last/any/none.  For
this general case, it's only usually possible to fold a PTEST with a previous
(potential) flag-setting instruction if both instructions have the same
governing predicate.

However, for the simple any/none (ne/eq) case, it's enough for the PTEST gp to
be a superset of the other instruction's gp.  In particular, we can always fold
if the PTEST is predicated on a PTRUE for the same element width or narrower. 
The failure to handle this case is causing us to miss many folds, both in ACLE
code and in early-break tests.

I think it could be handled by using CC_Z for ne/eq and relaxing
aarch64_sve_same_pred_for_ptest_p for that case.  It might even be a relatively
simple change.

For example:

#include 

int
foo (svbool_t pg, svint32_t x, svint32_t y)
{
  return svptest_any(svptrue_b8(), svcmpeq(pg, x, y));
}

currently generates:

ptrue   p3.b, all
cmpeq   p0.s, p0/z, z0.s, z1.s
ptest   p3, p0.b
csetw0, any
ret

where the ptest and ptrue are redundant.  The same is true with svptrue_b8
replaced by svptrue_b16 or svptrue_b32, but not with svptrue_b64.  (LLVM
optimises the svptrue_b32 case, but not the others.)

We should try to make it so that two tests of the same result, such as
svptest_last and svptest_any, both still use the same PTEST, even if they
initially use different CC modes.

[Bug rtl-optimization/117999] [15 regression] libgo failures on arm

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

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

--- Comment #9 from Christophe Lyon  ---
I have opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152 about the
sync/atomic failure.

[Bug go/118152] New: libgo sync/atomic fails since g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm

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

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

Bug ID: 118152
   Summary: libgo sync/atomic fails since
g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

libgo's sync/atomic has been reported to fail for a long time on arm, and I
have bisected this to commit g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1

I reproduced this by building a native compiler on a Ubuntu-20.04
arm-linux-gnueabihf machine.

[Bug target/118131] [15 regression] ICE in gcc.c-torture/execute/loop-13.c after g:4f4e13dd235bba9c706948a3ecb3e530dd68aad1

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:670df03e5294a31efff1554c9a751ef893dc1f71

commit r15-6389-g670df03e5294a31efff1554c9a751ef893dc1f71
Author: Christophe Lyon 
Date:   Thu Dec 19 16:25:59 2024 +

arm: [MVE intrinsics] Fix moves of tuples (PR target/118131)

Commit r15-6245-g4f4e13dd235b introduced new modes for MVE tuples, but
missed adding support for them in a few places.

Adding them to the list in arm_attr_length_move_neon is not sufficient
since we later face another ICE where the compiler does not know how
to split move of such data.

The patch therefore enhances the define_splits for OI and XI moves in
neon.md, via the introduction of new iterators.

In addition, it seems consistent to update output_move_neon such that
VALID_NEON_*_MODE are used only when TARGET_NEON.

gcc/ChangeLog:

PR target/118131
* config/arm/arm.cc (output_move_neon): Check TARGET_NEON as
needed.
(arm_attr_length_move_neon): Add support for V2x and V4x MVE tuple
modes.
* config/arm/iterators.md (VSTRUCT2, VSTRUCT4): New.
* config/arm/neon.md: Use VSTRUCT2 instead of OI and VSTRUCT4
instead of XI in define_split.

[Bug rtl-optimization/48696] Horrible bitfield code generation on x86

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

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

ptomsich at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ptomsich at gcc dot gnu.org

--- Comment #20 from ptomsich at gcc dot gnu.org ---
(In reply to Konstantinos Eleftheriou from comment #19)
> The two loads could be optimized, given that the small load is contained in
> the larger one. This could be handled by "reload" if we extend the size of
> the small load to the size of the large one.

Note that we are investigating to add the necessary infrastructure in the
store-forward-avoidance pass to merge the two differently-sized loads.

[Bug target/80813] [12/13/14/15 Regression] x86: std::vector::operator[] could be somewhat faster using BT instead of SHL

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|x86:|[12/13/14/15 Regression]
   |std::vector::operator |x86:
   |[] could be somewhat faster |std::vector::operator
   |using BT instead of SHL |[] could be somewhat faster
   ||using BT instead of SHL
 Ever confirmed|0   |1
   Last reconfirmed||2024-12-20

--- Comment #2 from Jan Hubicka  ---
trunk does
f(std::vector > const&, unsigned long):
testq   %rsi, %rsi
leaq63(%rsi), %rax
movq(%rdi), %rdx
cmovns  %rsi, %rax
sarq$6, %rax
leaq(%rdx,%rax,8), %rdx
movq%rsi, %rax
sarq$63, %rax
shrq$58, %rax
addq%rax, %rsi
andl$63, %esi
subq%rax, %rsi
jns .L2
addq$64, %rsi
subq$8, %rdx
.L2:
movl$1, %eax
shlx%rsi, %rax, %rax
andq(%rdx), %rax
setne   %al
ret

Removing basic block 5
bool f (const struct vector & v, size_t x)
{ 
  difference_type __n;
  _Bit_type * const SR.16;
  _Bit_type * _4;
  long int __n.0_5;
  long unsigned int _12;
  long unsigned int _13;
  long unsigned int _14;
  bool _15;
  long int _16;
  long int _20;
  long unsigned int _21;
  long unsigned int _22;
  _Bit_type * _23;
  _Bit_type * _26;
  unsigned int _42;

   [local count: 1073741824]:
  _4 = v_2(D)->D.25666._M_impl.D.25135._M_start.D.16486._M_p;
  __n.0_5 = (long int) x_3(D);
  _20 = __n.0_5 / 64;
  _21 = (long unsigned int) _20;
  _22 = _21 * 8;
  _23 = _4 + _22;
  __n_24 = __n.0_5 % 64;
  if (__n_24 < 0)
goto ; [41.00%]
  else
goto ; [59.00%]

   [local count: 440234144]:
  __n_25 = __n_24 + 64;
  _26 = _23 + 18446744073709551608;

   [local count: 1073741824]:
  # SR.16_41 = PHI <_26(3), _23(2)>
  # _16 = PHI <__n_25(3), __n_24(2)>
  _42 = (unsigned int) _16;
  _12 = 1 << _42;
  _13 = *SR.16_41;
  _14 = _12 & _13;
  _15 = _14 != 0;
  return _15;

} 

This is a regression since gcc 7 which produces more reasonable code:
f(std::vector > const&, unsigned long):
movq(%rdi), %rdx
movq%rsi, %rcx
movq%rsi, %rax
movl$1, %esi
shrq$6, %rcx
shlx%rax, %rsi, %rsi
andq(%rdx,%rcx,8), %rsi
setne   %al
ret

clang:
f(std::vector> const&, unsigned long):
leaq63(%rsi), %rax
testq   %rsi, %rsi
cmovnsq %rsi, %rax
sarq$6, %rax
shlq$3, %rax
addq(%rdi), %rax
movabsq $-9223372036854775808, %rcx
leaq63(%rcx), %rdx
andq%rsi, %rdx
xorl%edi, %edi
cmpq%rcx, %rdx
setbe   %dil
movq-8(%rax,%rdi,8), %rax
btq %rsi, %rax
setb%al
retq

clang with libc++

f(std::__1::vector> const&, unsigned long):
movq(%rdi), %rax
movq%rsi, %rcx
shrq$6, %rcx
movq(%rax,%rcx,8), %rax
btq %rsi, %rax
setb%al
retq

[Bug go/118152] libgo sync/atomic fails since g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm

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

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

--- Comment #1 from Christophe Lyon  ---
libgo.log says:
unexpected fault address 0x1e08e
fatal error: fault
[signal SIGBUS: bus error code=0x1 addr=0x1e08e pc=0x0]

goroutine 215 [running]:
runtime.dopanic__m
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/runtime/panic.go:1198
runtime.fatalthrow
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/runtime/panic.go:1067
runtime.throw
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/runtime/panic.go:1038
runtime.sigpanic
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/runtime/signal_unix.go:672
sync/atomic_test.TestNilDeref..func30
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~libgo-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest2297627/test/atomic_test.go:1464
sync_1atomic__test.TestNilDeref
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~libgo-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest2297627/test/atomic_test.go:1464
testing.tRunner
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1229
runtime.kickoff
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/runtime/proc.go:1234
created by testing.T.Run
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1274
+0x1bc

goroutine 1 [chan receive]:
testing.T.Run
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1275
testing.runTests..func1
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1547
testing.tRunner
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1229
testing.runTests
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1545
testing.M.Run
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/../mybuild/snapshots//gcc.git~libgo/libgo/go/testing/testing.go:1453
main.main
   
/home/christophe.lyon/src/Linaro/abe/mybuild-host-armhf/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~libgo-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest2297627/test/_testmain.go:61
FAIL: sync/atomic

[Bug rtl-optimization/118153] New: Wrong code generated due to selective scheduler on RISC-V target

[luiss at synopsys dot com via Gcc-bugs]

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

Bug ID: 118153
   Summary: Wrong code generated due to selective scheduler on
RISC-V target
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luiss at synopsys dot com
  Target Milestone: ---

Created attachment 59936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59936&action=edit
Test case

In the attached test case, there is incorrect code generation with a specific
set of options. It seems that the main issue is related to the selective
scheduler. The late-combine pass must be disabled to trigger the issue.

Execution command:
```
$ /home/luis/inst/bin/riscv64-unknown-elf-gcc \
-fharden-control-flow-redundancy -fselective-scheduling \
-fno-late-combine-instructions \
-mabi=ilp32 -march=rv32i_zicsr -mcmodel=medany \
-O3 test.i
$ /home/luis/inst/bin/qemu-riscv32 -r 5.10 a.out
checksum = 965B2E87
```

The expected output is `checksum = 18D42964`. Any modifications to the source
code or optimization options that affect the code flow, such as using -O2, will
trigger the expected result.


I'm using a GCC cross-compiler for RISC-V Baremetal Multilib (running on x64
Linux) - gcc version 12.2.0
GCC Trunk was used in this experiment. The output of "riscv64-unknown-elf-gcc
-v" is:
-
Using built-in specs.
COLLECT_GCC=/home/luis/inst/bin/riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/home/luis/inst/libexec/gcc/riscv64-unknown-elf/15.0.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: /home/luis/src/gcc-trunk/configure
--target=riscv64-unknown-elf --prefix=/home/luis/inst --disable-shared
--disable-threads --enable-languages=c,c++ --with-pkgversion=g2d8982c27
--with-system-zlib --enable-tls --with-newlib
--with-sysroot=/home/luis/inst/riscv64-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=/home/luis/src/gcc-trunk --enable-multilib
--with-abi=lp64d --with-arch=rv64gc --with-tune=rocket --with-isa-spec=20191213
'CFLAGS_FOR_TARGET=-Os-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os   
-mcmodel=medlow'
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241220 (experimental) (g2d8982c27)
-

[Bug rtl-optimization/118067] [15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1860 (unable to find a register to spill) {*lshrhi3_1} with -O -fno-split-wide-types -mavx512f

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:219ddae16f9d724baeff86934f8981aa5ef7b95f

commit r15-6394-g219ddae16f9d724baeff86934f8981aa5ef7b95f
Author: Uros Bizjak 
Date:   Fri Dec 20 16:16:15 2024 +0100

i386: Disable SImode/DImode moves from/to mask regs without avx512bw
[PR118067]

SImode and DImode moves from/to mask registers are valid only with
AVX512BW,
so mark relevant alternatives in *movsi_internal and *movdi_internal as
such.

Even with the patch, the testcase still fails, but now with:

pr118067.c: In function âfooâ:
pr118067.c:13:1: internal compiler error: maximum number of generated
reload insns per insn achieved (90)
   13 | }
  | ^
0x2c3b581 internal_error(char const*, ...)
../../git/gcc/gcc/diagnostic-global-context.cc:517
0xb68938 lra_constraints(bool)
../../git/gcc/gcc/lra-constraints.cc:5411
0xb51a0d lra(_IO_FILE*, int)
../../git/gcc/gcc/lra.cc:2449
0xaf9f4d do_reload
../../git/gcc/gcc/ira.cc:5977
0xafa462 execute
../../git/gcc/gcc/ira.cc:6165

PR target/118067

gcc/ChangeLog:

* config/i386/i386.md (*movdi_internal):
Disable alternatives from/to mask registers without AVX512BW.
(*movsi_internal): Ditto.

[Bug middle-end/118157] New: [OpenMP] Variant function - build failed due to auto-tagged as 'declare target' but uncalled + not callable

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

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

Bug ID: 118157
   Summary: [OpenMP] Variant function - build failed due to
auto-tagged as 'declare target' but uncalled + not
callable
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openmp, rejects-valid
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
  Target Milestone: ---

The following code is rejected with:

var.c:1:5: error: variable 'x' has been referenced in offloaded code but hasn't
been marked to be included in the offbut uncalledloaded code
1 | int x = 123;
  | ^
lto1: fatal error: errors during merging of translation units


The problem is that 'f' is has:
  __attribute__((omp declare target, omp declare variant variant))

However, the condition   device={isa("avx512f")}  can never be true for
devices, but it still gets the 'declare target' attribute.

Note that during gimplify, it is already resolved to:

#pragma omp target num_teams(-2) thread_limit(0) map(from:y [len: 4])
  {
int y.0;

y.0 = h ();
y = y.0;
  }

Thus, there is no need for 'f' getting the 'declare target'.
***

int x = 123;

int f() {
  return (int) x;
}

int h() {
  return 12;
}

#pragma omp declare variant(f) match(device={isa("avx512f")})
#pragma omp declare variant (h) match (user={condition(score(20): 1)})

int foo() {
 return 3;
}

int main()
{
  int y;
  #pragma omp target map(from: y)
y = foo();
  __builtin_printf("y = %d\n", y);
}

[Bug target/118150] Failure to fold NOT+PTEST to NOTS for SVE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2024-12-20

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

[Bug middle-end/113506] ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -Os -fno-tree-coalesce-vars -finline-stringops

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r15-6398-ge7108c34a3685eaf9edd3b1fefbd3645b9bd8def
Author: Alexandre Oliva 
Date:   Fri Dec 20 18:01:53 2024 -0300

avoid trying to set block in barriers [PR113506]

When we emit a sequence before a preexisting insn and naming a BB to
store in the insns, we will attempt to store the BB even in barriers
present in the sequence.

Barriers don't expect blocks, and rtl checking catches the problem.

When emitting after a preexisting insn, we skip the block setting in
barriers.  Change the before emitter to do so as well.


for  gcc/ChangeLog

PR middle-end/113506
* emit-rtl.cc (add_insn_before): Don't set the block of a
barrier.

for  gcc/testsuite/ChangeLog

PR middle-end/113506
* gcc.target/riscv/pr113506.c: New.

[Bug middle-end/118007] ICE when building ruby-3.2.5 with -fstrub=all

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:09dd47bc383f30f1ba03ec80f8bd849eb6283d29

commit r15-6399-g09dd47bc383f30f1ba03ec80f8bd849eb6283d29
Author: Alexandre Oliva 
Date:   Fri Dec 20 18:02:01 2024 -0300

strub: accept indirection of volatile pointer types [PR118007]

We don't want to indirect pointers in strub wrappers, because it
generally isn't profitable, but if the argument is volatile, then we
must use indirection to preserve access patterns, so amend the
assertion check.


for  gcc/ChangeLog

PR middle-end/118007
* ipa-strub.cc (pass_ipa_strub::execute): Accept indirecting
volatile args of pointer types.

for  gcc/testsuite/ChangeLog

PR middle-end/118007
* gcc.dg/strub-pr118007.c: New.

[Bug fortran/89632] documentation bug

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:53ddfbaede0db07843529f41b50133a815a1d90a

commit r15-6400-g53ddfbaede0db07843529f41b50133a815a1d90a
Author: Sandra Loosemore 
Date:   Thu Dec 19 00:43:11 2024 +

Fortran: Clean up -funderscoring and -fsecond-underscore docs [PR51820]

This is a long-standing documentation bug in the Fortran manual,
initially reported in 2012 as PR51820, with a quick fix applied later
for PR109216.  The patch here incorporates more of the discussion from
the original issue.

gcc/fortran/ChangeLog
PR fortran/51820
PR fortran/89632
PR fortran/109216
* invoke.texi (Code Gen Options): Further cleanups of the
discussion
of what -funderscoring and -fsecond-underscore do.

[Bug fortran/109216] Wrong behaviour explained in -fno-underscoring documentation

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:53ddfbaede0db07843529f41b50133a815a1d90a

commit r15-6400-g53ddfbaede0db07843529f41b50133a815a1d90a
Author: Sandra Loosemore 
Date:   Thu Dec 19 00:43:11 2024 +

Fortran: Clean up -funderscoring and -fsecond-underscore docs [PR51820]

This is a long-standing documentation bug in the Fortran manual,
initially reported in 2012 as PR51820, with a quick fix applied later
for PR109216.  The patch here incorporates more of the discussion from
the original issue.

gcc/fortran/ChangeLog
PR fortran/51820
PR fortran/89632
PR fortran/109216
* invoke.texi (Code Gen Options): Further cleanups of the
discussion
of what -funderscoring and -fsecond-underscore do.

[Bug fortran/51820] [doc] underscoring documentation incorrect

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:53ddfbaede0db07843529f41b50133a815a1d90a

commit r15-6400-g53ddfbaede0db07843529f41b50133a815a1d90a
Author: Sandra Loosemore 
Date:   Thu Dec 19 00:43:11 2024 +

Fortran: Clean up -funderscoring and -fsecond-underscore docs [PR51820]

This is a long-standing documentation bug in the Fortran manual,
initially reported in 2012 as PR51820, with a quick fix applied later
for PR109216.  The patch here incorporates more of the discussion from
the original issue.

gcc/fortran/ChangeLog
PR fortran/51820
PR fortran/89632
PR fortran/109216
* invoke.texi (Code Gen Options): Further cleanups of the
discussion
of what -funderscoring and -fsecond-underscore do.

[Bug c++/118155] Extend -Wtautological-compare for pointer addition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-12-20

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

[Bug fortran/113928] Aliasing of pointer in expression

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-15.

Thanks for the report!

[Bug c++/118155] Extend -Wtautological-compare for pointer addition

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Confirmed. Note there used to be an overflow warning for this at one point.

[Bug fortran/118120] Wrong aliasing assumptions for Fortran POINTERs

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-15.

Thanks for the report!

[Bug target/118151] Relax the SVE PTEST matching conditions for any/none (ne/eq)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-12-20

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

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop) since r15-5563

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

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

--- Comment #10 from Sam James  ---
Thank you!

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

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #26 from Sam James  ---
Reduced:
```
int a, b, c, *d = &a;
long e;
static long(am)(long f, int g) { return g == 0 || f == 1 && g == 1 ?: f / g; }
static void aq(unsigned f) {
  c ^= e = am(~f, 1);
  b = 7 - (e >= 1) - 33;
  *d = b;
}
int main() {
  am(1, 1);
  aq(1);
  if (a == 0xffe5)
;
  else
__builtin_abort();
}
```

[Bug tree-optimization/118149] [15 regression] ICE when building lsp-plugins-1.2.14 (mmap: Cannot allocate memory in forwprop) since r15-5563

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

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

Christoph Müllner  changed:

   What|Removed |Added

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

--- Comment #9 from Christoph Müllner  ---
The new tests pushed on master:
  https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672123.html

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #27 from Andrew Pinski  ---
(In reply to Sam James from comment #26)
> Reduced:
> ```
> int a, b, c, *d = &a;
> long e;
> static long(am)(long f, int g) { return g == 0 || f == 1 && g == 1 ?: f / g;
> }
> static void aq(unsigned f) {
>   c ^= e = am(~f, 1);
>   b = 7 - (e >= 1) - 33;
>   *d = b;
> }
> int main() {
>   am(1, 1);
>   aq(1);
>   if (a == 0xffe5)
> ;
>   else
> __builtin_abort();
> }
> ```

Yes it is the same as PR 118138, we have (long)(~1u) which is incorrectly sign
extending.  PR 118138 has a cleaner comment history so closing this one as a
dup of that.

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

[Bug ipa/118138] [15 Regression] wrong code at -O3 with "-fno-inline" on x86_64-linux-gnu since r15-6294-g96fb71883d438b

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

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

[Bug ipa/118148] [15 regression] Miscompilation at -Os since r15-6294-g96fb71883d438b

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same issue, a sign extend is being done instead of a zero extend for widdening.

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

[Bug ipa/118138] [15 Regression] wrong code at -O3 with "-fno-inline" on x86_64-linux-gnu since r15-6294-g96fb71883d438b

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||yunboni at smail dot nju.edu.cn

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

[Bug libstdc++/118158] New: std::filesystem::equivalent unsupported on socket files

[davidepesa at gmail dot com via Gcc-bugs]

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

Bug ID: 118158
   Summary: std::filesystem::equivalent unsupported on socket
files
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidepesa at gmail dot com
  Target Milestone: ---

Calling std::filesystem::equivalent() on two socket files throws:

std::filesystem::__cxx11::filesystem_error: filesystem error: cannot check file
equivalence: Operation not supported [/tmp/foo.sock] [foo.sock]

Is there a reason for this limitation?
Boost.Filesystem seems to work fine in this scenario, it just compares st_ino
and st_dev as suggested by [fs.op.equivalent].