[Bug c/119950] New: __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

[quentin at armitage dot org.uk via Gcc-bugs]

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

Bug ID: 119950
   Summary: __builtin_constant_p warning with
-Wdeprecated-non-prototype inconsistent
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: quentin at armitage dot org.uk
  Target Milestone: ---

The following code (in /tmp/wc.c) compiles without error:
#define __USE_EXTERN_INLINES
#include 

when compiled with gcc -Wdeprecated-non-prototypes -c -o /tmp/wc.{o,c}

However, if I copy /usr/include/wchar.h to /tmp and change /tmp/wc.c to be:
#define __USE_EXTERN_INLINES
#include 

compiling now gives the following errors:

In file included from /tmp/wc.c:2:
/tmp/wchar.h: In function ‘btowc’:
/tmp/wchar.h:344:11: warning: ISO C23 does not allow arguments for function
‘__builtin_constant_p’ declared without parameters [-Wdeprecated-non-prototype]
  344 | { return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f'
  |   ^~~~
/tmp/wchar.h: In function ‘wctob’:
/tmp/wchar.h:350:11: warning: ISO C23 does not allow arguments for function
‘__builtin_constant_p’ declared without parameters [-Wdeprecated-non-prototype]
  350 | { return (__builtin_constant_p (__wc) && __wc >= L'\0' && __wc <=
L'\x7f'
  |   ^~~~

The above in itself is clearly not the problem itself, but the problem comes
from including the glib2 headers (from
https://download.gnome.org/sources/glib/2.84/glib-2.84.1.tar.xz) which use
__builtin_constant_p.

Compiling:
#include 

with -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-Wdeprecated-non-prototype generates the following errors:

In file included from /usr/include/glib-2.0/glib/gstring.h:37,
 from /usr/include/glib-2.0/glib/giochannel.h:36,
 from /usr/include/glib-2.0/glib.h:56,
 from /usr/include/glib-2.0/gobject/gbinding.h:30,
 from /usr/include/glib-2.0/glib-object.h:24,
 from /usr/include/glib-2.0/gio/gioenums.h:30,
 from /usr/include/glib-2.0/gio/giotypes.h:30,
 from /usr/include/glib-2.0/gio/gio.h:28,
 from /tmp/gl.c:1:
/usr/include/glib-2.0/glib/gstrfuncs.h: In function ‘g_strdup_inline’:
/usr/include/glib-2.0/glib/gstrfuncs.h:311:7: warning: ISO C23 does not allow
arguments for function ‘__builtin_constant_p’ declared without parameters
[-Wdeprecated-non-prototype]
  311 |   if (__builtin_constant_p (!str) && !str)
  |   ^~~~
/usr/include/glib-2.0/glib/gstrfuncs.h:314:7: warning: ISO C23 does not allow
arguments for function ‘__builtin_constant_p’ declared without parameters
[-Wdeprecated-non-prototype]
  314 |   if (__builtin_constant_p (!!str) && !!str && __builtin_constant_p
(strlen (str)))
  |   ^~~~
/usr/include/glib-2.0/glib/gstrfuncs.h:314:48: warning: ISO C23 does not allow
arguments for function ‘__builtin_constant_p’ declared without parameters
[-Wdeprecated-non-prototype]
  314 |   if (__builtin_constant_p (!!str) && !!str && __builtin_constant_p
(strlen (str)))
  |^~~~
/usr/include/glib-2.0/glib/glib-autocleanups.h: In function
‘g_autoptr_cleanup_gstring_free’:
/usr/include/glib-2.0/glib/gstring.h:72:4: warning: ISO C23 does not allow
arguments for function ‘__builtin_constant_p’ declared without parameters
[-Wdeprecated-non-prototype]
   72 |   (__builtin_constant_p (free_segment) ?\
  |^~~~
/usr/include/glib-2.0/glib/glib-autocleanups.h:39:5: note: in expansion of
macro ‘g_string_free’
   39 | g_string_free (string, TRUE);

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #442 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #441)
> (In reply to John Paul Adrian Glaubitz from comment #440)
> > The branch for GCC 16 has opened now, so I assume it would be a good time to
> > rebase the patches so I can re-test them.
> 
> I just tried rebasing devel/sh-lra and at least the rebase works without
> problems.
> 
> Will run the various tests now over the next days in the hope to get this
> going again.

Full bootstrap works fine. Tested with all languages except Go, Rust, Cobol and
D.

[Bug target/118280] [14/15/16 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[eager at eagercon dot com via Gcc-bugs]

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

--- Comment #17 from Michael Eager  ---
The reproducer script builds gcc-13, not v14 or v15.  

There have been no changes to microblaze support in gcc-15.

[Bug analyzer/119952] New: -Wanalyzer-malloc-leak false positive with [[gnu::malloc(destructor)]]

[dories.spirits_0p at icloud dot com via Gcc-bugs]

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

Bug ID: 119952
   Summary: -Wanalyzer-malloc-leak false positive with
[[gnu::malloc(destructor)]]
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dories.spirits_0p at icloud dot com
  Target Milestone: ---

This code:

#include 

void my_free(void *);

[[gnu::malloc, gnu::malloc(my_free)]] void * my_malloc(size_t) { return (void
*)3233; } // can be whatever value


void f() {
my_free(my_malloc(1));
}

Results in a malloc leak warning:

: In function 'my_malloc':
:5:73: warning: leak of 'my_malloc(1)' [CWE-401]
[-Wanalyzer-malloc-leak]
5 | [[...]] void * my_malloc(size_t) { return (void *)3233; }
  |   ^
  'f': events 1-3
│
│8 | void f() {
│  |  ^
│  |  |
│  |  (1) entry to 'f'
│9 | my_free(my_malloc(1));
│  | ~
│  | |
│  | (2) allocated here
│  | (3) calling 'my_malloc' from 'f'
│
└──> 'my_malloc': events 4-5
   │
   │5 | [[...]] void * my_malloc(size_t) { return (void *)3233; }
   │  |^  ~
   │  ||  |
   │  |(4) entry to 'my_malloc'   (5) ⚠️ 
'my_malloc(1)' leaks here; was allocated at (2)

Seems to happen when compiled at -O0/1/g on GCC 11.1+
https://godbolt.org/z/bcbb37d9W

Doesn't happen if my_malloc returns NULL, unless LTO is enabled
https://godbolt.org/z/qzTsoz3Wb

[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

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

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

--- Comment #1 from Florian Weimer  ---
Patch posted:

[PATCH] c: Suppress -Wdeprecated-non-prototype warnings for builtins

[Bug middle-end/109267] generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 61200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61200&action=edit
Patch which will need testcases for

this patch should fix it. It replaces __builtin_unreachable to __builtin_trap
if it is the first non-debug statement and in the first (and only) bb.

[Bug middle-end/119951] Exception and std::stoi behaves abnormally in a rare occasion

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
The problem is the same as PR 109267. Can you try the patch in PR 109267 which
I just attached, it is against GCC 16 but this area in the file has not changed
since GCC 12 (r12-4616-g9262ae450d6a57).

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

[Bug middle-end/109267] generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||invisparent at outlook dot com

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

[Bug ipa/103734] IPA-CP opportunity for imagick in SPECCPU 2017

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

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

--- Comment #5 from Jan Hubicka  ---
This is MorphologyApply

MagickExport Image *MorphologyApply(const Image *image, const ChannelType
 channel,const MorphologyMethod method, const ssize_t iterations,
 const KernelInfo *kernel, const CompositeOperator compose,
 const double bias, ExceptionInfo *exception)

 - considering value 134217719 for param #1 const ChannelType (caller_count: 3)
 - considering value 1 for param #2 const MorphologyMethod (caller_count: 6)
 - considering value 1 for param #3 const ssize_t (caller_count: 6)
 - considering value 0 for param #5 const CompositeOperator (caller_count: 6)
 - considering value 0.0 for param #6 const double (caller_count: 6) 

Sp we know ChannelType==134217719, method == 1 iterations==1 compose=0 and
bisas == 0.0

Summary is:
size:2.00, time:2.00
size:3.00, time:2.00,  executed if:(not inlined)
size:31.00, time:19.00,  executed if:(op3 != 0)
size:1.00, time:0.00,  executed if:(op3 < 0) && (op3 != 0) && (not
inlined)
size:2.00, time:0.00,  executed if:(op3 < 0) && (op3 != 0)
size:347.50, time:0.00,  executed if:(op2 == 7 || op2 == 21) &&
(op3 != 0)
size:1150.00, time:144587098112.00,  executed if:(op2 <= 11 || op2
== 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 < 15 || op2 >
21) && (op2 >= 8 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7
|| op2 < 15 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18
|| op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 >= 8 || op2 == 12 ||
op2 <= 17 || op2 == 18 || op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2
<= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 >
12 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 >=
19 || op2 < 7 || op2 > 12 || op2 > 21) && (op3 != 0)
size:1.00, time:1.00,  executed if:(op5 == 0) && (op2 <= 11 || op2
== 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 < 15 || op2 >
21) && (op2 >= 8 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7
|| op2 < 15 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18
|| op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 >= 8 || op2 == 12 ||
op2 <= 17 || op2 == 18 || op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2
<= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 >
12 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 >=
19 || op2 < 7 || op2 > 12 || op2 > 21) && (op3 != 0)
size:2.00, time:0.00,  executed if:(op2 == 2 || op2 == 9 || op2 <=
12 || op2 == 17) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <=
20 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 >= 8 || op2 == 12 || op2 <= 17
|| op2 == 18 || op2 <= 20 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 <= 11 ||
op2 == 12 || op2 <= 17 || op2 == 18 || op2 >= 19 || op2 < 7 || op2 < 15 || op2
> 21) && (op2 >= 8 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 >= 19 || op2 <
7 || op2 < 15 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18
|| op2 <= 20 || op2 < 7 || op2 > 12 || op2 > 21) && (op2 <= 11 || op2 == 12 ||
op2 <= 17 || op2 == 18 || op2 >= 19 || op2 < 7 || op2 > 12 || op2 > 21) && (op3
!= 0)
size:0.50, time:0.50,  executed if:(op2 <= 11 || op2 == 12 || op2
<= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 >=
8 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 < 15 ||
op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 >= 19 ||
op2 < 7 || op2 < 15 || op2 > 21) && (op2 >= 8 || op2 == 12 || op2 <= 17 || op2
== 18 || op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 <= 11 || op2 ==
12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 > 12 || op2 > 21)
&& (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 >= 19 || op2 < 7 ||
op2 > 12 || op2 > 21) && (op3 != 0) && (not inlined)
size:8.00, time:0.00,  executed if:(op2 == 12) && (op3 != 0)
size:2.00, time:0.00,  executed if:(op2 == 10) && (op2 <= 11 || op2
== 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 < 15 || op2 >
21) && (op2 >= 8 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7
|| op2 < 15 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18
|| op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2 >= 8 || op2 == 12 ||
op2 <= 17 || op2 == 18 || op2 >= 19 || op2 < 7 || op2 < 15 || op2 > 21) && (op2
<= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 >
12 || op2 > 21) && (op2 <= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 >=
19 || op2 < 7 || op2 > 12 || op2 > 21) && (op3 != 0)
size:2.00, time:0.00,  executed if:(op2 == 9 || op2 == 17) && (op2
<= 11 || op2 == 12 || op2 <= 17 || op2 == 18 || op2 <= 20 || op2 < 7 || op2 <
15 || op2 > 21) && (op2 >= 8 || op2 == 12 || op2 <= 17 || op2 == 18 

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

[stefan at bytereef dot org via Gcc-bugs]

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

--- Comment #8 from Stefan Krah  ---
As Richard wrote, C99 demands that an additional out-of-line copy of the
function is generated. Whether the non-standard __attribute__ ((always_inline))
should override C99 is of course another question.

For users the strictness of always_inline seems tricky. I'd welcome an
additional "really_inline" that ignores the heuristics but does not fail with a
compile error if inlining is not possible.

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

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

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

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

You are mistaken. Why not just try? https://godbolt.org/z/sEcxvMjG6

[Bug tree-optimization/119924] [16 Regression] ICE when building 531.deepsjeng_r during ipa-cp since r16-101-g132d01d96ea9d6

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-26

--- Comment #2 from Jan Hubicka  ---
The compile time crash is now solved. However deepsjeng with LTO is now 6-72%
bigger (with -fprofile-use even at -O2) 
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=293.381.4
and about 3% slower
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=958.387.0

[Bug c++/119953] New: Compiling libstdc++ on MSP430 fails

[marian.buschsieweke at posteo dot net via Gcc-bugs]

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

Bug ID: 119953
   Summary: Compiling libstdc++ on MSP430 fails
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marian.buschsieweke at posteo dot net
  Target Milestone: ---

Compiling g++ for msp430-elf using:

$ ./configure \
--target=msp430-elf \
--prefix=/usr \
--with-sysroot=/usr/$target \
--with-native-system-header-dir=/include \
--with-headers=/usr/$target/include \
--with-python-dir=share/gcc-msp430-elf \
--libexecdir=/usr/lib \
--enable-languages=c++ \
--enable-lto \
--enable-plugins \
--enable-gnu-indirect-function \
--disable-decimal-float \
--disable-libffi \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-nls \
--disable-shared \
--disable-threads \
--disable-werror \
--with-gmp \
--with-gnu-as \
--with-gnu-ld \
--with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' \
--with-isl \
--with-libelf \
--with-mpc \
--with-mpfr \
--with-newlib \
--with-system-zlib

fails while building libstdc++ with:

/home/maribu/Repos/software/aports/master/community/g++-cross-embedded/src/gcc-15.1.0/libstdc++-v3/src/c++17/fs_path.cc:
In function 'std::size_t std::filesystem::__cxx11::hash_value(const path&)':
   
/home/maribu/Repos/software/aports/master/community/g++-cross-embedded/src/gcc-15.1.0/libstdc++-v3/src/c++17/fs_path.cc:1995:1:
error: insn does not satisfy its constraints:
 1995 | }
  | ^
(insn 38 85 86 3 (set (reg:SI 14 R14)
(plus:SI (reg:SI 14 R14)
(reg:SI 13 R13 [orig:51 _6 ] [51])))
"/home/maribu/Repos/software/aports/master/community/g++-cross-embedded/src/gcc-15.1.0/libstdc++-v3/src/c++17/fs_path.cc":1992:14
22 {addsi3}
 (nil))
during RTL pass: postreload
   
/home/maribu/Repos/software/aports/master/community/g++-cross-embedded/src/gcc-15.1.0/libstdc++-v3/src/c++17/fs_path.cc:1995:1:
internal compiler error: in extract_constrain_insn, at recog.cc:2783
0x7f0420f33495 libc_start_main_stage2
src/env/__libc_start_main.c:95
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccEoppeo.out file, please attach
this to your bugreport.

The preprocessed file is added as attachment.

[Bug ipa/119955] New: ipa-locality-cloning.cc has poor test coverage

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

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

Bug ID: 119955
   Summary: ipa-locality-cloning.cc has poor test coverage
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

only 1.6% coverage in a standard x86-64 test suite run for
ipa-locality-cloning.cc according to
https://gcc.opensuse.org/gcc-lcov/gcc/index.html

[Bug lto/119956] New: lockfile / lto-ltrans-cache have poor testing coverage

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

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

Bug ID: 119956
   Summary: lockfile / lto-ltrans-cache have poor testing coverage
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

lockfile.cc has 0% and lto-ltrans-cache.cc only 4.3% coverage for a x86-64
standard test suite run according to
https://gcc.opensuse.org/gcc-lcov/gcc/index.html

[Bug c++/119957] New: vtable-verify.cc has poor test coverage

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

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

Bug ID: 119957
   Summary: vtable-verify.cc has poor test coverage
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

Only 54% coverage with quite some code paths missing according to
https://gcc.opensuse.org/gcc-lcov/gcc/index.html

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

chenglulu  changed:

   What|Removed |Added

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

--- Comment #6 from chenglulu  ---
# gcc/cc1 -quiet  test.c -O2  -std=gnu11 -o test.s
-Wno-incompatible-pointer-types -fno-jump-tables
-fno-asynchronous-unwind-tables

The problem of bug 116600 can be circumvented by using option
'-fno-asynchronous-unwind-tables'.

>From the flow graph comparison, we can find that in the ree pass, bb12->bb13 is
100%, but in pro_and_epilogue it is 50%

[Bug c/48274] C frontend emit invalid promotions (TARGET_PROMOTE_PROTOTYPES )

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-170-ga670ebde3995481225ec62b29686ec07a21e5c10
Author: H.J. Lu 
Date:   Thu Nov 21 07:54:35 2024 +0800

Drop targetm.promote_prototypes from C, C++ and Ada frontends

Remove the targetm.calls.promote_prototypes call from C, C++ and Ada
frontends.

gcc/

PR c/48274
PR middle-end/112877
PR middle-end/118288
* gimple.cc (gimple_builtin_call_types_compatible_p): Remove the
targetm.calls.promote_prototypes call.
* tree.cc (tree_builtin_call_types_compatible_p): Likewise.

gcc/ada/

PR middle-end/112877
* gcc-interface/utils.cc (create_param_decl): Remove the
targetm.calls.promote_prototypes call.

gcc/c/

PR c/48274
PR middle-end/112877
PR middle-end/118288
* c-decl.cc (start_decl): Remove the
targetm.calls.promote_prototypes call.
(store_parm_decls_oldstyle): Likewise.
(finish_function): Likewise.
* c-typeck.cc (convert_argument): Likewise.
(c_safe_arg_type_equiv_p): Likewise.

gcc/cp/

PR middle-end/112877
* call.cc (type_passed_as): Remove the
targetm.calls.promote_prototypes call.
(convert_for_arg_passing): Likewise.
* typeck.cc (cxx_safe_arg_type_equiv_p): Likewise.

Signed-off-by: H.J. Lu 

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-172-gf9f81d5017adc5d860b24f67aeb89b4e79c7ebdb
Author: H.J. Lu 
Date:   Sun Nov 10 16:41:10 2024 +0800

vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86

Since the C frontend no longer promotes char and short arguments, expect
in-branch clones for x86.

PR middle-end/112877
* gcc.dg/vect/vect-simd-clone-16c.c: Expect in-branch clones for
x86.
* gcc.dg/vect/vect-simd-clone-16d.c: Likewise.
* gcc.dg/vect/vect-simd-clone-17c.c: Likewise.
* gcc.dg/vect/vect-simd-clone-17d.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18c.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18d.c: Likewise.

Signed-off-by: H.J. Lu 

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:78db4753c9646a372512e6a951fced12f74de0bc

commit r16-169-g78db4753c9646a372512e6a951fced12f74de0bc
Author: H.J. Lu 
Date:   Thu Nov 21 08:11:06 2024 +0800

Honor TARGET_PROMOTE_PROTOTYPES during RTL expand

Promote integer arguments smaller than int if TARGET_PROMOTE_PROTOTYPES
returns true.

gcc/

PR middle-end/112877
* calls.cc (initialize_argument_information): Promote small integer
arguments if TARGET_PROMOTE_PROTOTYPES returns true.

gcc/testsuite/

PR middle-end/112877
* gfortran.dg/pr112877-1.f90: New test.

Signed-off-by: H.J. Lu 

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Which makes me think this is a dup of bug 116600.

[Bug middle-end/118288] Using new crc builtins on i386 leads to ICE

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-170-ga670ebde3995481225ec62b29686ec07a21e5c10
Author: H.J. Lu 
Date:   Thu Nov 21 07:54:35 2024 +0800

Drop targetm.promote_prototypes from C, C++ and Ada frontends

Remove the targetm.calls.promote_prototypes call from C, C++ and Ada
frontends.

gcc/

PR c/48274
PR middle-end/112877
PR middle-end/118288
* gimple.cc (gimple_builtin_call_types_compatible_p): Remove the
targetm.calls.promote_prototypes call.
* tree.cc (tree_builtin_call_types_compatible_p): Likewise.

gcc/ada/

PR middle-end/112877
* gcc-interface/utils.cc (create_param_decl): Remove the
targetm.calls.promote_prototypes call.

gcc/c/

PR c/48274
PR middle-end/112877
PR middle-end/118288
* c-decl.cc (start_decl): Remove the
targetm.calls.promote_prototypes call.
(store_parm_decls_oldstyle): Likewise.
(finish_function): Likewise.
* c-typeck.cc (convert_argument): Likewise.
(c_safe_arg_type_equiv_p): Likewise.

gcc/cp/

PR middle-end/112877
* call.cc (type_passed_as): Remove the
targetm.calls.promote_prototypes call.
(convert_for_arg_passing): Likewise.
* typeck.cc (cxx_safe_arg_type_equiv_p): Likewise.

Signed-off-by: H.J. Lu 

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-173-gde8648def762e3b54200dd3cd5c6fb480b228579
Author: H.J. Lu 
Date:   Sun Nov 10 16:50:46 2024 +0800

scev-cast.c: Enable for all targets and adjust scan matches

Since the C frontend no longer promotes char argument, enable scev-cast.c
for all targets and adjust scan matches.

PR middle-end/112877
* gcc.dg/tree-ssa/scev-cast.c: Enable for all targets and adjust
scan match.

Signed-off-by: H.J. Lu 

[Bug tree-optimization/119960] [15/16 Regression] vectorizer seems not to do as much any more

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64
   Target Milestone|--- |15.2
Summary|Regression of code  |[15/16 Regression]
   |generation  |vectorizer seems not to do
   ||as much any more
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116352

[Bug rtl-optimization/119961] New: Control flow errors caused by shrink wrap optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 119961
   Summary: Control flow errors caused by shrink wrap optimization
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
  Target Milestone: ---

Created attachment 61210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61210&action=edit
testsuite

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-174-gf962f594e9006651379dafc9ef039be9654e6291
Author: H.J. Lu 
Date:   Sun Nov 10 17:55:20 2024 +0800

ssa-fre-4.c: Enable for all targets and adjust scan match

Since the C frontend no longer promotes char argument, enable ssa-fre-4.c
for all targets and adjust scan match.

PR middle-end/112877
* gcc.dg/tree-ssa/ssa-fre-4.c: Enable for all targets and adjust
scan match.

Signed-off-by: H.J. Lu 

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #2 from chenglulu  ---
Created attachment 61212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61212&action=edit
test-pro_and_epilogue.png

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to chenglulu from comment #6)
> # gcc/cc1 -quiet  test.c -O2  -std=gnu11 -o test.s
> -Wno-incompatible-pointer-types -fno-jump-tables
> -fno-asynchronous-unwind-tables
> 
> The problem of bug 116600 can be circumvented by using option
> '-fno-asynchronous-unwind-tables'.


Except that just hides the ICE and not the wrong code happening.

> 
> From the flow graph comparison, we can find that in the ree pass, bb12->bb13
> is 100%, but in pro_and_epilogue it is 50%

[Bug rtl-optimization/116600] [12/13/14/15/16 Regression] shrink wrapping vs asm goto, ICE: in maybe_record_trace_start, at dwarf2cfi.cc:2584 since r7-5127-g827ab47ab1f

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

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

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

[Bug rtl-optimization/116600] [12/13/14/15/16 Regression] shrink wrapping vs asm goto, ICE: in maybe_record_trace_start, at dwarf2cfi.cc:2584 since r7-5127-g827ab47ab1f

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #9 from chenglulu  ---
I found that there are two edges, 6->13 and 12->13, as shown in
https://gcc.gnu.org/bugzilla/attachment.cgi?id=61211. When shrink-wrap
optimizes 6->13, it finds that bb12 fall-through bb13. So it needs to split
12->13 first. There is an error in the split process.
I tried to modify this part of the code and it solved the problem, but I'm not
sure if the logic is correct.
```
diff --git a/gcc/cfgrtl.cc b/gcc/cfgrtl.cc
index d206c0d53a7..57bb4699c6a 100644
--- a/gcc/cfgrtl.cc
+++ b/gcc/cfgrtl.cc
@@ -1593,6 +1593,7 @@ force_nonfallthru_and_redirect (edge e, basic_block
target, rtx jump_label)
}
 }

+  bool adjust_jump_target = false;
   /* If e->src ends with asm goto, see if any of the ASM_OPERANDS_LABELs
  don't point to the target or fallthru label.  */
   if (JUMP_P (BB_END (e->src))
@@ -1601,7 +1602,6 @@ force_nonfallthru_and_redirect (edge e, basic_block
target, rtx jump_label)
   && (note = extract_asm_operands (PATTERN (BB_END (e->src)
 {
   int i, n = ASM_OPERANDS_LABEL_LENGTH (note);
-  bool adjust_jump_target = false;

   for (i = 0; i < n; ++i)
{
@@ -1615,33 +1615,6 @@ force_nonfallthru_and_redirect (edge e, basic_block
target, rtx jump_label)
  if (XEXP (ASM_OPERANDS_LABEL (note, i), 0) == BB_HEAD (target))
asm_goto_edge = true;
}
-  if (adjust_jump_target)
-   {
- rtx_insn *insn = BB_END (e->src);
- rtx note;
- rtx_insn *old_label = BB_HEAD (e->dest);
- rtx_insn *new_label = BB_HEAD (target);
-
- if (JUMP_LABEL (insn) == old_label)
-   {
- JUMP_LABEL (insn) = new_label;
- note = find_reg_note (insn, REG_LABEL_TARGET, new_label);
- if (note)
-   remove_note (insn, note);
-   }
- else
-   {
- note = find_reg_note (insn, REG_LABEL_TARGET, old_label);
- if (note)
-   remove_note (insn, note);
- if (JUMP_LABEL (insn) != new_label
- && !find_reg_note (insn, REG_LABEL_TARGET, new_label))
-   add_reg_note (insn, REG_LABEL_TARGET, new_label);
-   }
- while ((note = find_reg_note (insn, REG_LABEL_OPERAND, old_label))
-!= NULL_RTX)
-   XEXP (note, 0) = new_label;
-   }
 }

   if (EDGE_COUNT (e->src->succs) >= 2 || abnormal_edge_flags || asm_goto_edge)
@@ -1692,6 +1665,42 @@ force_nonfallthru_and_redirect (edge e, basic_block
target, rtx jump_label)
}

   new_bb = jump_block;
+
+  if (adjust_jump_target)
+   {
+ rtx_insn *insn = BB_END (new_edge->src);
+ rtx note;
+ rtx_insn *old_label = BB_HEAD (e->dest);
+ rtx_insn *new_label = BB_HEAD (jump_block);
+
+ if (JUMP_LABEL (insn) == old_label)
+   {
+ rtx tmp = extract_asm_operands (PATTERN (insn));
+ rtx_code_label *new_label = block_label (new_edge->dest);
+ rtx old_ref = ASM_OPERANDS_LABEL (tmp, 0);
+ gcc_assert (GET_CODE(old_ref) == LABEL_REF);
+ ASM_OPERANDS_LABEL (tmp, 0) = gen_rtx_LABEL_REF (Pmode,
new_label);
+ JUMP_LABEL (insn) = new_label;
+ --LABEL_NUSES (old_label);
+ ++LABEL_NUSES (new_label);
+ note = find_reg_note (insn, REG_LABEL_TARGET, old_label);
+ if (note)
+   remove_note (insn, note);
+
+   }
+ else
+   {
+ note = find_reg_note (insn, REG_LABEL_TARGET, old_label);
+ if (note)
+   remove_note (insn, note);
+ if (JUMP_LABEL (insn) != new_label
+ && !find_reg_note (insn, REG_LABEL_TARGET, new_label))
+   add_reg_note (insn, REG_LABEL_TARGET, new_label);
+   }
+ while ((note = find_reg_note (insn, REG_LABEL_OPERAND, old_label))
+!= NULL_RTX)
+   XEXP (note, 0) = new_label;
+   }
 }
   else
 jump_block = e->src;

```

[Bug tree-optimization/117385] Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||48

--- Comment #4 from Andrew Pinski  ---
So when I did this change, I ran into PR 48's f3


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48
[Bug 48] Missing boolean optimizations due to comparisons

[Bug tree-optimization/117385] Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 61213 [details]
> In progress patch

bool-checks-1.c is the testcase that fails.

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-170-ga670ebde3995481225ec62b29686ec07a21e5c10
Author: H.J. Lu 
Date:   Thu Nov 21 07:54:35 2024 +0800

Drop targetm.promote_prototypes from C, C++ and Ada frontends

Remove the targetm.calls.promote_prototypes call from C, C++ and Ada
frontends.

gcc/

PR c/48274
PR middle-end/112877
PR middle-end/118288
* gimple.cc (gimple_builtin_call_types_compatible_p): Remove the
targetm.calls.promote_prototypes call.
* tree.cc (tree_builtin_call_types_compatible_p): Likewise.

gcc/ada/

PR middle-end/112877
* gcc-interface/utils.cc (create_param_decl): Remove the
targetm.calls.promote_prototypes call.

gcc/c/

PR c/48274
PR middle-end/112877
PR middle-end/118288
* c-decl.cc (start_decl): Remove the
targetm.calls.promote_prototypes call.
(store_parm_decls_oldstyle): Likewise.
(finish_function): Likewise.
* c-typeck.cc (convert_argument): Likewise.
(c_safe_arg_type_equiv_p): Likewise.

gcc/cp/

PR middle-end/112877
* call.cc (type_passed_as): Remove the
targetm.calls.promote_prototypes call.
(convert_for_arg_passing): Likewise.
* typeck.cc (cxx_safe_arg_type_equiv_p): Likewise.

Signed-off-by: H.J. Lu 

[Bug tree-optimization/119960] [15/16 Regression] vectorizer seems not to do as much any more since r15-5863

[arseny.kapoulkine at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Kapoulkine  ---
Created attachment 61209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61209&action=edit
preprocessed source

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64

--- Comment #3 from Andrew Pinski  ---
With the following added to the begining of the testcase:
```
struct static_key;
struct i2c_adapter;
```
We get the following ICE for aarch64 on the trunk:
```
during RTL pass: dwarf2
dump file: /app/output.cpp.365r.dwarf2
: In function '__i2c_transfer':
:151:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.cc:2591
  151 | }
  | ^
```

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> No this is the same problem as PR 116600. Just the ICE shows up.

What is happening is shrink wrapping is moving the restore to the edge of the
basic block containing the asm goto.

That is we start with:
```
asm goto("":::"l1");
l1:
```

So there is only one edge from bbN to bbM.
But shrink wrapping adds the restore on the edge there and splits it but messes
up because now it is:
```
asm goto("":::"l1");
restore
l1:
```

But that is wrong.
The ICE in maybe_record_trace_start is trying to detect that the restores are
done correctly.

PR 116600 is exactly the same situtation as the above case.

[Bug tree-optimization/119960] [15/16 Regression] vectorizer seems not to do as much any more since r15-5863

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #10 from chenglulu  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > No this is the same problem as PR 116600. Just the ICE shows up.
> 
> What is happening is shrink wrapping is moving the restore to the edge of
> the basic block containing the asm goto.
> 
> That is we start with:
> ```
> asm goto("":::"l1");
> l1:
> ```
> 
> So there is only one edge from bbN to bbM.
> But shrink wrapping adds the restore on the edge there and splits it but
> messes up because now it is:
> ```
> asm goto("":::"l1");
> restore
> l1:
> ```
> 
> But that is wrong.
> The ICE in maybe_record_trace_start is trying to detect that the restores
> are done correctly.
> 
> PR 116600 is exactly the same situtation as the above case.

I agree, it's really the same issue

[Bug tree-optimization/117385] Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 61213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61213&action=edit
In progress patch

[Bug libstdc++/119962] New: : __maybe_present_t misses initialization

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 119962
   Summary: : __maybe_present_t misses initialization
   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: ---

It looks like libstdc++'s __maybe_present_t is always missing initialization,
which leads to failure to make some constexpr singular iterators:

https://godbolt.org/z/eaaE8xn6z

[Bug analyzer/116865] [14/15/16 Regression] ICE when compiling GNU coreutils numfmt with -fanalyzer since r14-9527-g1579394c9ecf3d

[bruno at clisp dot org via Gcc-bugs]

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

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #6 from Bruno Haible  ---
Reproduced with gcc 15.1.0.

[Bug sanitizer/119958] UBSAN: Replacing add with lea leads to false positive

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||wrong-code
   See Also||https://reviews.llvm.org/D1
   ||31716

--- Comment #1 from Sam James  ---
(In reply to Stefan Krah from comment #0)

> I can submit a somewhat chaotic test case that is difficult to make smaller
> and less chaotic

Please do. Thanks.

[Bug target/119958] UBSAN: Replacing add with lea leads to false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|MOVED   |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #4 from Andrew Pinski  ---
Oh wait this is not a linker issue but rather the odd definition of the linker
relaxation in the ABI.

[Bug target/119958] UBSAN: Replacing add with lea leads to false positive

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

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

--- Comment #5 from Jakub Jelinek  ---
This is in tls.pdf documented
0x00 movq %fs:0,%rax
0x09 addq x@gottpoff(%rip),%rax R_X86_64_GOTTPOFF x
⇓⇓⇓
0x00 movq %fs:0,%rax
0x09 leaq x@tpoff(%rax),%rax R_X86_64_TPOFF32 x
IE->LE relaxation, which is based on relocations, not on analyzing the code.
So, it is gcc's fault that it attempts to use flags set by the addq.

[Bug target/119958] UBSAN: Replacing add with lea leads to false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Got a reduced testcase:
```
extern __thread int f __attribute__((weak));
extern __thread int hh;
int h(int);
int h1(int*);
int g(void)
{
  h1(&hh);
  if (&f)
return (h1(&f));
  return 0;
}
```

[Bug target/119958] TLS relaxation does not allow addq with GOTTPOFF

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #8)
> Though, I guess testing address of __thread weak for non-NULL or NULL makes
> no sense.
> Address of it will be never NULL even when it is not defined.
> Which is because the instructions compute the thread segment base (which is
> pretty much always non-NULL) + whatever the relocation resolves to.

In fact LLVM starting in 16, removes the test of non-NULL .

[Bug target/119958] TLS relaxation does not allow addq with GOTTPOFF

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

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

--- Comment #8 from Jakub Jelinek  ---
Though, I guess testing address of __thread weak for non-NULL or NULL makes no
sense.
Address of it will be never NULL even when it is not defined.
Which is because the instructions compute the thread segment base (which is
pretty much always non-NULL) + whatever the relocation resolves to.

[Bug c++/119957] vtable-verify.cc has poor test coverage

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89423,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88818,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=118981,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70360,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85884

--- Comment #1 from Andrew Pinski  ---
--enable-vtable-verify will improve coverage but we know it is broken for some
cases already and maybe should be deprecated and/or removed ...

[Bug sanitizer/119958] UBSAN: Replacing add with lea leads to false positive

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> This is not a GCC bug but rather a binutils one, please report to it to them.
> 
> https://sourceware.org/bugzilla/
> 
> The linker/assembler is doing relaxation on the TLS and doing it
> incorrectly. Not realzing the flags register is needed.

s/TLS/gottpoff/ .

[Bug sanitizer/119958] New: UBSAN: Replacing add with lea leads to false positive

[stefan at bytereef dot org via Gcc-bugs]

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

Bug ID: 119958
   Summary: UBSAN: Replacing add with lea leads to false positive
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at bytereef dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Hi,

I can submit a somewhat chaotic test case that is difficult to make smaller
and less chaotic, but if my guess is correct, the issue might be resolved by
looking at assembly snippets and this issue:

https://reviews.llvm.org/D131716


My guess is that addq is replaced by leaq, which does not clear the zero flag,
leading to a jump to __ubsan_handle_type_mismatch_v1, which results in:

apitest.cc:17:43: runtime error: member call on null pointer of type 'struct
Context'

Using clang++ and UBSAN does not exhibit this issue.



The relevant generated assembly of the test case (-O3 -g -fsanitize=undefined
-S) is:

=
.LVL3256:
xorl%esi, %esi  ### sets the zero flag
movq%rbx, %rax
addqcontext@gottpoff(%rip), %rax  ### add is replaced by lea
movl%esi, -28(%rbp)
je  .L4844  ### jump uses the zero flag from xor
[snip]

.L4844: 
xorl%esi, %esi
movl$.Lubsan_data6185, %edi
call__ubsan_handle_type_mismatch_v1
=


When actually compiled with "-O3 -g -fsanitize=undefined", gdb shows that
lea is used:

=
(gdb) display/i $pc
=> 0x400b21 : xor%esi,%esi
=> 0x400b23 : mov%rbx,%rax
=> 0x400b26 : lea-0x10(%rax),%rax  ### <<== here
=> 0x400b2d : mov%esi,-0x1c(%rbp)
=> 0x400b30 : je 0x400cbe 
=> 0x400cbe : xor%esi,%esi
=> 0x400cc0 : mov$0x4176a0,%edi
=> 0x400cc5 : call   0x4005e0
<__ubsan_handle_type_mismatch_v1@plt>

(gdb) c
Continuing.
apitest.cc:17:43: runtime error: member call on null pointer of type 'struct
Context'
=

[Bug sanitizer/119958] UBSAN: Replacing add with lea leads to false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Andrew Pinski  ---
This is not a GCC bug but rather a binutils one, please report to it to them.

https://sourceware.org/bugzilla/

The linker/assembler is doing relaxation on the TLS and doing it incorrectly.
Not realzing the flags register is needed.

[Bug target/105275] [12/13/14/15/16 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

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

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

--- Comment #9 from Jan Hubicka  ---
The only vectorization difference is:

+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1911:18: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1898:17: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1966:30: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1966:30: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:2304:24: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1814:44: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1835:44: optimized: basic
block part vectorized using 16 byte vectors

magick/distort.c:1835:44: note: Cost model analysis for part in loop 0:
  Vector cost: 2004
  Scalar cost: 2152

changes to:

magick/distort.c:1835:44: note: Cost model analysis for part in loop 0:
  Vector cost: 2004
  Scalar cost: 1864

The costing differences are all of the form

-MAX_EXPR <_43, _1390> 1 times scalar_stmt costs 4 in body
-MAX_EXPR <_44, _1394> 1 times scalar_stmt costs 4 in body
+MAX_EXPR <_43, _1390> 1 times scalar_stmt costs 12 in body
+MAX_EXPR <_44, _1394> 1 times scalar_stmt costs 12 in body

which is wrong. Cost should be 4.

[Bug target/119958] TLS relaxation does not allow addq with GOTTPOFF

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||3.4.6

--- Comment #7 from Andrew Pinski  ---
```
Trying 13 -> 14:
   13: {r102:DI=r100:DI+[const(unspec[`f'] 7)];clobber flags:CC;}
  REG_EQUAL `f'
  REG_UNUSED flags:CC
  REG_DEAD r100:DI
   14: flags:CCZ=cmp(r102:DI,0)
Successfully matched this instruction:
(parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:DI (reg:DI 100)
(mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref/i:DI ("f") [flags 0x60] 
)
] UNSPEC_GOTNTPOFF)) [2  S8 A8]))
(const_int 0 [0])))
(set (reg/f:DI 102)
(plus:DI (reg:DI 100)
(mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref/i:DI ("f") [flags 0x60]  )
] UNSPEC_GOTNTPOFF)) [2  S8 A8])))
])
allowing combination of insns 13 and 14
original costs 9 + 4 = 13
replacement cost 9
deferring deletion of insn with uid = 13.
modifying insn i314: {flags:CCZ=cmp(r100:DI+[const(unspec[`f']
7)],0);r102:DI=r100:DI+[const(unspec[`f'] 7)];}
  REG_DEAD r100:DI
deferring rescan insn with uid = 14.
```

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

  Attachment #61203|0   |1
is obsolete||

--- Comment #7 from mcccs at gmx dot com ---
Created attachment 61204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61204&action=edit
preprocessed.cpp.xz

raw preprocessed file zipped again. replaced __float128 with _Float128,
replaced mac-only assert failure function with __builtin_abort() so it works on
my linux as well

[Bug ipa/103734] IPA-CP opportunity for imagick in SPECCPU 2017

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

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

--- Comment #4 from Jan Hubicka  ---
With -fprofile-use we get

Evaluating opportunities for MorphologyApply/3266.
 - considering value 134217719 for param #1 const ChannelType (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 427, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 1.11411e+06, size: 1493, count_sum: 2
(precise), overall time saved: 2228228 (adjusted), single_call) -> evaluation:
1268.58, threshold:
 not cloning: time saved is not hot
 - considering value 1 for param #2 const MorphologyMethod (caller_count: 6)
 good_cloning_opportunity_p (time: 1, size: 357, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 1, size: 357, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 - considering value 1 for param #3 const ssize_t (caller_count: 6)
 good_cloning_opportunity_p (time: 1, size: 424, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 1, size: 424, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 - considering value 0 for param #5 const CompositeOperator (caller_count: 6)
 good_cloning_opportunity_p (time: 1, size: 427, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 1, size: 427, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 - considering value 0.0 for param #6 const double (caller_count: 6) 
 good_cloning_opportunity_p (time: 1, size: 427, count_sum: 2 (precise),
overall time saved: 2 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 2, size: 1575, count_sum: 2 (precise),
overall time saved: 4 (adjusted), single_call) -> evaluation: 0.00, threshold:
500
 not cloning: time saved is not hot


So no cloning of MorphologyApply

For GetVirtualPixelsFromNexus
Evaluating opportunities for GetVirtualPixelsFromNexus/487.
 - considering value 1 for param #4 const size_t (caller_count: 14)
 good_cloning_opportunity_p (time: 1, size: 537, count_sum: 23739800
(precise), overall time saved: 23739800 (adjusted), scc) -> evaluation:
26524.92, threshold: 500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 2, size: 648, count_sum: 23739800
(precise), overall time saved: 47479600 (adjusted), scc) -> evaluation:
43962.59, threshold: 500
  Creating a specialized node of GetVirtualPixelsFromNexus/487.



 - considering value 1 for param #5 const size_t (caller_count: 12)
 good_cloning_opportunity_p (time: 1, size: 537, count_sum: 19110748
(adjusted), overall time saved: 19110748 (adjusted), scc) -> evaluation:
21352.79, threshold: 500
 not cloning: time saved is not hot
 good_cloning_opportunity_p (time: 2, size: 648, count_sum: 19110748
(adjusted), overall time saved: 38221496 (adjusted), scc) -> evaluation:
35390.27, threshold: 500
  Creating a specialized node of GetVirtualPixelsFromNexus/487.
replacing param #5 const size_t with const 1

So at least here the cloning now works.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #443 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #442)
> (In reply to John Paul Adrian Glaubitz from comment #441)
> > (In reply to John Paul Adrian Glaubitz from comment #440)
> > > The branch for GCC 16 has opened now, so I assume it would be a good time 
> > > to
> > > rebase the patches so I can re-test them.
> > 
> > I just tried rebasing devel/sh-lra and at least the rebase works without
> > problems.
> > 
> > Will run the various tests now over the next days in the hope to get this
> > going again.
> 
> Full bootstrap works fine. Tested with all languages except Go, Rust, Cobol
> and D.

Thanks for your efforts and reporting the results.  Although I'm not sure which
branch exactly you have used for this test...

As can be seen above, I've been trying to track LRA changes and there have been
several bug fixes and changes.  Therefore it would require re-visiting the SH
backend changes in order to figure out which changes are still relevant and
necessary and which aren't.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #444 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #443)
> Thanks for your efforts and reporting the results.  Although I'm not sure
> which branch exactly you have used for this test...

Sorry for the lack of clarification, I used devel/sh-lra from
https://gcc.gnu.org/git. I pulled the main repo, switched to devel/sh-lra,
created a new branch and rebased that one with master. Then performed native
test builds to verify that the bootstraps still work.

Looking at your Github account, I think the latest branch there contains many
additional patches, doesn't it?

> As can be seen above, I've been trying to track LRA changes and there have
> been several bug fixes and changes.  Therefore it would require re-visiting
> the SH backend changes in order to figure out which changes are still
> relevant and necessary and which aren't.

OK, no problem. I have not added any of the additional patches like 59432 or
59550 yet which were added to fix additional problems in WebKit2Gtk and ffmpeg.

Let me know which one to test.

[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #21 from mcccs at gmx dot com ---
Sorry again, there's a function of int type that didn't return anything but the
compiler didn't catch it so the reduction script allowed it. My last reduction
is also invalid.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #445 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #444)
> 
> Sorry for the lack of clarification, I used devel/sh-lra from
> https://gcc.gnu.org/git. I pulled the main repo, switched to devel/sh-lra,
> created a new branch and rebased that one with master. Then performed native
> test builds to verify that the bootstraps still work.
> 
> Looking at your Github account, I think the latest branch there contains
> many additional patches, doesn't it?

The gcc.gnu.org/git devel/sh-lra branch was a failed attempt and is stale.  Use
the one on github.

> 
> OK, no problem. I have not added any of the additional patches like 59432 or
> 59550 yet which were added to fix additional problems in WebKit2Gtk and
> ffmpeg.
> 
> Let me know which one to test.

I don't think there's anything meaningful to test at the moment.  Somebody
needs to go through the accumulated SH patches and the LRA changes, try to
understand the code and what is what.  At the moment I don't have time to dig
into it.

[Bug target/105275] [12/13/14/15/16 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-26

--- Comment #7 from Jan Hubicka  ---
I built with -march=native -Ofast -flto -fno-ipa-cp + PGO (without -flto the
problem does not reproduce).

imagick has bad train run and the hottest loop is not trained at all. Compared
to GCC15 the cold loop is now much slower:

  50.26%  imagick_r_peak.  imagick_r_peak.trunk-pgolto-Ofast-native-m64
 [.] MorphologyApply.cold
  15.85%  imagick_r_peak.  imagick_r_peak.gcc15-pgolto-Ofast-native-m64
 [.] MorphologyApply.cold
   9.93%  imagick_r_peak.  imagick_r_peak.gcc15-pgolto-Ofast-native-m64
 [.] MeanShiftImage
   9.24%  imagick_r_peak.  imagick_r_peak.trunk-pgolto-Ofast-native-m64
 [.] MeanShiftImage
   4.41%  imagick_r_peak.  imagick_r_peak.trunk-pgolto-Ofast-native-m64
 [.] GetVirtualPixelsFromNexus
   3.64%  imagick_r_peak.  imagick_r_peak.gcc15-pgolto-Ofast-native-m64
 [.] GetVirtualPixelsFromNexus
   1.51%  imagick_r_peak.  imagick_r_peak.gcc15-pgolto-Ofast-native-m64
 [.] MagickRound.lto_priv.1.lto_priv.0
   1.38%  imagick_r_peak.  imagick_r_peak.trunk-pgolto-Ofast-native-m64
 [.] MagickRound.lto_priv.1.lto_priv.0
   1.21%  imagick_r_peak.  imagick_r_peak.trunk-pgolto-Ofast-native-m64
 [.] GetOneCacheViewVirtualPixel
   1.18%  imagick_r_peak.  imagick_r_peak.gcc15-pgolto-Ofast-native-m64
 [.] GetOneCacheViewVirtualPixel

Codegen of the internal loop is same for both versions:

   0.00 │2afd:┌─ cmp  %rdx,%rcx▒
   0.00 │ │  jge  312f ▒
│ │result.red += (*k)*k_pixels[u].red; ▒
│ │  imul $0xfff8,%rcx,%r11▒
  17.91 │ │  vmovsd   (%rax,%r11,1),%xmm5  ▒
   0.00 │ │  movzwl   0x4(%rbx,%rcx,8),%r11d   ▒
   0.00 │ │  vcvtsi2sd%r11d,%xmm6,%xmm6▒
│ │result.green   += (*k)*k_pixels[u].green;   ▒
  22.46 │ │  movzwl   0x2(%rbx,%rcx,8),%r11d   ▒
│ │result.red += (*k)*k_pixels[u].red; ▒
   0.00 │ │  vfmadd231sd  %xmm6,%xmm5,%xmm4▒
│ │result.green   += (*k)*k_pixels[u].green;   ▒
   0.04 │ │  vcvtsi2sd%r11d,%xmm6,%xmm6▒
│ │result.blue+= (*k)*k_pixels[u].blue;▒
  17.09 │ │  movzwl   (%rbx,%rcx,8),%r11d  ▒
│ │result.green   += (*k)*k_pixels[u].green;   ▒
   0.00 │ │  vfmadd231sd  %xmm6,%xmm5,%xmm3▒
│ │result.blue+= (*k)*k_pixels[u].blue;▒
  12.99 │ │  vcvtsi2sd%r11d,%xmm6,%xmm6▒
│ │result.opacity += (*k)*k_pixels[u].opacity; ▒
   0.15 │ │  movzwl   0x6(%rbx,%rcx,8),%r11d   ▒
│ │result.blue+= (*k)*k_pixels[u].blue;▒
   0.00 │ │  vfmadd231sd  %xmm6,%xmm5,%xmm2▒
│ │result.opacity += (*k)*k_pixels[u].opacity; ▒
  19.48 │ │  vcvtsi2sd%r11d,%xmm6,%xmm6▒
   0.00 │ │  vfmadd231sd  %xmm6,%xmm5,%xmm1▒
│ │if ( image->colorspace == CMYKColorspace)   ▒
   9.61 │ │  cmp  $0xc,%esi◆
   0.00 │ │  je   317c ▒
│ │for (u=0; u < (ssize_t) kernel->width; u++, k--) {  ▒
│2b58:│  inc  %rcx ▒
   0.00 │ └──jmp  2afd ▒


   0.02 │2b34:┌─ cmp  %rdx,%rcx▒
   3.62 │ │  jge  3166 ▒
│ │result.red += (*k)*k_pixels[u].red; ▒
│ │  imul $0xfff8,%rcx,%r11▒
   0.19 │ │  vmovsd   (%rax,%r11,1),%xmm5  ▒
   8.36 │ │  movzwl   0x4(%rbx,%rcx,8),%r11d   ▒
   0.00 │ │  vcvtsi2sd%r11d,%xmm12,%xmm6   ▒
│ │result.green   += (*k)*k_pixels[u].green;   ▒
   7.13 │ │  movzwl   0x2(%rbx,%rcx,8),%r11d   ▒
│ │result.red += (*k)*k_pixels[u].red; ▒
  19.29 │ │  vfmadd231sd  %xmm6,%xmm5,%xmm4▒
│ │result.green   += (*k)*k_pixels[u].green;  

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #7 from Harald van Dijk  ---
(In reply to uecker from comment #6)
> The warning is about truncation of the final NUL
> character in the string literal. So I think the warning is correct. It does
> not warn about the result not being NUL-terminated, but about truncating a
> NUL from the initializer.

The warning is called -Wunterminated-string-initialization, but there is no
unterminated string. That is what this bug is about. If people want a warning
for truncated data, there should be a new warning for that, making
-Wunterminated-string-initialization do something other than what its name
clearly says it does is not the right way of handling that.

[Bug c++/119951] New: Exception and std::stoi behaves abnormally in a rare occasion

[invisparent at outlook dot com via Gcc-bugs]

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

Bug ID: 119951
   Summary: Exception and std::stoi behaves abnormally in a rare
occasion
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: invisparent at outlook dot com
  Target Milestone: ---

@code

#include 
#include 

int f() {
// We do nothing here,
// deliberately omit the return stmt.
// and note honestly we never invoke this function.
}

int main() {
try {
std::stoi("abc");
}
catch (...) {
std::cerr << "123" << std::endl;
}
return 0;
}

@endcode

Code above should always output "123" in cerr because "abc" can't be converted
to int. In MSVC, it does so in various optimization level, C++ standard.
But in gcc, things become interesting:
Fix -lstdc++=17. When I specify optimization level -O0, -O2 and -O3, it does
output "123". But with -O1, program crashed and exit with 541541187(dec).
Fix -lstdc++=23, it only outputs "123" with -O0, but exit with 541541187(dec)
with -O1, -O2 and -O3.
Feeling weird? But oh no there's something weirder:
Note that function, f(), that we never invoke? If we change its return type to
void, or let f returns something, or delete it completely, and then compile it,
program will output "123" in all flags(optimization level, C++ standard) I've
tested!
What's more, if I keep f() ill-formed, but substitute "123" with string literal
"I'm NOT an integer" (xD), all programs output "123".

I'm so... so confused... I know f() is ill-formed, but a function that is never
invoked can affect program's behavior! With those tests above, I have to doubt
that may be a bug...
I have to say this is the most strange bug I've ever met. Fixing it is far
beyond my skill. So, I'd like to say a big thanks to all volunteers &
contributors who maintains gcc. And apologize for the inconvenience if I
misreport this bug.

Extra info:
gcc(g++) version: 14.2.0 (in w64devkit-2.1.0)
System: Windows 11, OS build 26100.3775
CPU: AMD Ryzen 9 9950X3D

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #8 from Alejandro Colomar  ---
(In reply to Harald van Dijk from comment #7)
> (In reply to uecker from comment #6)
> > The warning is about truncation of the final NUL
> > character in the string literal. So I think the warning is correct. It does
> > not warn about the result not being NUL-terminated, but about truncating a
> > NUL from the initializer.
> 
> The warning is called -Wunterminated-string-initialization, but there is no
> unterminated string. That is what this bug is about. If people want a
> warning for truncated data, there should be a new warning for that, making
> -Wunterminated-string-initialization do something other than what its name
> clearly says it does is not the right way of handling that.

Not only there's no _unterminated string_; there's no _string_ at all.  That
string literal is not a string.



Quoting C23:

| 75)  A string literal may not be a string (see 7.1.1),
| because a null character can be embedded in it by a \0 escape sequence.


So, if you're using a non-string to initialize a string, you deserve a
diagnostic.  If you're being too clever about it, you should turn off the
diagnostic, IMO.  My recommendation, like Martin said, is that you remove that
extra \0 and rely on this diagnostic for making sure that there's a NUL
terminator.

[Bug c++/119951] Exception and std::stoi behaves abnormally in a rare occasion

[invisparent at outlook dot com via Gcc-bugs]

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

--- Comment #1 from Chenyi Wang  ---
Update:
"-fexceptions" is always passed to gcc.

[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

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

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

Florian Weimer  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||fw at gcc dot gnu.org
   Last reconfirmed||2025-04-26
   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #10 from Alejandro Colomar  ---
(In reply to Harald van Dijk from comment #9)
> If you want to make the argument that there is no unterminated string
> because there is no string in the first place, then the logical conclusion
> is still that  -Wunterminated-string-initialization should not warn about
> that.
> 
> If you want a warning for something other than unterminated strings, that
> should be a different warning, not -Wunterminated-string-initialization.

I don't oppose that.  I suggested that possibility in
.  However, I'm not
sure it's worth a separate diagnostic, considering that it's easier to just
rely on Wusi.  But if anyone feels like implementing that, I'm okay with it.

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #9 from Harald van Dijk  ---
(In reply to Alejandro Colomar from comment #8)
> (In reply to Harald van Dijk from comment #7)
> > The warning is called -Wunterminated-string-initialization, but there is no
> > unterminated string. That is what this bug is about. If people want a
> > warning for truncated data, there should be a new warning for that, making
> > -Wunterminated-string-initialization do something other than what its name
> > clearly says it does is not the right way of handling that.
> 
> Not only there's no _unterminated string_; there's no _string_ at all.  That
> string literal is not a string.

That string literal is not a string, sure.

> So, if you're using a non-string to initialize a string, you deserve a
> diagnostic.

Including "so" does not actually make what you write follow from the preceding.

If you want to make the argument that there is no unterminated string because
there is no string in the first place, then the logical conclusion is still
that  -Wunterminated-string-initialization should not warn about that.

If you want a warning for something other than unterminated strings, that
should be a different warning, not -Wunterminated-string-initialization.

[Bug middle-end/109267] generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||EH, link-failure,
   ||wrong-code
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #6 from Andrew Pinski  ---
I have an idea on how to fix this.

[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting

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

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

--- Comment #22 from Jonathan Wakely  ---
I don't think there any point reducing this, I can see what the code does and
it's invalid. Adding a non-trivial copy constructor fixes it.

[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #23 from mcccs at gmx dot com ---
Yes that's what I think! Thanks

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #5 from mcccs at gmx dot com ---
I have the source failing with latest GCC and succeeding with GCC 14. I'll try
to reduce it

[Bug fortran/119948] Source allocation of pure function result rejected

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #3 from kargls at comcast dot net ---
Created attachment 61202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61202&action=edit
fix the issues

The attached patch has passed regression testing on x86_64-*-freebsd.

* primary.cc (match_variable): Handle a result-name with an
allocatable component in a pure function.
* resolve.cc (gfc_impure_variable): Ditto.


* gfortran.dg/pr119948_1.f90: New testcase.
* gfortran.dg/pr119948_2.f90: Ditto.

[Bug middle-end/119954] New: "a < b < c < d < ..." taking long time to process to generate error message

[mcccs at gmx dot com via Gcc-bugs]

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

Bug ID: 119954
   Summary: "a < b < c < d < ..." taking long time to process to
generate error message
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

While trying to reduce pr118526, I found that source code of just

"a < b < c < d < ..."

compiled with std=c++20 is taking long times. an extra "< next_letter" added
takes 15 times more time I guess

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #6 from Sam James  ---
Created attachment 61201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61201&action=edit
foo.sh

Looking at your log, I tried this, but it didn't reproduce it for me.

[Bug c/119432] gimple front-end and round trip for fails for __builtin_stdc_rotate_left

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Andrew Pinski  ---
Patch(es):
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681920.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681921.html

[Bug c/119959] New: [15 regression] simple loop miscompiled into an endless loop

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 119959
   Summary: [15 regression] simple loop miscompiled into an
endless loop
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 61205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61205&action=edit
test case foo.c

gcc 15.1.0 (built from source, full bootstrap, with isl) generates wrong code
for the function 'rehash_symtab' in the attached test case foo.c.

How to reproduce:
$ gcc -Wall -O1 -S -fno-dwarf2-cfi-asm foo.c -o foo.gcc15.O1.s

For comparison, gcc 14.2.0 (also built from source, full bootstrap, with isl)
generates correct code:
$ gcc -Wall -O1 -S -fno-dwarf2-cfi-asm foo.c -o foo.gcc14.O1.s

In the source code, the function rehash_symtab contains two loops, each with a
call to newinsert() in the middle, and a final epilogue that stores two words
in memory and then returns.

In foo.gcc14.O1.s (correct) you can see the second loop like this:
===
.L8:
addq$8, %r12
cmpq%r12, %rbx
je  .L16
.L9:
movqSTACK(%rip), %rax
movq-24(%rax), %rdx
movq10(%r12,%rdx), %rdi
cmpq$symbol_tab_data+6, %rdi
je  .L8
movq%rdi, %rdx
andl$7, %edx
cmpq$2, %rdx
je  .L8
movq%rdi, (%rax)
addq$8, STACK(%rip)
movl%ebp, %esi
callnewinsert
subq$8, STACK(%rip)
jmp .L8
===

In foo.gcc15.O1.s (miscompiled) you can see the second loop like this:
===
.L7:
addq$8, %rbx
.L8:
movqSTACK(%rip), %rax
movq-24(%rax), %rdx
movq10(%rbx,%rdx), %rdi
cmpq$symbol_tab_data+6, %rdi
je  .L7
movq%rdi, %rdx
andl$7, %edx
cmpq$2, %rdx
je  .L7
movq%rdi, (%rax)
addq$8, STACK(%rip)
movl%ebp, %esi
callnewinsert
subq$8, STACK(%rip)
jmp .L7
===

You can see that here,
  - between .L7 and .L8 the loop termination condition is missing,
(foo.c line 118),
  - accordingly the loop has become and endless loop,
  - and as a consequence the function's epilogue has been removed.

[Bug c/119959] [15 regression] simple loop miscompiled into an endless loop

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #2 from Bruno Haible  ---
Created attachment 61207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61207&action=edit
foo.c compiled by gcc 15.1

[Bug c/119959] [15 regression] simple loop miscompiled into an endless loop

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #1 from Bruno Haible  ---
Created attachment 61206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61206&action=edit
foo.c compiled by gcc 14.2

[Bug target/105275] [12/13/14/15/16 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r16-162-g1d635e79b3c2d26f864964b79717132bffbcad20
Author: Jan Hubicka 
Date:   Sat Apr 26 22:10:19 2025 +0200

Fix i386 vectorizer cost of FP scalar MAX_EXPR and MIN_EXPR

I introduced a bug by last minute cleanups unifying the scalar and vector
SSE conditional.
This patch fixes it and restores cost of 1 of SSE scalar MIN/MAX

Bootstrapped/regtested x86_64-linux, comitted.

gcc/ChangeLog:

PR target/105275
* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost): Fix cost
of FP scalar
MAX_EXPR and MIN_EXPR

[Bug tree-optimization/119959] [15/16 regression] simple loop miscompiled into an endless loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host|x86_64-linux-gnu|
  Component|c   |tree-optimization

--- Comment #3 from Andrew Pinski  ---
-fno-ivopts looks to fix it ...

[Bug middle-end/109267] generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

--- Comment #9 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681924.html

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

[steffen at sdaoden dot eu via Gcc-bugs]

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

--- Comment #11 from Steffen Nurpmeso  ---
I had reverted to 14.2.0.
Alejandro, the NUL is not "embedded", it "terminates".
*OR* at least this is what i am used to; for me this is a string literal.

Also to uecker who moves the camel through the eye of the needle:
Dennis Ritchie writes in his "The Development of the C Language"

   C treats strings as arrays of characters conventionally terminated by a
marker. Aside from one special rule about initialization by string literals,
the semantics of strings are fully subsumed by more general rules governing all
arrays, and as a result the language is simpler to describe and to translate
than one incorporating the string as a unique data type.

In the 2nd edition of the C programming language K&R write

  Adjacent string literals are concatenated into a single string. After any
concatenation, a null byte \0 is appended to the string so that programs that
scan the string can find its end.

But i must be very much mistaken if you get two \0\0 in such a case for many
generations of compilers back to around Y2K.

I mean, it could very well be i am, though twenty++ years ago i surely often
looked in assembler output, including .asciz definitions and such.
It is ok for .asciz to simply add a \0, and for .ascii not to.
I just looked, this was documented already Y2K (2.95.3 i started with that).

But really, C frontends -- isn't this a change in actual behavior?
uecker?

[Bug target/119549] [14 Regression] SSE4 code inlined into no-sse4 function

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

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

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

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

commit r16-164-gd85444a3b00c9a6fce56459af5ec081439a9aaa0
Author: liuhongt 
Date:   Tue Apr 1 00:30:07 2025 -0700

Refactor msse4 and mno-sse4.

gcc/ChangeLog:

PR target/119549
* common/config/i386/i386-common.cc (ix86_handle_option):
Refactor msse4 and mno-sse4.
* config/i386/i386.opt (msse4): Remove RejectNegative.
(mno-sse4): Remove the entry.
* config/i386/i386-options.cc
(ix86_valid_target_attribute_inner_p): Remove special code
which handles mno-sse4.

[Bug tree-optimization/119960] New: Regression of code generation

[arseny.kapoulkine at gmail dot com via Gcc-bugs]

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

Bug ID: 119960
   Summary: Regression of code generation
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arseny.kapoulkine at gmail dot com
  Target Milestone: ---

Created attachment 61208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61208&action=edit
perf assembly

Starting from gcc15, index decoder benchmark in
https://github.com/zeux/meshoptimizer sees a substantial regression with O2/O3:

Using Zen 4 (7950X) CPU:

gcc14 O2: 4.80 GB/s
gcc14 O3: 7.10 GB/s

gcc15 O2: 5.40 GB/s
gcc15 O3: 4.50 GB/s

clang20 O2: 6.10 GB/s
clang20 O3: 6.10 GB/s

To reproduce this, run:

   make config=release codecbench && ./codecbench -l

.. after cloning the project. You can also use `CXX=` variable to override the
compiler.

The function that regressed is meshopt_decodeIndexBuffer in src/indexcodec.cpp.

I've bisected the regression to:

commit 5ab3f091b3eb42795340d3c9cea8aaec2060693c (HEAD)
Author: Richard Biener 
Date:   Mon Dec 2 11:07:46 2024 +0100

tree-optimization/116352 - SLP scheduling and stmt order

I've attached the hot loop as ran under perf, when using gcc15 before the
referenced commit and at the referenced commit.

[Bug tree-optimization/119960] Regression of code generation

[arseny.kapoulkine at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Arseny Kapoulkine  ---
Here's what I think is happening:

- The C code hot path is, on every iteration, reading a pair of integers from
`edgefifo`, decoding a triangle and writing two new pairs of integers to
`edgefifo`. It's very common for the edge to be written on one iteration and
read on the next iteration.

- In gcc 14, the read is done twice; once into a 64-bit GPR (rbp), and once
into two separate XMM registers (xmm0/xmm1). Each of the two writes is using a
64-bit movq from the XMM registers.

- In gcc 15, the read is done once as a 64-bit value into an XMM register
(xmm0). Both writes are split and are done one pair element at a time (both
from XMM and from GPR).

I assume this breaks store-to-load forwarding, or makes it more expensive: for
code generated by gcc 14, the CPU only needs to know how to forward 64-bit
stores into separate 32-bit halves; for code generated by gcc 15, CPU would
need to know how to combine two 32-bit writes into a single 64-bit load, and
Zen 4 (just as many other CPUs) can't do that.

AMD uProf shows ~47M successfull store->load forwards on gcc15 binary and ~151M
on gcc14 binary.

[Bug fortran/119928] [15/16 Regression] Bogus "Interface mismatch" in gfortran.dg/proc_ptr_52.f90 with -Wall

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-26
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-reduction |
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #24 from Sam James  ---
.

[Bug translation/89936] wrong punctuation in tree-profile.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #6 from mcccs at gmx dot com ---
Created attachment 61203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61203&action=edit
preprocessed.cpp.xz

The preprocessed source

[Bug fortran/119948] Source allocation of pure function result rejected

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

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

Jerry DeLisle  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-27
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
A small adjustment to the comment in the patch:

  /* If sym is for a result-name, its pure attribute may not be set.
 Check the namespace to see if this is a procedure and, if it is a 
 pure function.  */

instead of:

  /* If sym is for a result-name, then its pure attribute may not be set.
 Check the namespace to see if this a procedure, and if it is a 
 pure function.  */

Otherwise, OK and regression tests fine here as well.

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
No this is the same problem as PR 116600. Just the ICE shows up.

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

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-171-gcdb239bd213524a43b38ad8fca8e7ed0b5fb41eb
Author: H.J. Lu 
Date:   Sun Nov 10 11:27:14 2024 +0800

i386: Adjust apx-ndd.c for frontend promotion removal

Since the C frontend no longer promotes integer argument smaller than int,
the apx-ndd.c codgen is slightly different:

apx-ndd.s (original)2024-11-10 06:07:09.894876973 +0800
apx-ndd.s (updated) 2024-11-10 06:06:59.371860565 +0800
@@ -17,7 +17,7 @@ foo_add_char:
 foo1_add_char:
 .LFB1:
.cfi_startproc
-   leal(%rsi,%rdi), %eax
+   leal(%rdi,%rsi), %eax
ret
.cfi_endproc
 .LFE1:
@@ -50,7 +50,7 @@ foo_add_short:
 foo1_add_short:
 .LFB4:
.cfi_startproc
-   leal(%rsi,%rdi), %eax
+   leal(%rdi,%rsi), %eax
ret
.cfi_endproc
 .LFE4:
@@ -413,7 +413,7 @@ foo_and_char:
 foo1_and_char:
 .LFB37:
.cfi_startproc
-   andl%edi, %esi, %eax
+   andl%esi, %edi, %eax
ret
.cfi_endproc
 .LFE37:
@@ -435,7 +435,7 @@ foo_and_short:
 foo1_and_short:
 .LFB39:
.cfi_startproc
-   andl%edi, %esi, %eax
+   andl%esi, %edi, %eax
ret
.cfi_endproc
 .LFE39:
@@ -501,7 +501,7 @@ foo_or_char:
 foo1_or_char:
 .LFB45:
.cfi_startproc
-   orl %edi, %esi, %eax
+   orl %esi, %edi, %eax
ret
.cfi_endproc
 .LFE45:
@@ -523,7 +523,7 @@ foo_or_short:
 foo1_or_short:
 .LFB47:
.cfi_startproc
-   orl %edi, %esi, %eax
+   orl %esi, %edi, %eax
ret
.cfi_endproc
 .LFE47:
@@ -589,7 +589,7 @@ foo_xor_char:
 foo1_xor_char:
 .LFB53:
.cfi_startproc
-   xorl%edi, %esi, %eax
+   xorl%esi, %edi, %eax
ret
.cfi_endproc
 .LFE53:
@@ -611,7 +611,7 @@ foo_xor_short:
 foo1_xor_short:
 .LFB55:
.cfi_startproc
-   xorl%edi, %esi, %eax
+   xorl%esi, %edi, %eax
ret
.cfi_endproc
 .LFE55:
@@ -1018,7 +1018,7 @@ foo4_rol_uint64_t:
 foo1_imul_short:
 .LFB92:
.cfi_startproc
-   imull   %edi, %esi, %eax
+   imull   %esi, %edi, %eax
ret
.cfi_endproc
 .LFE92:

Adjust the assembler scans.

PR middle-end/112877
* gcc.target/i386/apx-ndd.c: Adjusted.

Signed-off-by: H.J. Lu 

[Bug tree-optimization/119960] [15/16 Regression] vectorizer seems not to do as much any more since r15-5863

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-reduction,
   ||needs-source
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
Summary|[15/16 Regression]  |[15/16 Regression]
   |vectorizer seems not to do  |vectorizer seems not to do
   |as much any more|as much any more since
   ||r15-5863
   Last reconfirmed||2025-04-27

--- Comment #2 from Andrew Pinski  ---
Can you provide the preprocessed source of the file which is having the issue
as requested by https://gcc.gnu.org/bugs/ .


>commit 5ab3f091b3eb42795340d3c9cea8aaec2060693c (HEAD)
r15-5863-g5ab3f091b3eb42

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

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

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

--- Comment #7 from Matthias Klose  ---
the same build / configuration succeeds to build on Ubuntu (Ubuntu has all the
hardening flags turned on by default, Debian keeps them off by default).

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

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

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

--- Comment #8 from Matthias Klose  ---
and both builds use the 64bit time_t changes, which are still in review.

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---
Created attachment 61211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61211&action=edit
test-ree.png

[Bug rtl-optimization/119961] Control flow errors caused by shrink wrap optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Yes this is a dup of bug 116600.

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

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||chenglulu at loongson dot cn

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

[Bug tree-optimization/119959] [15/16 regression] simple loop miscompiled into an endless loop

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #4 from mcccs at gmx dot com ---
> -fno-ivopts looks to fix it ...

Then is it a duplicate of pr119872 ?

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #8 from mcccs at gmx dot com ---
bisect bad commit: r15-3153-g68ee624bc52ba1

reduce is running, we can't know if the fault is in a commit or in the source
for now