[Bug target/114094] New: Assembler messages: Error: junk `nop' after expression with -fprofile -fPIE -mno-direct-extern-access -masm=intel

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114094
   Summary: Assembler messages: Error: junk `nop' after expression
with -fprofile -fPIE -mno-direct-extern-access
-masm=intel
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Compiler output:
$ echo 'void foo(void) {}' > testcase.c
$ x86_64-pc-linux-gnu-gcc -fprofile -fPIE -mno-direct-extern-access -masm=intel
testcase.c
/tmp/ccu6XIRH.s: Assembler messages:
/tmp/ccu6XIRH.s:14: Error: junk `nop' after expression

The offending line is:
...
1:  call[QWORD PTR mcount@GOTPCREL[rip]]nop
...

There is probably missing a newline somewhere.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9161-20240224001742-g4d9da4199d1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9161-20240224001742-g4d9da4199d1-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240224 (experimental) (GCC)

[Bug tree-optimization/114095] New: ICE: in build2, at tree.cc:5097

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 114095
   Summary: ICE: in build2, at tree.cc:5097
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/c4d5x6Eza

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/2024020020942/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/2024020020942/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/2024020020942
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240204 (experimental) (GCC)

git version: 8e6ebacc9e3cee0d2053fdaceda0ae052e34b777
***
Program:
$ cat mutant.c
__GIMPLE a(double *x) {
  b c;
  d = x_80 + c

***
Command Lines:
$ gcc mutant.c
mutant.c:1:1: error: ‘__GIMPLE’ only valid with ‘-fgimple’
1 | __GIMPLE a(double *x) {
  | ^~~~
mutant.c:1:10: error: return type defaults to ‘int’ [-Wimplicit-int]
1 | __GIMPLE a(double *x) {
  |  ^
mutant.c: In function ‘a’:
mutant.c:2:3: error: unknown type name ‘b’
2 |   b c;
  |   ^
mutant.c:3:3: error: ‘d’ undeclared (first use in this function)
3 |   d = x_80 + c
  |   ^
mutant.c:3:3: note: each undeclared identifier is reported only once for each
function it appears in
mutant.c:3:3: internal compiler error: in build2, at tree.cc:5097
0x869763 build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/gcc/tree.cc:5097
0x9f960f build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/tree.h:4750
0x9f960f c_parser_gimple_binary_expression
../../gcc/gcc/c/gimple-parser.cc:1068
0x9fa561 c_parser_gimple_statement
../../gcc/gcc/c/gimple-parser.cc:878
0x9fb2aa c_parser_gimple_compound_statement
../../gcc/gcc/c/gimple-parser.cc:669
0x9fcca1 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
../../gcc/gcc/c/gimple-parser.cc:253
0x9e8cd4 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.cc:3011
0x9f2f3b c_parser_external_declaration
../../gcc/gcc/c/c-parser.cc:2046
0x9f3925 c_parser_translation_unit
../../gcc/gcc/c/c-parser.cc:1900
0x9f3925 c_parse_file()
../../gcc/gcc/c/c-parser.cc:26815
0xa6ad51 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1306
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.

[Bug ada/113862] error: "others" choice not allowed here

[p.p11 at orange dot fr via Gcc-bugs]

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

--- Comment #5 from Pascal Pignard  ---
Created attachment 57522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57522&action=edit
Reproducer updated (no more error)

I apologize the reproducer was wrong, I assumed Some_Array unconstrained
whereas it should have been constrained:
   type Some_Array is array (Positive range 1 .. 10) of NTCT;
Then no more error issue.
I've updated the reproducer.
Sorry for that, Pascal.

[Bug tree-optimization/114096] New: ICE: in lower_stmt, at gimple-lower-bitint.cc:5533 on vector -> _BitInt() cast

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114096
   Summary: ICE: in lower_stmt, at gimple-lower-bitint.cc:5533 on
vector -> _BitInt() cast
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c -Wno-psabi
during GIMPLE pass: bitintlower0
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in lower_stmt, at
gimple-lower-bitint.cc:5533
5 | foo(V v)
  | ^~~
0xd8d6b3 lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5533
0x27235b9 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6719
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9161-20240224001742-g4d9da4199d1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9161-20240224001742-g4d9da4199d1-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240224 (experimental) (GCC)

[Bug rtl-optimization/101523] Huge number of combine attempts

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

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

--- Comment #5 from Segher Boessenkool  ---
Hrm.  When did this start, can you tell?

[Bug c/114097] New: Missed register optimization in _Noreturn functions

[pskocik at gmail dot com via Gcc-bugs]

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

Bug ID: 114097
   Summary: Missed register optimization in _Noreturn functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

Consider a never-returning functions such as this:

#include
#include
//_Noreturn
void noret(unsigned A, unsigned B, unsigned C, unsigned D, unsigned E, jmp_buf
Jb){

for(;A--;) puts("A");
for(;B--;) puts("B");
for(;C--;) puts("C");
for(;D--;) puts("D");
for(;E--;) puts("E");

longjmp(Jb,1);
}

https://godbolt.org/z/35YjrhjYq

In its prologue, gcc saves the arguments in call-preserved registers to
preserve them around the puts calls, and it does so the usual way: by (1)
pushing the old values of the call-preserved registers to the stack and (2)
actually moving the arguments into the call-preserved registers.

pushq   %r15
movq%r9, %r15
pushq   %r14
movl%edi, %r14d
pushq   %r13
movl%esi, %r13d
pushq   %r12
movl%edx, %r12d
pushq   %rbp
movl%ecx, %ebp
pushq   %rbx
movl%r8d, %ebx
pushq   %rax
//...

Since this function demonstrably never returns, step 1 can be entirely elided
as the old values of the call-preserved registers won't ever need to be
restored
(desirably, gcc does not generate the would-be-dead restoration code):


movq%r9, %r15
movl%edi, %r14d
movl%esi, %r13d
movl%edx, %r12d
movl%ecx, %ebp
movl%r8d, %ebx
pushq   %rax
//...

(Also desirable would be the unrealized tailoptimization of the longjmp call in
this case: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837)

[Bug modula2/113749] [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-9167-gd1b241b9506cdc0ebd3f43d12cf77d7c33271342
Author: Gaius Mulley 
Date:   Sun Feb 25 11:08:37 2024 +

PR modula2/113749 m2 enabled build times out on i686-gnu-hurd

The bug fix changes the FIO module to use the target O_RDONLY,
O_WRONLY, SEEK_SET and SEEK_END (now available from the module wrapc).
Also rebuilt are the bootstrap tools mc and pge as they have their
own wrapc and C translations of FIO.

gcc/m2/ChangeLog:

PR modula2/113749
* Make-lang.in (BUILD-PGE-O): Add m2/pge-boot/Gwrapc.o.
* gm2-libs-ch/wrapc.c (wrapc_SeekSet): New function.
(wrapc_SeekEnd): Ditto.
(wrapc_ReadOnly): Ditto.
(wrapc_WriteOnly): Ditto.
* gm2-libs/FIO.mod (SEEK_SET): Remove.
(SEEK_END): Remove.
(UNIXREADONLY): Remove.
(UNIXWRITEONLY): Remove.
(ConnectToUnix): Replace UNIXWRITEONLY with a call to WriteOnly.
Replace UNIXREADONLY with a call to ReadOnly.
(SetPositionFromBeginning): Replace SEEK_SET with a call to
SeekSet.
(SetPositionFromEnd): Replace SEEK_END with a call to
SeekEnd.
* gm2-libs/wrapc.def (SeekSet): New procedure function.
(SeekEnd): New procedure function.
(ReadOnly): New procedure function.
(WriteOnly): New procedure function.
* mc-boot-ch/Glibc.c (BUILD_MC_LIBC_TRACE): Undef.
(check_init): New function.
(tracedb): Ditto.
(tracedb_open): Ditto.
(tracedb_result): Ditto.
(libc_read): Ditto.
(libc_write): Ditto.
(libc_close): Ditto.
(libc_creat): Ditto.
(libc_open): Ditto.
(libc_lseek): Ditto.
* mc-boot-ch/Gwrapc.c (wrapc_SeekSet): New function.
(wrapc_SeekEnd): Ditto.
(wrapc_ReadOnly): Ditto.
(wrapc_WriteOnly): Ditto.
* mc-boot/GDynamicStrings.cc: Rebuilt.
* mc-boot/GFIO.cc: Ditto.
* mc-boot/GIndexing.cc: Ditto.
* mc-boot/GM2Dependent.cc: Ditto.
* mc-boot/GM2EXCEPTION.cc: Ditto.
* mc-boot/GPushBackInput.cc: Ditto.
* mc-boot/GRTExceptions.cc: Ditto.
* mc-boot/GRTint.cc: Ditto.
* mc-boot/GSArgs.cc: Ditto.
* mc-boot/GStdIO.cc: Ditto.
* mc-boot/GStringConvert.cc: Ditto.
* mc-boot/GSysStorage.cc: Ditto.
* mc-boot/Gdecl.cc: Ditto.
* mc-boot/Gkeyc.cc: Ditto.
* mc-boot/Glibc.h: Ditto.
* mc-boot/GmcComment.cc: Ditto.
* mc-boot/GmcComp.cc: Ditto.
* mc-boot/GmcDebug.cc: Ditto.
* mc-boot/GmcMetaError.cc: Ditto.
* mc-boot/GmcStack.cc: Ditto.
* mc-boot/GmcStream.cc: Ditto.
* mc-boot/GnameKey.cc: Ditto.
* mc-boot/GsymbolKey.cc: Ditto.
* mc-boot/Gvarargs.cc: Ditto.
* mc-boot/Gwrapc.h: Ditto.
* mc/decl.mod (getSymName): Add pointerref clause.
* mc/mcStream.mod (copy): Check for an error after every read.
* mc/varargs.mod (copy): Rewrite pointer arithmetic using INC to
avoid type incompatibility.
* pge-boot/GDynamicStrings.cc: Rebuilt.
* pge-boot/GDynamicStrings.h: Ditto.
* pge-boot/GFIO.cc: Ditto.
* pge-boot/GFIO.h: Ditto.
* pge-boot/GIO.cc: Ditto.
* pge-boot/GIndexing.cc: Ditto.
* pge-boot/GM2Dependent.cc: Ditto.
* pge-boot/GM2EXCEPTION.cc: Ditto.
* pge-boot/GNameKey.cc: Ditto.
* pge-boot/GPushBackInput.cc: Ditto.
* pge-boot/GRTExceptions.cc: Ditto.
* pge-boot/GStdIO.cc: Ditto.
* pge-boot/GSymbolKey.cc: Ditto.
* pge-boot/GSysStorage.cc: Ditto.
* pge-boot/Glibc.h: Ditto.
* pge-boot/Gwrapc.cc: Ditto.
* pge-boot/Gwrapc.h: Ditto.

libgm2/ChangeLog:

PR modula2/113749
* libm2pim/wrapc.cc: Include fcntl.h.
(SeekSet): New function.
(SeekEnd): Ditto.
(ReadOnly): Ditto.
(WriteOnly): Ditto.

Signed-off-by: Gaius Mulley 

[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab

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

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

Filip Kastl  changed:

   What|Removed |Added

Summary|[14 Regression] 435.gromacs |[14 Regression] 435.gromacs
   |fails verification with |fails verification with
   |-Ofast -march=znver4 and|-Ofast
   |PGO after   |-march={znver2,znver4} and
   |r14-7272-g57f611604e8bab|PGO after
   ||r14-7272-g57f611604e8bab

--- Comment #6 from Filip Kastl  ---
I just observed the same miscomparison on a Zen2 machine. Exactly the same
values:

0002:  3.07684e+02
   3.11606e+02

So I assume it's the same problem.

[Bug tree-optimization/113833] 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

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

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

Filip Kastl  changed:

   What|Removed |Added

 CC||pheeck at gcc dot gnu.org

--- Comment #5 from Filip Kastl  ---
Just posting here to notify that I've found a very similar miscomparison on AMD
Zen CPUs: pr114057

[Bug modula2/113749] [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #7 from Gaius Mulley  ---
I'm optimistically closing the PR - thanks for the report - please re-open if
the problem persists.  I've seen cc1gm2 build on a debian i686 hurd system.

Interestingly the bug fix might well be applicable for other non Unix hosts.

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[pskocik at gmail dot com via Gcc-bugs]

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

Petr Skocik  changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #19 from Petr Skocik  ---
IMO(In reply to Xi Ruoyao from comment #16)

> In practice most _Noreturn functions are abort, exit, ..., i.e. they are
> only executed one time so optimizing against a cold path does not help much.
> I don't think it's a good idea to encourage people to construct some fancy
> code by a recursive _Noreturn function (why not just use a loop?!)  And if
> you must write such fancy code anyway IMO musttail attribute (PR83324) will
> be a better solution.

There's also longjmp, which may not be all that super cold and may be executed
multiple times. And while yeah, nobody will notice a single call vs jmp time
save against a process spawn/exit, for a longjmp wrapper, it'll make it a few %
faster (as would utilizing _Noreturn attributes for better register allocation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097, which would also save a
bit of codesize too). Taillcalls can also save a bit of codesize if the target
is near.

[Bug target/114094] Assembler messages: Error: junk `nop' after expression with -fprofile -fPIE -mno-direct-extern-access -masm=intel

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Oops, my fault.
--- gcc/config/i386/i386.cc.jj  2024-02-22 10:10:18.675032283 +0100
+++ gcc/config/i386/i386.cc 2024-02-25 13:12:12.403323842 +0100
@@ -22909,7 +22909,7 @@ x86_function_profiler (FILE *file, int l
  if (!ix86_direct_extern_access)
{
  if (ASSEMBLER_DIALECT == ASM_INTEL)
-   fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]",
+   fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
 mcount_name);
  else
fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n",

[Bug tree-optimization/114096] ICE: in lower_stmt, at gimple-lower-bitint.cc:5533 on vector -> _BitInt() cast

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
This seems to no longer fail with r14-9166:

$ x86_64-pc-linux-gnu-gcc testcase.c -Wno-psabi
/usr/bin/x86_64-pc-linux-gnu-ld: /usr/lib/../lib64/crt1.o: in function
`_start':
(.text+0x17): undefined reference to `main'
collect2: error: ld returned 1 exit status

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9166-20240225001706-g5c45dc1b978-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9166-20240225001706-g5c45dc1b978-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240225 (experimental) (GCC)

[Bug tree-optimization/114096] ICE: in lower_stmt, at gimple-lower-bitint.cc:5533 on vector -> _BitInt() cast

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
It is probably dup of PR114073. Sorry about that.

[Bug tree-optimization/113622] [11/12/13 Regression] ICE with vectors in named registers

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

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

--- Comment #24 from Xi Ruoyao  ---
It looks I can rewrite the LoongArch test case (still broken though ICE is
stopped) using check-function-bodies.  Will try later...

[Bug c/114097] Missed register optimization in _Noreturn functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-25
Version|unknown |14.0
 CC||hjl.tools at gmail dot com
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
__attribute__((noreturn)) works in GCC 14:

[hjl@gnu-cfl-3 tmp]$ cat y.c
#include
#include
//_Noreturn
__attribute__((noreturn))
void noret(unsigned A, unsigned B, unsigned C, unsigned D, unsigned E, jmp_buf
Jb){

for(;A--;) puts("A");
for(;B--;) puts("B");
for(;C--;) puts("C");
for(;D--;) puts("D");
for(;E--;) puts("E");

longjmp(Jb,1);
}
[hjl@gnu-cfl-3 tmp]$ /usr/gcc-14.0.1-x32/bin/gcc -S -O2 y.c
[hjl@gnu-cfl-3 tmp]$ cat y.s
.file   "y.c"
.text
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "A"
.LC1:
.string "B"
.LC2:
.string "C"
.LC3:
.string "D"
.LC4:
.string "E"
.text
.p2align 4
.globl  noret
.type   noret, @function
noret:
.LFB11:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl%esi, %r15d
movl%edx, %r14d
movl%ecx, %r13d
movl%r8d, %ebp
movq%r9, %r12
testl   %edi, %edi
je  .L2
leal-1(%rdi), %ebx
.p2align 4,,10
.p2align 3
.L3:
movl$.LC0, %edi
callputs
subl$1, %ebx
jnb .L3
.L2:
leal-1(%r15), %ebx
testl   %r15d, %r15d
je  .L4
.p2align 4,,10
.p2align 3
.L5:
movl$.LC1, %edi
callputs
subl$1, %ebx
jnb .L5
.L4:
leal-1(%r14), %ebx
testl   %r14d, %r14d
je  .L6
.p2align 4,,10
.p2align 3
.L7:
movl$.LC2, %edi
callputs
subl$1, %ebx
jnb .L7
.L6:
leal-1(%r13), %ebx
testl   %r13d, %r13d
je  .L8
.p2align 4,,10
.p2align 3
.L9:
movl$.LC3, %edi
callputs
subl$1, %ebx
jnb .L9
.L8:
leal-1(%rbp), %ebx
testl   %ebp, %ebp
je  .L10
.p2align 4,,10
.p2align 3
.L11:
movl$.LC4, %edi
callputs
subl$1, %ebx
jnb .L11
.L10:
movl$1, %esi
movq%r12, %rdi
calllongjmp
.cfi_endproc
.LFE11:
.size   noret, .-noret
.ident  "GCC: (GNU) 14.0.1 20240223 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 tmp]$

[Bug c/114097] Missed register optimization in _Noreturn functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #2 from H.J. Lu  ---
I couldn't find a way to access the _Noreturn info in backend.

[Bug c/114088] Please provide __builtin_c16slen and __builtin_c32slen to complement __builtin_wcslenw

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Xi Ruoyao from comment #2)
> But __builtin_strlen *does* get optimized when the input is a string
> literal.

But so does strlen, because GCC knows about it. That's my point.

[Bug c/114097] Missed register optimization in _Noreturn functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 57524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57524&action=edit
A patch

[Bug target/114097] Missed register optimization in _Noreturn functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

  Component|c   |target
   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

[Bug target/114097] Missed register optimization in _Noreturn functions

[pskocik at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Petr Skocik  ---
Excellent! Thank you very much. Didn't realize the functionality was already
there, but didn't work without an explicit __attribute((noreturn)). Now I can
get rid of my most complex assembly function which I stupidly (back then I
thought cleverly) wrote. :)

[Bug target/114098] New: _tile_loadconfig doesn't work

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 114098
   Summary: _tile_loadconfig doesn't work
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-cfl-3 amx-1]$ cat foo.c
#include 
#include 

#define MAX_ROWS 16
#define MAX_COLS 64
#define MAX 1024
#define STRIDE 64

typedef struct __tile_config
{
  uint8_t palette_id;
  uint8_t start_row;
  uint8_t reserved_0[14];
  uint16_t colsb[16];
  uint8_t rows[16];
} __tilecfg;


extern void bar (__tilecfg *tileinfo);

/* Initialize tile config */
static void
init_tile_config (__tilecfg *tileinfo)
{
  int i;
  tileinfo->palette_id = 1;
  tileinfo->start_row = 0;

  for (i = 0; i < 1; ++i)
  {
tileinfo->colsb[i] = MAX_ROWS;
tileinfo->rows[i] =  MAX_ROWS;
  }

  for (i = 1; i < 4; ++i)
  {
tileinfo->colsb[i] = MAX_COLS;
tileinfo->rows[i] =  MAX_ROWS;
  }

  _tile_loadconfig (tileinfo);
}

void
enable_amx (void)
{
  __tilecfg tile_data = {0};
  init_tile_config (&tile_data);
}
[hjl@gnu-cfl-3 amx-1]$ gcc -S -O2 -mamx-tile foo.c
[hjl@gnu-cfl-3 amx-1]$ cat foo.s
.file   "foo.c"
.text
.p2align 4
.globl  enable_amx
.type   enable_amx, @function
enable_amx:
.LFB6615:
.cfi_startproc
movl$1, %eax < tile_data isn't properly initialized.
movw%ax, -72(%rsp)
#APP
# 42 "/usr/lib/gcc/x86_64-redhat-linux/13/include/amxtileintrin.h" 1
ldtilecfg   -72(%rsp)
# 0 "" 2
#NO_APP
ret
.cfi_endproc
.LFE6615:
.size   enable_amx, .-enable_amx
.ident  "GCC: (GNU) 13.2.1 20231205 (Red Hat 13.2.1-6)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 amx-1]$

[Bug rtl-optimization/101523] Huge number of combine attempts

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

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

--- Comment #6 from Segher Boessenkool  ---
There is no attached testcase, btw.  This makes investigating this kind of
tricky ;-)

[Bug target/114098] _tile_loadconfig doesn't work

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #1 from H.J. Lu  ---
The problem is that in

extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_tile_loadconfig (const void *__config)
{
  __asm__ volatile ("ldtilecfg\t%X0" :: "m" (*((const void **)__config)));
}

only 8 bytes are used.

[Bug middle-end/114099] New: [14 regression] ICE when building darktable-4.6.1

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

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

Bug ID: 114099
   Summary: [14 regression] ICE when building darktable-4.6.1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57525&action=edit
PentaxDecompressor.cpp.ii

This was found after applying the patch from PR114068. I can hit it without too
though.

Initially reported downstream in Gentoo by tdr.

```
$ gcc -c PentaxDecompressor.cpp.ii -O3 -march=sapphirerapids -std=c++20
during GIMPLE pass: vect
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/decompressors/PentaxDecompressor.cpp:
In static member function ‘static
rawspeed::HuffmanCode
rawspeed::PentaxDecompressor::SetupPrefixCodeDecoder_Modern(rawspeed::ByteStream)’:
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/decompressors/PentaxDecompressor.cpp:81:1:
internal compiler error: Segmentation fault
0x55743ad30b10 crash_signal
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/toplev.cc:319
0x55743bb50b1f find_uses_to_rename_use
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-ssa-loop-manip.cc:414
0x55743bb50b1f find_uses_to_rename_bb(basic_block_def*, bitmap_head**,
bitmap_head*, int) [clone .constprop.0]
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-ssa-loop-manip.cc:489
0x55743b993aed find_uses_to_rename
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-ssa-loop-manip.cc:521
0x55743b993aed rewrite_into_loop_closed_ssa_1
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-ssa-loop-manip.cc:588
0x55743b993aed rewrite_into_loop_closed_ssa(bitmap_head*, unsigned int)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-ssa-loop-manip.cc:628
0x55743bd1e8d9 execute
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-vectorizer.cc:1360
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.
```

[Bug middle-end/114099] [14 regression] ICE when building darktable-4.6.1

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

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

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

Attached reduced version from tdr too. I can reproduce with `gcc -c
PentaxDecompressor.cpp.ii -O3 -mavx -std=c++20`.

[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3) since r14-6822

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/114098] _tile_loadconfig doesn't work

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-25

--- Comment #2 from H.J. Lu  ---
We should tell GCC that 64 bytes will be accessed by ldtilecfg and sttilecfg.

[Bug target/114097] Missed register optimization in _Noreturn functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #5 from H.J. Lu  ---
A patch is submitted:

https://patchwork.sourceware.org/project/gcc/list/?series=31294

[Bug middle-end/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

Sam James  changed:

   What|Removed |Added

  Attachment #57526|0   |1
is obsolete||

--- Comment #2 from Sam James  ---
Created attachment 57527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57527&action=edit
reduced.ii

[Bug target/114100] New: [avr] Inefficient indirect addressing on Reduced Tiny

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

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

Bug ID: 114100
   Summary: [avr] Inefficient indirect addressing on Reduced Tiny
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The Reduced Tiny core does not support indirect addressing with offset, which
basically means that every indirect memory access with a size of more than one
byte is effectively POST_INC or PRE_DEC.  The lack of that addressing mode is
currently handled by pretending to support it, and then let the insn printers
add and subtract again offsets as needed on the fly.

For example, the following C code

   int vars[10];

   void inc_var2 (void) {
  ++vars[2];
   }

is compiled to:

   ldi r30,lo8(vars) ;  14   [c=4 l=2]  *movhi/4
   ldi r31,hi8(vars)
   subi r30,lo8(-(4));  15   [c=8 l=6]  *movhi/2
   sbci r31,hi8(-(4))
   ld r20,Z+
   ld r21,Z
   subi r30,lo8((4+1))
   sbci r31,hi8((4+1))
   subi r20,-1 ;  16   [c=4 l=2]  *addhi3_clobber/1
   sbci r21,-1
   subi r30,lo8(-(4+1));  17   [c=4 l=4]  *movhi/3
   sbci r31,hi8(-(4+1))
   st Z,r21
   st -Z,r20

where the code could be:

   ldi r30,lo8(vars+4);  28   [c=4 l=2]  *movhi/4
   ldi r31,hi8(vars+4)
   ld r20,Z+  ;  17   [c=8 l=2]  *movhi/2
   ld r21,Z+
   subi r20,-1;  19   [c=4 l=2]  *addhi3_clobber/1
   sbci r21,-1
   st -Z,r21  ;  30   [c=4 l=2]  *movhi/3
   st -Z,r20

[Bug target/114100] [avr] Inefficient indirect addressing on Reduced Tiny

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Priority|P3  |P4
   Keywords||missed-optimization
 Target||avr

[Bug libstdc++/114101] New: FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

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

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

Bug ID: 114101
   Summary: FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc
 -std=gnu++17 (test for excess errors)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc  -std=gnu++17 (test for
excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:48:
error: 'acosl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:50:
error: 'asinl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:52:
error: 'atanl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:54:
error: 'atan2l' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:55:
error: 'ceilf' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:56:
error: 'ceill' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:58:
error: 'cosl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:60:
error: 'coshl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:62:
error: 'expl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:64:
error: 'fabsl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:65:
error: 'floorf' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:66:
error: 'floorl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:68:
error: 'fmodl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:69:
error: 'frexpf' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:70:
error: 'frexpl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:71:
error: 'ldexpf' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:72:
error: 'ldexpl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:74:
error: 'logl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:76:
error: 'log10l' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:77:
error: 'modff' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:78:
error: 'modfl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:80:
error: 'powl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:82:
error: 'sinl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:84:
error: 'sinhl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:86:
error: 'sqrtl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:88:
error: 'tanl' has not been declared in 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:90:
error: 'tanhl' has not been declared in 'std'

libstdc++-v3 provides stubs for the above but they are not declared
in .  Further, the "using" directives for the above are guarded:

#ifdef _GLIBCXX_HAVE_ACOSF
  using ::acosf;
#endif

So if the target doesn't declare these or if a configure check is missing,
these functions won't be declared or in 'std'.

Similar fails:
FAIL: 26_numerics/headers/cmath

[Bug fortran/114102] New: ice in matching_typebound_op, at fortran/interface.cc:4564

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114102
   Summary: ice in matching_typebound_op, at
fortran/interface.cc:4564
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57528&action=edit
F90 source code

>From the flang testsuite at

https://github.com/llvm/llvm-project/tree/main/flang/test

source code file ./Semantics/modfile35.f90, does this with recent 
gcc trunk:

test $ ~/gcc/results/bin/gfortran -c -w ./Semantics/modfile35.f90
f951: internal compiler error: in matching_typebound_op, at
fortran/interface.cc:4564
0x7768f6 matching_typebound_op(gfc_expr**, gfc_actual_arglist*,
gfc_intrinsic_op, char const*, char const**)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/interface.cc:4564

This bug has existed since sometime before 20240126.

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

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

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

--- Comment #1 from John David Anglin  ---
Created attachment 57529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57529&action=edit
Preliminary patch.

Still need to review float and long double stubs to make sure they are complete
for libgm2.  Tested so far on hppa64-hp-hpux.

configure, config.h.in and src/c++98/Makefile.in need regeneration with
autoconf, autoheader and automake, respectively.

[Bug libstdc++/114103] New: FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)

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

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

Bug ID: 114103
   Summary: FAIL: 29_atomics/atomic/lock_free_aliases.cc
-std=gnu++20 (test for excess errors)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-14/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-14/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc
-std=gnu++20 -D__GLIBCXX__= -fdiagnostics-plain-output -S -o
lock_free_aliases.s
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:33:
error: static assertion failed
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:34:
error: static assertion failed
compiler exited with status 1
FAIL: 29_atomics/atomic/lock_free_aliases.cc  -std=gnu++20 (test for excess
errors)
Excess errors:
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:33:
error: static assertion failed
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:34:
error: static assertion failed

[Bug tree-optimization/114095] ICE: in build2, at tree.cc:5097

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 108954

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

[Bug c/108954] ICE with invalid gimple source

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||iamanonymous.cs at gmail dot 
com

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

[Bug ada/104342] [14 regression] ICE with -gnata -fcallgraph-info=su

[simon at pushface dot org via Gcc-bugs]

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

simon at pushface dot org changed:

   What|Removed |Added

Summary|ICE with -gnata |[14 regression] ICE with
   |-fcallgraph-info=su |-gnata -fcallgraph-info=su

--- Comment #2 from simon at pushface dot org ---
This doesn’t occur in 12.2.0 or 13.1.0, but has reappeared in gcc version
14.0.1 20240218 (experimental) (GCC).

New reproducer uploaded (same files, new content).

gcc -c -gnata -fcallgraph-info=su stm32-spi-dma.adb
  targetname: "+===GNAT BUG
DETECTED==+
| 14.0.1 20240218 (experimental) (x86_64-apple-darwin21) Assert_Failure
exp_cg.adb:484|
| No source file position information available|
| Compiling stm32-spi-dma.adb  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

stm32-spi-dma.adb
stm32-spi-dma.ads
stm32-spi.ads
stm32.ads
hal.ads
stm32_svd.ads
stm32_svd-spi.ads
hal-spi.ads
stm32-dma.ads
stm32_svd-dma.ads
stm32-dma-interrupts.ads

compilation abandoned
gnatmake: "stm32-spi-dma.adb" compilation error

[Bug ada/104342] [14 regression] ICE with -gnata -fcallgraph-info=su

[simon at pushface dot org via Gcc-bugs]

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

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #52327|0   |1
is obsolete||

--- Comment #3 from simon at pushface dot org ---
Created attachment 57530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57530&action=edit
Reproducer (14.0.1)

[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #25 from Zdenek Sojka  ---
Created attachment 57531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57531&action=edit
combined testcase ICEing at different places with -O -mavx512f

This ICEs on,
$ x86_64-pc-linux-gnu-gcc -O -mavx512f testcase.c
...
xxx.c:2:6: internal compiler error: in handle_operand_addr, at
gimple-lower-bitint.cc:2108

xxx.c:3:12: internal compiler error: in handle_cast, at
gimple-lower-bitint.cc:1559

testcase.c:4:1: internal compiler error: in lower_stmt, at
gimple-lower-bitint.cc:5501

depending on which of the functions is compiled

[Bug c++/98520] nodiscard not diagnosed in comma operator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2021-01-07 00:00:00 |2024-2-25

--- Comment #1 from Jonathan Wakely  ---
Are you sure this is related to the comma operator? We also fail to diagnose:

struct [[nodiscard]] S{};

void _()
{
S{};
}


I think this is just a dup of PR 85973

[Bug ada/104342] ICE with -gnata -fcallgraph-info=su

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[14 regression] ICE with|ICE with -gnata
   |-gnata -fcallgraph-info=su  |-fcallgraph-info=su

--- Comment #4 from Eric Botcazou  ---
Release branches simply do not have assertions enabled.

[Bug target/114100] [avr] Inefficient indirect addressing on Reduced Tiny

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-25

--- Comment #1 from Andrew Pinski  ---
Confirmed. One way of improving this is to slightly increase the cost of the
indirect addressing with offset for these cores.

[Bug c++/114104] New: nodiscard not diagnosed on synthesized operator!=

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

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

Bug ID: 114104
   Summary: nodiscard not diagnosed on synthesized operator!=
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We fail to diagnose this C++20 code:

[[nodiscard]] bool operator==(X, int) { return true; }

int main() {
  X x, y;
  x != 0;
}

For x == 0 and 0 == x the nodiscard attribute works as expected, but not for x
!= 0

[Bug c++/114104] nodiscard not diagnosed on synthesized operator!=

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-25

--- Comment #1 from Jonathan Wakely  ---
This bug means we fail to diagnose this example (courtesy of Stephan T.
Lavavej):

#include 
#include 
using namespace std;

int main() {
vector x{10, 20, 30};
vector y{11, 22, 33, 44};

for (auto i = x.begin(), j = y.begin(); i != x.end(), j != y.end(); ++i,
++j) {
println("{} {}", *i, *j);
}
}

The loop condition should use && between the two expressions but it uses a
comma instead. Even though operator== for vector::iterator is marked nodiscard,
we fail to warn that i != x.end() is discarded.

[Bug fortran/114012] overloaded unary operator called twice

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following patch fixes the redundant procedure invocation:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 118dfd7c9b2..581b3786dea 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6691,6 +6692,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
{
  tree efield;

+ /* Evaluate arguments just once.  */
+ if (e->expr_type != EXPR_VARIABLE)
+   parmse.expr = save_expr (parmse.expr);
+
  /* Set the _data field.  */
  tmp = gfc_class_data_get (var);
  efield = fold_convert (TREE_TYPE (tmp),

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2024-02-25 2:17 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101
>
> Jonathan Wakely  changed:
>
> What|Removed |Added
> 
> See Also||https://gcc.gnu.org/bugzill
> ||a/show_bug.cgi?id=79700
The patch I posted allows HP-UX targets to make use of the above change.  I
defined
_GLIBCXX_USE_C99_MATH_FUNCS and _GLIBCXX_USE_BUILTIN_FMAF in
config/os/hpux/os_defines.h:

+// Import C99 functions in  in  in namespace std in C++11.
+// Missing functions are handled by stubs.  The fma, nexttoward, scalbln
+// and tgamma are missing in HP-UX 11.  Many float variants are supported.
+#define _GLIBCXX_USE_C99_MATH_FUNCS 1
+#define _GLIBCXX_USE_C99_MATH_TR1 1

Had to add double stubs for fma, nexttoward, scalbln and tgamma to complete the
set
of required functions.

Currently, _GLIBCXX_USE_C99_MATH_FUNCS and _GLIBCXX_USE_C99_MATH_TR1 are
only enabled when configure detects the full set of C99 functions.

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2024-02-25 2:21 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101
>
> Jonathan Wakely  changed:
>
> What|Removed |Added
> 
> See Also||https://gcc.gnu.org/bugzill
> ||a/show_bug.cgi?id=86553
If a target has inconsistent declarations for any standard C99 functions, they
should be fixed
using a fixincludes hack.

Originally, I wrote a patch to add declarations for missing C99 functions on
hpux to math.h.
They were declared when __cplusplus was defined.  But then I realized they
would be
better in cmath as then all targets could potentially benefit.

They could be guarded by something like _GLIBCXX_NEED_C99_DECLARATIONS.  It
could
go in os_defines.h.  On hpux11, the configure checks are sufficient.  I think
they are also
sufficient on linux (test in progress).

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2024-02-25 2:21 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101
>
> Jonathan Wakely  changed:
>
> What|Removed |Added
> 
> See Also||https://gcc.gnu.org/bugzill
> ||a/show_bug.cgi?id=111639
I haven't tested my hpux changes to crossconfig.m4.  I just added new defines
for some
float math functions that were missing from the list and slightly reorganized
the list into
something slightly closer to alphabetical order.

The  for HP-UX doesn't do this sort of thing:

extern double acos(double __x) __ATTR_CONST__;
#define acosf    acos        /**< The alias for acos().    */

Technically, avr doesn't have a proper acosf.  If float and double differ, acos
won't handle exceptional
values correctly for acosf.  So, I think the AC_DEFINEs for the float variants
should be removed or
conditioned on some libc version.

In my package, configure checks were added so that we now check all the C99
float variants.  As a result,
we now use the libc version instead of the stub version for some functions.

[Bug fortran/114012] overloaded unary operator called twice

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-February/060267.html

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

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

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

--- Comment #5 from John David Anglin  ---
Test results without patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/808830.html
=== libstdc++ tests ===


Running target unix
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test
FAIL: 20_util/from_chars/4.cc  -std=gnu++17 execution test
FAIL: 20_util/from_chars/8.cc  -std=gnu++23 execution test
FAIL: 20_util/from_chars/8.cc  -std=gnu++26 execution test
FAIL: 20_util/to_chars/float128_c++23.cc  -std=gnu++23 execution test
FAIL: 20_util/to_chars/float128_c++23.cc  -std=gnu++26 execution test
FAIL: 26_numerics/headers/cmath/constexpr_std_c++23.cc  -std=gnu++23 (test for
excess errors)
FAIL: 26_numerics/headers/cmath/constexpr_std_c++23.cc  -std=gnu++26 (test for
excess errors)
FAIL: 26_numerics/headers/cmath/equivalent_functions.cc  -std=gnu++17 (test for
excess errors)
UNRESOLVED: 26_numerics/headers/cmath/equivalent_functions.cc  -std=gnu++17
compilation failed to produce executable
FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc  -std=gnu++17 (test for
excess errors)
FAIL: 26_numerics/headers/cmath/functions_std_c++23.cc  -std=gnu++23 (test for
excess errors)
FAIL: 26_numerics/headers/cmath/functions_std_c++23.cc  -std=gnu++26 (test for
excess errors)
FAIL: 26_numerics/headers/cmath/nextafter_c++23.cc  -std=gnu++23 (test for
excess errors)
UNRESOLVED: 26_numerics/headers/cmath/nextafter_c++23.cc  -std=gnu++23
compilation failed to produce executable
FAIL: 26_numerics/headers/cmath/nextafter_c++23.cc  -std=gnu++26 (test for
excess errors)
UNRESOLVED: 26_numerics/headers/cmath/nextafter_c++23.cc  -std=gnu++26
compilation failed to produce executable
FAIL: 27_io/basic_ofstream/open/char/noreplace.cc  -std=gnu++17 execution test
FAIL: 27_io/basic_ofstream/open/wchar_t/noreplace.cc  -std=gnu++17 execution
test
FAIL: 29_atomics/atomic/lock_free_aliases.cc  -std=gnu++20 (test for excess
errors)
FAIL: 29_atomics/atomic/lock_free_aliases.cc  -std=gnu++26 (test for excess
errors)
FAIL: std/text_encoding/cons.cc  -std=gnu++26 (test for excess errors)
UNRESOLVED: std/text_encoding/cons.cc  -std=gnu++26 compilation failed to
produce executable
FAIL: std/text_encoding/requirements.cc  -std=gnu++26 (test for excess errors)

=== libstdc++ Summary ===

# of expected passes16365
# of unexpected failures27
# of expected failures  126
# of unresolved testcases   4
# of unsupported tests  1109

Compiler version: 14.0.1 20240223 (experimental) [remotes/origin/trunk
r14-9158-gfdf9df9d558] (GCC) 
Platform: hppa64-hp-hpux11.11
configure flags: --without-zstd --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/opt/gnu64/gcc/gcc-14 --disable-nls --without-libiconv-prefix
--without-libintl-prefix --enable-threads=posix --with-gmp=/opt/gnu64/gcc/gmp
--with-isl=/opt/gnu64/gcc/gmp --with-stage1-ldflags='-Wl,+b
-Wl,/opt/gnu64/gcc/gcc-12/lib:/opt/gnu64/lib' --with-boot-ldflags=
--enable-checking=release --enable-libgomp --enable-libstdcxx CC=gcc CXX=g++
--disable-lto --enable-languages=c,c++


Test results with patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/808771.html

=== libstdc++ tests ===


Running target unix
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test
FAIL: 20_util/from_chars/4.cc  -std=gnu++17 execution test
FAIL: 20_util/from_chars/8.cc  -std=gnu++23 execution test
FAIL: 20_util/from_chars/8.cc  -std=gnu++26 execution test
FAIL: 20_util/to_chars/float128_c++23.cc  -std=gnu++23 execution test
FAIL: 20_util/to_chars/float128_c++23.cc  -std=gnu++26 execution test
FAIL: 20_util/to_chars/long_double.cc  -std=gnu++17 execution test
FAIL: 27_io/basic_ofstream/open/char/noreplace.cc  -std=gnu++17 execution test
FAIL: 27_io/basic_ofstream/open/wchar_t/noreplace.cc  -std=gnu++17 execution
test
FAIL: 29_atomics/ato

[Bug c++/114105] New: --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

[markmigm at gmail dot com via Gcc-bugs]

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

Bug ID: 114105
   Summary: --disable-bootstrap based builds vs libcc1 and gcc/jit
use of gcc/system.h poisoning policy
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markmigm at gmail dot com
  Target Milestone: ---

[ Note: not limited to gcc14 : FreeBSD ports lang/gcc12 (& -devel) and
lang/gcc13
(& -devel) had to be patched for libcc1 , not just lang/gcc14-devel ]

Attempting --disable-bootstrap builds of various gcc versions under clang &
libc++
gets errors from, appearently, assuming that the sources and toolchain will
follow
the gcc internal poisoning principles. The results are errors like:

In file included from
/wrkdirs/share/dim/ports/lang/gcc13/work/gcc-13.2.0/libcc1/libcc1plugin.cc:72:
In file included from /usr/include/c++/v1/vector:321:
In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
/usr/include/c++/v1/locale:289:36: error: attempt to use a poisoned identifier
  289 | __status = (unsigned char*)malloc(__nkw);
  |^
/usr/include/c++/v1/locale:1584:28: error: attempt to use a poisoned identifier
 1584 | __ob =
(char_type*)malloc(2*static_cast(__nc)*sizeof(char_type));
  |^

(FreeBSD patches lang/gcc12* and lang/gcc13* and lang/gcc14-devel for the
libcc1
issues involving poisoning identifiers.)

and:

In file included from
/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240218/gcc/jit/dummy-frontend.cc:23:
In file included from
/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240218/gcc/jit/jit-playback.h:26:
In file included from /usr/include/c++/v1/vector:321:
In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
/usr/include/c++/v1/locale:289:36: error: attempt to use a poisoned identifier
  289 | __status = (unsigned char*)malloc(__nkw);
  |^

(FreeBSD is still working on patching lang/gcc14-devel for its gcc/jit issues
involving poisoning identifiers. It is possible that after that is done
more issues will be exposed.)

Part of the reason FreeBSD puts effort into making --disable-bootstrap work,
despite it not being the default in the ports, is to allow builds that stay
in the bounds of the free version of, for example, cirrus.

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

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

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

--- Comment #1 from Andrew Pinski  ---
`#define INCLUDE_VECTOR` should be done for jit ...
And maybe libcc1 too.

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

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

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

--- Comment #2 from Andrew Pinski  ---
Something like:
```
diff --git a/gcc/jit/dummy-frontend.cc b/gcc/jit/dummy-frontend.cc
index dbeeacd17a8..f57fb805a5f 100644
--- a/gcc/jit/dummy-frontend.cc
+++ b/gcc/jit/dummy-frontend.cc
@@ -18,6 +18,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */

 #include "config.h"
+#define INCLUDE_VECTOR
 #include "system.h"
 #include "coretypes.h"
 #include "jit-playback.h"
```


>Part of the reason FreeBSD puts effort into making --disable-bootstrap work
This should not be done unless you are building with GCC itself. The reason is
only the C, C++ front-ends are supposed to be able to compile with a (non-GCC)
C++11 compiler. So FreeBSD is doing it wrong anyways.

[Bug c++/114104] nodiscard not diagnosed on synthesized operator!=

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk  ---
Isn't this behaving as designed as far as nodiscard goes? x != 0 is defined to
be evaluated as !(x == 0) per [over.match.oper]p9, where the result of x == 0
is not a discarded-value expression, and therefore nodiscard suggests no
warning for it.

That said, there is a missing general warning in GCC about the built-in !
operator being discarded:

  bool f();
  int main() {
!f(); // clang: warning: expression result unused [-Wunused-value]
  // gcc: no warning
  }

For similar useless operations, such as f() ^ true;, GCC emits a similar
warning "warning: value computed is not used [-Wunused-value]". Presumably, if
that warning were implemented in GCC for ! as well, it should also fire for
your original x != 0 test?

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

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

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

--- Comment #3 from Sam James  ---
I have a patch which includes those extra hunks (in addition to the PR111632
one), but didn't have a chance yet to look at iain's build failure on darwin.

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

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

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

--- Comment #4 from Sam James  ---
(In reply to Sam James from comment #3)
> I have a patch which includes those extra hunks (in addition to the PR111632
> one), but didn't have a chance yet to look at iain's build failure on darwin.

(someone should feel free to do the easier bits though ofc, these things tend
to accumulate anyway)

[Bug ada/104342] ICE with -gnata -fcallgraph-info=su

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #5 from simon at pushface dot org ---
That thought occurred to me, but does that mean that if this code is compiled
with a release branch Bad Things will happen? (I guess the code would probably
have to get executed for that to occur)

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #6 from dave.anglin at bell dot net ---
The  for HP-UX doesn't do this sort of thing:
> extern double acos(double __x) __ATTR_CONST__;
> #define acosf    acos        /**< The alias for acos().    */
>
> Technically, avr doesn't have a proper acosf.  If float and double differ, 
> acos
> won't handle exceptional
> values correctly for acosf.  So, I think the AC_DEFINEs for the float variants
> should be removed or
> conditioned on some libc version.
With my proposed patch, the avr defines for the float variants in
crossconfig.m4 can be removed
and the code will fallback to using the float stubs.

[Bug ada/104342] ICE with -gnata -fcallgraph-info=su

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

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

--- Comment #6 from Eric Botcazou  ---
> That thought occurred to me, but does that mean that if this code is
> compiled with a release branch Bad Things will happen? (I guess the code
> would probably have to get executed for that to occur)

It's related to -fcallgraph-info=su and this doesn't affect the generated code.

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2024-02-25 4:04 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101
>
> --- Comment #6 from dave.anglin at bell dot net ---
> The  for HP-UX doesn't do this sort of thing:
>> extern double acos(double __x) __ATTR_CONST__;
>> #define acosf    acos        /**< The alias for acos().    */
>>
>> Technically, avr doesn't have a proper acosf.  If float and double differ, 
>> acos
>> won't handle exceptional
>> values correctly for acosf.  So, I think the AC_DEFINEs for the float 
>> variants
>> should be removed or
>> conditioned on some libc version.
> With my proposed patch, the avr defines for the float variants in
> crossconfig.m4 can be removed
> and the code will fallback to using the float stubs.
But I need to move the undefs for the C99 math funcs forward before the
declarations.

[Bug c++/114106] New: Wrong result of decltype

[egor.pugin at gmail dot com via Gcc-bugs]

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

Bug ID: 114106
   Summary: Wrong result of decltype
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor.pugin at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/ojbzGYqbW

MSVC works.

template 
struct Type {};

template 
struct ImplT : Ts...
{ using Ts::operator()...; };

template 
using ImplA = ImplT){})...>;

template 
constexpr bool allUnique{
([]( ImplA x, Type t )
{ x.operator()(t); return true;} && ...)}; // <- error is here

//static_assert(allUnique); // also does not work

: In lambda function:
:16:18: error: request for member 'operator()' in 'x', which is of
non-class type 'int'
   16 | { x.operator()(t); return true;} && ...)};
  |  ^

[Bug c++/114106] Wrong result of decltype

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda
 Blocks||107430

--- Comment #1 from Andrew Pinski  ---
>decltype([](Type){})

Yes lambdas inside a decltype is known to cause issues.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
[Bug 107430] [meta-bug] lambda in decltype

[Bug middle-end/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

--- Comment #3 from Andrew Pinski  ---
Note the reduced testcase is undefined code.
c::j is not initialized when c::k() is called.

[Bug libfortran/105456] Child I/O does not propage iostat

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r14-9168-g3f58f96a4e8255e222953f9856bcd6c25f7b33cd
Author: Jerry DeLisle 
Date:   Sun Feb 25 14:50:07 2024 -0800

libgfortran: Propagate user defined iostat and iomsg.

PR libfortran/105456

libgfortran/ChangeLog:

* io/list_read.c (list_formatted_read_scalar): Add checks
for the case where a user defines their own error codes
and error messages and generate the runtime error.
* io/transfer.c (st_read_done): Whitespace.

gcc/testsuite/ChangeLog:

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

[Bug middle-end/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 57532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57532&action=edit
Reduced further but still has undefined code in it

[Bug c++/114104] nodiscard not diagnosed on synthesized operator!=

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

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

--- Comment #3 from Jonathan Wakely  ---
I don't care whether GCC synthesizes an operator!= that inherits the nodiscard
attribute, or it generates a discarded bool using the built-in !, but there
needs to be a warning either way.

Currently a handwritten operator!= with the attribute gives better results than
letting the compiler do it, and that should not be the case.

[Bug middle-end/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #57527|0   |1
is obsolete||
  Attachment #57532|0   |1
is obsolete||

--- Comment #5 from Andrew Pinski  ---
Created attachment 57533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57533&action=edit
Reduced all the way without undefined code in it

This ICEs on aarch64 with just -O3.

[Bug tree-optimization/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-25
   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1
   Target Milestone|--- |14.0

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

[Bug tree-optimization/114107] New: poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

[nathanael.schaeffer at gmail dot com via Gcc-bugs]

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

Bug ID: 114107
   Summary: poor vectorization at -O3 when dealing with arrays of
different multiplicity, good with -O2
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.schaeffer at gmail dot com
  Target Milestone: ---

A simple loop multiplying two arrays, with different multiplicity fails to
vectorize efficiently with -O3.
Target is AVX x86_64.
The loop is the following, where 4 consecutive values in data are multiplied by
the same factor :

for (int i=0; ihttps://godbolt.org/z/fWj34bbhq

[Bug tree-optimization/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #7 from Andrew Pinski  ---
Note the difference between noreturn vs __builtin_unreachable BB is the
noreturn bb has:
  # _21 = PHI <_2(4)>
  m = _21;

But the one with unreachable does not.
It feels like that difference is causing the issue here. Replacing unreachable
with another noreturn function removes the ICE even.

I am 99% sure this is related to the early out vect changes too.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

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

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

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

`-O3 -march=skylake`

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux

--- Comment #2 from Andrew Pinski  ---
I am not 100% sure that is always better.

What is happening is GCC is vectorizing even the outer loop.

It is easier to understand via aarch64 asm too:
.L4:
ldr q27, [x3], 16
ld4 {v28.2d - v31.2d}, [x4]
fmulv24.2d, v27.2d, v28.2d
fmulv25.2d, v27.2d, v29.2d
fmulv26.2d, v27.2d, v30.2d
fmulv27.2d, v27.2d, v31.2d
st4 {v24.2d - v27.2d}, [x4], 64
cmp x3, x5
bne .L4

Have you benchmarked both?

If anything this is a cost model issue.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

[nathanael.schaeffer at gmail dot com via Gcc-bugs]

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

--- Comment #3 from N Schaeffer  ---
I have not benchmarked.
For 4 vmulpd doing the actual work, there are more than 40 permute/mov
instructions, among which 24 vpermd instructions which have a 3 cycle latency.
That is 6 vpermd per vmulpd.
There is no way this can be faster than vbroadcastsd. I would bet it is 4 to 10
times slower than the vbroadcastsd loop.
If you want, I can benchmark it tomorrow.

If this is a cost model problem, it is a bad one. Even ignoring the decoding of
all these instructions, how can adding 6 vpermd to each vmulpd be faster?
I would rather think (hope?) the optimizer does not consider the vbroadcastsd
solution at all.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

[nathanael.schaeffer at gmail dot com via Gcc-bugs]

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

--- Comment #4 from N Schaeffer  ---
... and thank you for your quick reply!

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to N Schaeffer from comment #3)
> If this is a cost model problem, it is a bad one.

It is almost definitely a cost model in the x86_64 backend issue. Because I
tried on aarch64 with -march=armv9-a+sve and then we get only the vectorization
of the inner loop for both -O2 and -O3:
```
.L3:
ldp q29, q30, [x0]
ld1r{v31.2d}, [x1], 8
fmulv30.2d, v30.2d, v31.2d
fmulv29.2d, v29.2d, v31.2d
stp q29, q30, [x0], 32
cmp x2, x1
bne .L3
```

With the default generic armv8-a cost model we get the ld4 there and
vectorizing the outer loop.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

[nathanael.schaeffer at gmail dot com via Gcc-bugs]

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

--- Comment #6 from N Schaeffer  ---
indeed, aarch64 assembly looks very good.

[Bug tree-optimization/114096] ICE: in lower_stmt, at gimple-lower-bitint.cc:5533 on vector -> _BitInt() cast

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 114073.

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

[Bug middle-end/114073] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5530

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug middle-end/114108] New: [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression)

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

27;Gentoo Hardened
14.0. p, commit e54a7fbca63053b5753fd9ba543c27ef392d3084'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240225 (experimental)
5c45dc1b97890afe7a977cea8069214ccdc42384 (Gentoo Hardened 14.0. p, commit
e54a7fbca63053b5753fd9ba543c27ef392d3084)
```

[Bug middle-end/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression)

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

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

--- Comment #1 from Sam James  ---
I can reproduce it with `g++ -c arithm.dispatch.cpp.ii -O3
-mcpu=neoverse-n1+crc+crypto+ssbs`. I can't try to narrow it down or reduce it
right now though.

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
 Target||aarch64
  Component|middle-end  |tree-optimization
   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

[markmigm at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mark Millard  ---
(In reply to Andrew Pinski from comment #2)
> . . .
> >Part of the reason FreeBSD puts effort into making --disable-bootstrap work
> This should not be done unless you are building with GCC itself. The reason
> is only the C, C++ front-ends are supposed to be able to compile with a
> (non-GCC) C++11 compiler. So FreeBSD is doing it wrong anyways.

Thanks for that wording. I did not get that relationship from the wording
in the standard documentation that talks about --disable-bootstrap . It
might be good if that documentation did also have such wording.

I'll note that the FreeBSD lang/gcc* ports do not normally use
--disable-bootstrap .

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression)

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

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

--- Comment #2 from Andrew Pinski  ---
Just -O3 is enough.

Reducing

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Mark Millard from comment #5)
> (In reply to Andrew Pinski from comment #2)
> > . . .
> > >Part of the reason FreeBSD puts effort into making --disable-bootstrap work
> > This should not be done unless you are building with GCC itself. The reason
> > is only the C, C++ front-ends are supposed to be able to compile with a
> > (non-GCC) C++11 compiler. So FreeBSD is doing it wrong anyways.
> 
> Thanks for that wording. I did not get that relationship from the wording
> in the standard documentation that talks about --disable-bootstrap . It
> might be good if that documentation did also have such wording.

It is documented here:
https://gcc.gnu.org/install/prerequisites.html

"To build all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed, you need to start with an existing GCC
binary (version 4.8.3 or later) because source code for language frontends
other than C might use GCC extensions.
"

Though it should say other than `C and C++` but that is a minor thing.

[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy

[markmigm at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Mark Millard  ---
(In reply to Andrew Pinski from comment #6)
> . . .
> It is documented here:
> https://gcc.gnu.org/install/prerequisites.html
> 
> "To build all languages in a cross-compiler or other configuration where
> 3-stage bootstrap is not performed, you need to start with an existing GCC
> binary (version 4.8.3 or later) because source code for language frontends
> other than C might use GCC extensions.
> "
> 
> Though it should say other than `C and C++` but that is a minor thing.

Ahh, not text I can find by looking for "--disable-bootstrap" or
"disable-bootstrap" and not explicit in terms of any command line
options syntax in general for the overall issue. That probably
explains why I did not run into it.

Again: Thanks. (I do like the wording about the front-end vs. not
distinctions for --disable-bootstrap .)

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #7 from Hongtao Liu  ---
perm_cost is very low in x86 backend, and it maybe ok for 128-bit vectors,
pshufb/shufps are avaible for most cases.
But for 256/512-bit vectors, when the permuation is cross-lane, the cost could
be higher. One solution is increase perm_cost when vector size is more than 128
since vperm is most likely used instead of vblend/vpblend/vpshuf/vshuf.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

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

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

--- Comment #8 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #7)
> perm_cost is very low in x86 backend, and it maybe ok for 128-bit vectors,
> pshufb/shufps are avaible for most cases.
> But for 256/512-bit vectors, when the permuation is cross-lane, the cost
> could be higher. One solution is increase perm_cost when vector size is more
> than 128 since vperm is most likely used instead of
> vblend/vpblend/vpshuf/vshuf.

Furthermore, if we can get indices in the backend when calculating vec_perm
cost, we can check if the permutation is cross-lane or not, and set cost more
accurately for 256/512-bit vector permutation.

[Bug target/114098] _tile_loadconfig doesn't work

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

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

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

https://gcc.gnu.org/g:4972f97a265c574d51e20373ddefd66576051e5c

commit r14-9171-g4972f97a265c574d51e20373ddefd66576051e5c
Author: H.J. Lu 
Date:   Sun Feb 25 10:21:04 2024 -0800

x86: Properly implement AMX-TILE load/store intrinsics

ldtilecfg and sttilecfg take a 512-byte memory block.  With
_tile_loadconfig implemented as

extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_tile_loadconfig (const void *__config)
{
  __asm__ volatile ("ldtilecfg\t%X0" :: "m" (*((const void **)__config)));
}

GCC sees:

(parallel [
  (asm_operands/v ("ldtilecfg   %X0") ("") 0
   [(mem/f/c:DI (plus:DI (reg/f:DI 77 virtual-stack-vars)
 (const_int -64 [0xffc0])) [1
MEM[(const void * *)&tile_data]+0 S8 A128])]
   [(asm_input:DI ("m"))]
   (clobber (reg:CC 17 flags))])

and the memory operand size is 1 byte.  As the result, the rest of 511
bytes is ignored by GCC.  Implement ldtilecfg and sttilecfg intrinsics
with a pointer to XImode to honor the 512-byte memory block.

gcc/ChangeLog:

PR target/114098
* config/i386/amxtileintrin.h (_tile_loadconfig): Use
__builtin_ia32_ldtilecfg.
(_tile_storeconfig): Use __builtin_ia32_sttilecfg.
* config/i386/i386-builtin.def (BDESC): Add
__builtin_ia32_ldtilecfg and __builtin_ia32_sttilecfg.
* config/i386/i386-expand.cc (ix86_expand_builtin): Handle
IX86_BUILTIN_LDTILECFG and IX86_BUILTIN_STTILECFG.
* config/i386/i386.md (ldtilecfg): New pattern.
(sttilecfg): Likewise.

gcc/testsuite/ChangeLog:

PR target/114098
* gcc.target/i386/amxtile-4.c: New test.

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression)

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

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

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

Just needs -O3 as mentioned.

[Bug tree-optimization/114108] [14 regression] ICE when building opencv-4.8.1 (error: type mismatch in binary expression)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
I suspect r14-1832-g710b8dec61a73c as GCC 13 didn't use ABD but the trunk is
now using it and there seems to be missing a VCE from `vector(16) unsigned
char` to `vector(16) signed char` before the MIN_EXPR too.

Confirmed.

[Bug target/114094] Assembler messages: Error: junk `nop' after expression with -fprofile -fPIE -mno-direct-extern-access -masm=intel

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

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

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

https://gcc.gnu.org/g:6987f16742bd4fc6bb8118b9efde52fb9169b327

commit r14-9172-g6987f16742bd4fc6bb8118b9efde52fb9169b327
Author: Jakub Jelinek 
Date:   Mon Feb 26 07:30:05 2024 +0100

i386: Fix up x86_function_profiler -masm=intel support [PR114094]

In my r14-8214 changes I apparently forgot one \n at the end of an
instruction.
The corresponding AT&T line looks like:
"1:\tcall\t*%s@GOTPCREL(%%rip)\n"
but the Intel variant was
"1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]"

Fixed thusly.

2024-02-26  Jakub Jelinek  

PR target/114094
* config/i386/i386.cc (x86_function_profiler): Add missing new-line
to printed instruction.

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

[Bug target/114094] Assembler messages: Error: junk `nop' after expression with -fprofile -fPIE -mno-direct-extern-access -masm=intel

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/114099] [14 regression] ICE in find_uses_to_rename_use when building darktable-4.6.1

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

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

--- Comment #8 from Tamar Christina  ---
Created attachment 57537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57537&action=edit
uses.patch

new code seems sensitive to visitation order as get_virtual_phi returns NULL
for blocks which don't define or use a virtual PHI.

testing patch.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

[nathanael.schaeffer at gmail dot com via Gcc-bugs]

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

--- Comment #9 from N Schaeffer  ---
In addition, optimizing for size with -Os leads to a non-vectorized double-loop
(51 bytes) while the vectorized loop with vbroadcastsd (produced by clang -Os)
leads to 40 bytes.
It is thus also a missed optimization for -Os.

[Bug middle-end/114070] [12/13/14 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model

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

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

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

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

commit r14-9173-gaf66ad89e8169f44db723813662917cf4cbb78fc
Author: Richard Biener 
Date:   Fri Feb 23 16:06:05 2024 +0100

middle-end/114070 - folding breaking VEC_COND expansion

The following properly guards the simplifications that move
operations into VEC_CONDs, in particular when that changes the
type constraints on this operation.

This needed a genmatch fix which was recording spurious implicit fors
when tcc_comparison is used in a C expression.

PR middle-end/114070
* genmatch.cc (parser::parse_c_expr): Do not record operand
lists but only mark operators used.
* match.pd ((c ? a : b) op (c ? d : e)  -->  c ? (a op d) : (b op
e)):
Properly guard the case of tcc_comparison changing the VEC_COND
value operand type.

* gcc.dg/torture/pr114070.c: New testcase.

[Bug middle-end/114070] [12/13 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[12/13/14 regression] ICE   |[12/13 regression] ICE when
   |when building git-2.43.2|building git-2.43.2 with
   |with -mcpu=niagara4 |-mcpu=niagara4
   |-fno-vect-cost-model|-fno-vect-cost-model
  Known to work||14.0

--- Comment #9 from Richard Biener  ---
Should be fixed on trunk.

[Bug target/114107] poor vectorization at -O3 when dealing with arrays of different multiplicity, good with -O2

[nathanael.schaeffer at gmail dot com via Gcc-bugs]

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

--- Comment #10 from N Schaeffer  ---
intrestingly (and maybe surprisingly) I can get gcc to produce nearly optimal
code using vbroadcastsd with the following options:

-O2 -march=skylake -ftree-vectorize