[Bug tree-optimization/110386] [11/12 Regression] ICE with ABSU in backprop

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

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

commit r12-10434-gf5c7306d7f039e5c74c5e82cf06610f0ae07a0e8
Author: Andrew Pinski 
Date:   Sat Sep 23 21:53:09 2023 -0700

Fix PR 110386: backprop vs ABSU_EXPR

The issue here is that when backprop tries to go
and strip sign ops, it skips over ABSU_EXPR but
ABSU_EXPR not only does an ABS, it also changes the
type to unsigned.
Since strip_sign_op_1 is only supposed to strip off
sign changing operands and not ones that change types,
removing ABSU_EXPR here is correct. We don't handle
nop conversions so this does cause any missed optimizations either.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/110386

gcc/ChangeLog:

* gimple-ssa-backprop.cc (strip_sign_op_1): Remove ABSU_EXPR.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr110386-1.c: New test.
* gcc.c-torture/compile/pr110386-2.c: New test.

(cherry picked from commit 2bbac12ea7bd8a3eef5382e1b13f6019df4ec03f)

[Bug tree-optimization/110386] [11/12 Regression] ICE with ABSU in backprop

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Andrew Pinski
:

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

commit r11-11422-gdbfc2d075f10149bd94e16c1210ffe4bac7e60c3
Author: Andrew Pinski 
Date:   Sat Sep 23 21:53:09 2023 -0700

Fix PR 110386: backprop vs ABSU_EXPR

The issue here is that when backprop tries to go
and strip sign ops, it skips over ABSU_EXPR but
ABSU_EXPR not only does an ABS, it also changes the
type to unsigned.
Since strip_sign_op_1 is only supposed to strip off
sign changing operands and not ones that change types,
removing ABSU_EXPR here is correct. We don't handle
nop conversions so this does cause any missed optimizations either.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/110386

gcc/ChangeLog:

* gimple-ssa-backprop.c (strip_sign_op_1): Remove ABSU_EXPR.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr110386-1.c: New test.
* gcc.c-torture/compile/pr110386-2.c: New test.

(cherry picked from commit 2bbac12ea7bd8a3eef5382e1b13f6019df4ec03f)

[Bug tree-optimization/110386] [11/12 Regression] ICE with ABSU in backprop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||11.4.1, 12.3.1
 Resolution|--- |FIXED
  Known to fail||12.3.0

--- Comment #13 from Andrew Pinski  ---
Fixed everywhere.

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

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

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

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

https://gcc.gnu.org/g:5967696c0f6300da4387fea5d102be5bc9f23233

commit r15-337-g5967696c0f6300da4387fea5d102be5bc9f23233
Author: Hu, Lin1 
Date:   Fri Jan 19 15:22:10 2024 +0800

i386: Fix some intrinsics without alignment requirements.

gcc/ChangeLog:

PR target/84508
* config/i386/emmintrin.h
(_mm_load_sd): Remove alignment requirement.
(_mm_store_sd): Ditto.
(_mm_loadh_pd): Ditto.
(_mm_loadl_pd): Ditto.
(_mm_storel_pd): Add alignment requirement.
* config/i386/xmmintrin.h
(_mm_loadh_pi): Remove alignment requirement.
(_mm_loadl_pi): Ditto.
(_mm_load_ss): Ditto.
(_mm_store_ss): Ditto.

gcc/testsuite/ChangeLog:

PR target/84508
* gcc.target/i386/pr84508-1.c: New test.
* gcc.target/i386/pr84508-2.c: Ditto.

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #3 from Kito Cheng  ---
> Can this fix backport to GCC-14 ?

Sure, GCC 14.1 released, so it open to accept fixes now :)

[Bug tree-optimization/114998] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|ICE on valid code at -O3|[14/15 Regression] ICE on
   |with "-fno-inline   |valid code at -O3 with
   |-fno-tree-dce -fno-ipa-cp"  |"-fno-tree-dce" on
   |on x86_64-linux-gnu:|x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault
   Last reconfirmed||2024-05-09
   Target Milestone|--- |14.2
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. here is a testcase with only `-O3 -fno-tree-dce` as this basically
does what `-fno-inline` and `-fno-ipa-cp` cause:
```
short a, d;
int b, c, f, g, h, i, j[2], o;
__attribute__((const)) int s(char r);
int main() {
  int l, m, k, n;
  if (b) {
char p;
for (; p >= 0; p--) {
  int e[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0,
 1, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 1,
 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0};
  if (j[p]) {
int q[1];
i = o;
o = q[h];
if (g)
  n = d;
m = 4;
for (; m; m--) {
  if (l)
k |= c;
  if (a)
break;
}
  }
  s(n);
  f |= b;
}
  }
  return 0;
}
```

[Bug target/114981] [avr] Improve powi implementation

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:

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

commit r13-8736-gadba85bb63a45d7d668501c11bdf9772cc00b7b8
Author: Georg-Johann Lay 
Date:   Wed May 8 17:56:05 2024 +0200

AVR: target/114981 - Support __builtin_powi[l] / __powidf2.

This supports __powidf2 by means of a double wrapper for already
existing f7_powi (renamed to __f7_powi by f7-renames.h).
It tweaks the implementation so that it does not perform trivial
multiplications with 1.0 any more, but instead uses a move.
It also fixes the last statement of f7_powi, which was wrong.
Notice that f7_powi was unused until now.

PR target/114981
libgcc/config/avr/libf7/
* libf7-common.mk (F7_ASM_PARTS): Add D_powi
* libf7-asm.sx (F7MOD_D_powi_, __powidf2): New module and function.
* libf7.c (f7_powi): Fix last (wrong) statement.
Tweak trivial multiplications with 1.0.

gcc/testsuite/
* gcc.target/avr/pr114981-powil.c: New test.

(cherry picked from commit de4eea7d7ea86e54843507c68d6672eca9d8c7bb)

[Bug fortran/114825] [11/12 Regression] Compiler error using gfortran and OpenMP since r5-1190

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11/12 Regression] Compiler
   |Compiler error using|error using gfortran and
   |gfortran and OpenMP since   |OpenMP since r5-1190
   |r5-1190 |

--- Comment #8 from Jakub Jelinek  ---
Fixed also for 13.3.

[Bug tree-optimization/114876] [11/12 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11/12 Regression]
   |-fprintf-return-value   |-fprintf-return-value
   |mishandles %lc with a '\0'  |mishandles %lc with a '\0'
   |argument.   |argument.

--- Comment #10 from Jakub Jelinek  ---
Fixed also for 13.3.

[Bug sanitizer/114956] [11/12 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11/12 Regression]
   |Segmentation fault with |Segmentation fault with
   |-fsanitize=address  |-fsanitize=address
   |-fsanitize=null -O2 when|-fsanitize=null -O2 when
   |attribute   |attribute
   |no_sanitize_address is  |no_sanitize_address is
   |enabled since r9-5742   |enabled since r9-5742

--- Comment #8 from Jakub Jelinek  ---
Fixed also for 13.3.

[Bug c++/111284] [11/12 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] Some  |[11/12 Regression] Some
   |passing-by-value parameters |passing-by-value parameters
   |are mishandled since GCC 9, |are mishandled since GCC 9,
   |affecting libstdc++'s   |affecting libstdc++'s
   |constexpr std::string   |constexpr std::string

--- Comment #13 from Jakub Jelinek  ---
Fixed also for 13.3.

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed also for 13.3.

[Bug tree-optimization/114965] [13 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #17 from Jakub Jelinek  ---
Fixed also for 13.3.

[Bug target/114981] [avr] Improve powi implementation

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:

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

commit r14-10186-ga9e313ed38775b3ffee650d5396419ce3e6ea389
Author: Georg-Johann Lay 
Date:   Wed May 8 17:56:05 2024 +0200

AVR: target/114981 - Support __builtin_powi[l] / __powidf2.

This supports __powidf2 by means of a double wrapper for already
existing f7_powi (renamed to __f7_powi by f7-renames.h).
It tweaks the implementation so that it does not perform trivial
multiplications with 1.0 any more, but instead uses a move.
It also fixes the last statement of f7_powi, which was wrong.
Notice that f7_powi was unused until now.

PR target/114981
libgcc/config/avr/libf7/
* libf7-common.mk (F7_ASM_PARTS): Add D_powi
* libf7-asm.sx (F7MOD_D_powi_, __powidf2): New module and function.
* libf7.c (f7_powi): Fix last (wrong) statement.
Tweak trivial multiplications with 1.0.

gcc/testsuite/
* gcc.target/avr/pr114981-powil.c: New test.

(cherry picked from commit de4eea7d7ea86e54843507c68d6672eca9d8c7bb)

[Bug c/115002] New: wide integer vector performance regression, x86, between gcc-14 and gcc-13 using target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

Bug ID: 115002
   Summary: wide integer vector performance regression, x86,
between gcc-14 and gcc-13 using target clones on
skylake platform
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colin.king at intel dot com
  Target Milestone: ---

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

I'm seeing a ~1.5% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:

Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

CFLAGS="" gcc-13 reproducer-vecwide.c -O2 -Wall
cking@skylake:~$ ./a.out 
7615.58 vint8w2048_t ops per sec, duration = 13.13 secs

cking@skylake:~$ CFLAGS="" gcc-14 reproducer-vecwide.c -O2 -Wall
cking@skylake:~$ ./a.out 
7489.42 vint8w2048_t ops per sec, duration = 13.35 secs

The original issue appeared when regression testing stress-ng vecwide stressor
[1]. I've managed to extract the attached reproducer from the original code
(see attached).

Salient point to focus on:

1. The issue is also dependant on the TARGET_CLONES macro being defined as
__attribute__((target_clones("avx,default")))  - the avx target clones seems to
be an issue in reproducing this problem.

Attached are the reproducer C source and disassembled object code. 

References: [1]
https://github.com/ColinIanKing/stress-ng/blob/master/stress-vecwide.c

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

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

[Bug target/115002] [14/15 regression] wide integer vector performance regression, x86, between gcc-14 and gcc-13 using target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #1 from Colin Ian King  ---
Created attachment 58139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58139&action=edit
gcc-13 disassembly

gcc-13 disassembly

[Bug target/115002] [14/15 regression] wide integer vector performance regression, x86, between gcc-14 and gcc-13 using target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #2 from Colin Ian King  ---
Created attachment 58140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58140&action=edit
gcc-14 disassembly

gcc-14 disassembly

[Bug target/114975] [AVR] Using popcounthi2 for 8-bit values despite popcountqi2

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:

https://gcc.gnu.org/g:4ef09dd8ce8866e4f64dd918890c97a67af8fd15

commit r14-10187-g4ef09dd8ce8866e4f64dd918890c97a67af8fd15
Author: Georg-Johann Lay 
Date:   Tue May 7 19:39:55 2024 +0200

AVR: target/114975 - Add combine-pattern for __popcountqi2.

PR target/114975
gcc/
* config/avr/avr.md: Add combine pattern for
8-bit popcount detection.

gcc/testsuite/
* gcc.target/avr/pr114975-popcount.c: New test.

(cherry picked from commit c8f4bbb824fafecf021a802324cd79e64b03b947)

[Bug target/114975] [AVR] Using popcounthi2 for 8-bit values despite popcountqi2

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:

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

commit r14-10188-gbbb76ac0a06ae3a469f2acc2d5d63e63160bd9e5
Author: Georg-Johann Lay 
Date:   Tue May 7 19:42:30 2024 +0200

AVR: target/114975 - Add combine-pattern for __parityqi2.

PR target/114975
gcc/
* config/avr/avr.md: Add combine pattern for
8-bit parity detection.

gcc/testsuite/
* gcc.target/avr/pr114975-parity.c: New test.

(cherry picked from commit 41bc359c322d45ec1adfb51f7a45c7ef02ce6ca9)

[Bug target/114975] [AVR] Using popcounthi2 for 8-bit values despite popcountqi2

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|15.0|14.2

--- Comment #6 from Georg-Johann Lay  ---
Fixed in v14.2+

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

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

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

Bug ID: 115004
   Summary: [11/12/13/14/15 Regression] Missed optimization for
Dead Code Elimination
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that the code below can be optimized by Dead Code
Elimination, but gcc -O3 missed it.

This is a regression from GCC-8.1.

https://godbolt.org/z/7e64e56Mq

int m;
void fn(signed char p1, short p2, signed char p3_1, signed char p3_2, short p4,
unsigned char p5) {
if(
(signed char)((p4 | 0) && (p1 || p2) || p5 || p3_1 && p5)
-
(signed char)((p4 | 0) && (p1 || p2) || p5 || p3_2 && p5)
)
{ m=1; }
}

GCC -O3:
fn(signed char, short, signed char, signed char, short, unsigned char):
testr8w, r8w
je  .L1
testdil, dil
setne   al
testsi, si
setne   dl
or  eax, edx
testr9b, r9b
jne .L6
.L1:
ret
.L6:
testal, al
jne .L1
testr9b, r9b
jne .L1
mov DWORD PTR m[rip], 1
ret

Expected code (GCC-7.5):
fn(signed char, short, signed char, signed char, short, unsigned char):
rep ret

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug modula2/115003] New: exporting a symbol to outer scope with a name clash causes ICE

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

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

Bug ID: 115003
   Summary: exporting a symbol to outer scope with a name clash
causes ICE
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the gm2 mailing list, the following program causes an ICE:

MODULE Test;
(*
 * Produces internal compiler error
 * Inside SymbolTable.GetScope, GetPsym() returns an unexpected token.
 *)

TYPE CardType = CARDINAL;

 MODULE Inside;

 EXPORT CardType;

 END Inside;

END Test.

[Bug modula2/115003] exporting a symbol to outer scope with a name clash causes ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-09

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug c++/95725] Confusing error diagnostic in an invalid template

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug c++/95659] Inconsistent error message in "default argument missing for parameter"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug target/115002] [14/15 regression] wide integer vector performance regression, x86, between gcc-14 and gcc-13 using target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #3 from Colin Ian King  ---
Created attachment 58141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58141&action=edit
perf output of stress_vecwide_2048 for gcc-13 compiled code

perf output of stress_vecwide_2048 for gcc-13 compiled code

[Bug target/115002] [14/15 regression] wide integer vector performance regression, x86, between gcc-14 and gcc-13 using target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #4 from Colin Ian King  ---
Created attachment 58142
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58142&action=edit
perf output of stress_vecwide_2048 for gcc-14 compiled code

perf output of stress_vecwide_2048 for gcc-14 compiled code

[Bug modula2/115003] exporting a symbol to outer scope with a name clash causes ICE

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 58143
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58143&action=edit
Proposed fix

The scope was an unknown symbol which was not in the case list within
SymbolTable.GetScope.
This patch adds a missing case clause allowing the compiler to recover.

$ gm2 Test.mod 
Test.mod:11:9: error: symbol ‘CardType’ is already declared in this scope, use
a different name or remove the declaration
   11 |  EXPORT CardType;
  | ^~~~
Test.mod:7:17: error: symbol ‘CardType’ also declared in this module
7 | TYPE CardType = CARDINAL;
  | ^~~~

[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type

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

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

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

https://gcc.gnu.org/g:8fb65ec816ff8f0d529b6d30821abace4328c9a2

commit r15-340-g8fb65ec816ff8f0d529b6d30821abace4328c9a2
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type

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

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

--- Comment #25 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:726e7a64edc22a33a5f495698722ba797793edca

commit r14-10189-g726e7a64edc22a33a5f495698722ba797793edca
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type

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

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

--- Comment #26 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8737-g6f7674a558aaa0c7b16657c35666ad9b12e1c219
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type

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

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

--- Comment #27 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-10435-gffa41c65a375746fd26c2d620e634fb162726dfc
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type

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

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

--- Comment #28 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-11423-ge6c869372f0ca8b28ac63c7eb26fde35b53aba37
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

[Bug target/113652] [14/15 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

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

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

--- Comment #26 from Segher Boessenkool  ---
(In reply to Michael Meissner from comment #23)
> 1) Ignore it and say to the users don't do that.
> 
> 2) Prevent the IEEE 128-bit libgcc bits from being built on a BE or 32-bit
> LE system unless some configure switch is used.  Or just kick the can down
> the road, and don't provide a configure option in GCC 14, and if people are
> interested do it in GCC 15.
> 
> 3) Only build the IEEE 128-bit libgcc bits if the user configured the
> compiler with --with-cpu=power7, --with-cpu=power8, --with-cpu=power9,
> --with-cpu=power10 (and in the future --with-cpu=power11 or
> --with-cpu=future).  This could be code that if __VSX__ is not defined, the
> libgcc support functions won't get built.  We would then remove the -mvsx
> option from the library support functions.

4) Build those pieces of libgcc with the flags needed for that piece of code.
Like, just as is required for all other code.

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

--- Comment #1 from Segher Boessenkool  ---
This is not a 2->2 combination.  It is a 1->1 combination, which we never have
done,
and still don't.  We incorrectly "combined" another instruction, which in fact
we
left in place, it isn't combined at all!

[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #2)
> We go from CCGC with a sign_extend to a zero_extend with CCZ. that can't be
> right.

Why not?  We prefer zero_extend whenever it has the same result.

[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu

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

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

--- Comment #10 from Segher Boessenkool  ---
(_extract, btw.)

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from Aldy Hernandez  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
>> > --- Comment #13 from Aldy Hernandez  ---
>> > BTW, I'm waiting for a review, or at least a nod from a C++ savvy
>> > person here:
>> >
>> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
>> 
>> I can give the patch a whirl, thanks.
>
> I've attached a rebased patch against current mainline.  Let me know if it
> works on your end, and I'll commit.

I've included both this patch ...

>> I had Andrew's patch in my tree to avoid the issue.  Unfortunately,
>> Solaris/SPARC bootstrap is broken again due to PR ipa/114985.
>
> I have provided a patch for that PR as well, but the IPA folk need to say if
> this is the correct approach.

... and that one in last night's SPARC bootstraps, which worked just
fine again.  Thanks.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #19 from Aldy Hernandez  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #18)
> > --- Comment #16 from Aldy Hernandez  ---
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> >> > --- Comment #13 from Aldy Hernandez  ---
> >> > BTW, I'm waiting for a review, or at least a nod from a C++ savvy
> >> > person here:
> >> >
> >> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
> >> 
> >> I can give the patch a whirl, thanks.
> >
> > I've attached a rebased patch against current mainline.  Let me know if it
> > works on your end, and I'll commit.
> 
> I've included both this patch ...
> 
> >> I had Andrew's patch in my tree to avoid the issue.  Unfortunately,
> >> Solaris/SPARC bootstrap is broken again due to PR ipa/114985.
> >
> > I have provided a patch for that PR as well, but the IPA folk need to say if
> > this is the correct approach.
> 
> ... and that one in last night's SPARC bootstraps, which worked just
> fine again.  Thanks.

Thanks for testing.  I'll close this PR as fixed in mainline then.  FWIW, I
also retested on x86-64 Linux.

[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #10 from Jakub Jelinek  ---
Vlad, do you plan to backport this to 13.3?  One of the 2 release blockers we
have for that release.

[Bug tree-optimization/114998] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[14/15 Regression] ICE on   |[14/15 Regression] ICE on
   |valid code at -O3 with  |valid code at -O3 with
   |"-fno-tree-dce" on  |"-fno-tree-dce" on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault since
   ||r14-9767

--- Comment #2 from Jakub Jelinek  ---
Started with r14-9767-ge7b7188b1cf8c174f0e890d4ac279ff480b51043

[Bug c/115005] New: [gcc-13] bogus -Warray-bounds warning

[sezeroz at gmail dot com via Gcc-bugs]

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

Bug ID: 115005
   Summary: [gcc-13] bogus -Warray-bounds warning
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sezeroz at gmail dot com
  Target Milestone: ---

Created attachment 58144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58144&action=edit
reduced C source exhibiting the issue

The attached C source emits bogus -Warray-bounds warnings at -O2 and -O3
(tested on i686 and x86_64):

$ gcc13 -c -O2 -Wall mmcmp-small.c

In function 'block_unpack_8bit',
inlined from 'decrunch_mmcmp' at mmcmp-small.c:231:4:
mmcmp-small.c:155:35: warning: array subscript 4294967295 is above array bounds
of 'const uint32[8]' {aka 'const unsigned int[8]'} [-Warray-bounds=]
  155 | if (d >= cmd_8bits[numbits]) {
  |  ~^
mmcmp-small.c: In function 'decrunch_mmcmp':
mmcmp-small.c:39:21: note: while referencing 'cmd_8bits'
   39 | extern const uint32 cmd_8bits[8];
  | ^
In function 'block_unpack_16bit',
inlined from 'decrunch_mmcmp' at mmcmp-small.c:229:4:
mmcmp-small.c:90:35: warning: array subscript 4294967295 is above array bounds
of 'const uint32[16]' {aka 'const unsigned int[16]'} [-Warray-bounds=]
   90 | if (d >= cmd_16bit[numbits]) {
  |  ~^
mmcmp-small.c: In function 'decrunch_mmcmp':
mmcmp-small.c:41:21: note: while referencing 'cmd_16bit'
   41 | extern const uint32 cmd_16bit[16];
  | ^

The original file in question is at
https://github.com/libxmp/libxmp/blob/master/src/depackers/mmcmp.c
I removed as much clutter as I could, but you guys would most probably reduce
it more.
The issue was originally discussed at libxmp:
https://github.com/libxmp/libxmp/issues/667
Notes particularly at
https://github.com/libxmp/libxmp/issues/667#issuecomment-1712584590

The warnings go away if numbits is changed from uint32 to uint8 or uint16: 
We had changed it to uint8 as a solution.

[Bug c/115005] [gcc-13] bogus -Warray-bounds warning

[sezeroz at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ozkan Sezer  ---
Created attachment 58145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58145&action=edit
preprocessed original source

[Bug bootstrap/115006] New: Bootstrap with clang 17 on macOS & CLT 15.3 fails to compile gcov.cc

[ilg at livius dot net via Gcc-bugs]

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

Bug ID: 115006
   Summary: Bootstrap with clang 17 on macOS & CLT 15.3 fails to
compile gcov.cc
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ilg at livius dot net
  Target Milestone: ---

If I read the error message right, it looks like a mismatch between the
definitions in GCC headers and the clang C++ headers.

In my test I installed clang 17 via Homebrew.

If not solved, this error will most probably affect the GCC bootstrap on future
CLT/Xcode releases, when Apple will get to clang 17.

I noticed the error while trying to bootstrap GCC 14 and 13, but previous
versions might also be affected. 

Ideally the fix should be back-ported to previous GCC versions.


```
In file included from
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/gcov.cc:39:
In file included from
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/system.h:227:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/map:2529:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/functional:526:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__functional/boyer_moore_searcher.h:27:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/vector:321:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__format/formatter_bool.h:20:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__format/formatter_integral.h:32:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/locale:202:
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__locale:546:5:
error: '__abi_tag__' attribute only applies to structs, variables, functions,
and namespaces
  546 | _LIBCPP_INLINE_VISIBILITY
  | ^
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__config:841:37:
note: expanded from macro '_LIBCPP_INLINE_VISIBILITY'
  841 | #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
  | ^
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__config:820:26:
note: expanded from macro '_LIBCPP_HIDE_FROM_ABI'
  820 |  
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_ODR_SIGNATURE
  |  ^
In file included from
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/gcov.cc:39:
In file included from
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/system.h:227:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/map:2529:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/functional:526:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__functional/boyer_moore_searcher.h:27:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/vector:321:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__format/formatter_bool.h:20:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__format/formatter_integral.h:32:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/locale:202:
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__locale:547:37:
error: expected ';' at end of declaration list
  547 | char_type toupper(char_type __c) const
  | ^
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../include/c++/v1/__locale:553:48:
error: too many arguments provided to function-like macro invocation
  553 | const char_type* toupper(char_type* __low, const char_type* __high)
const
  |^
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/../include/safe-ctype.h:146:9:
note: macro 'toupper' defined here
  146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
  | ^
In file included from
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/gcov.cc:39:
In file included from
/Users/ilg/Work/xpack-dev-tools-build/aarch64-none-elf-gcc-13.2.1-1.1/darwin-x64/sources/gcc/gcc/system.h:227:
In file included from
/Users/ilg/.local/homebrew/hb/Cellar/llvm/17.0.6_1/bin/../i

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #11 from chenglulu  ---
(In reply to Chen Chen from comment #0)
> We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux
> operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we
> found the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered
> significant regressions from 14% to 28% with various compiling options.
> 
> The rate-1 results are following:
> 
> after snapshot 20240317 score 14.3-19.3% lower with parameters "-g -Ofast
> -march=native":
> 13.2.0:11.7 (223s) [gcc 13.2.0, system default]
Hi：

 I can't reproduce the score of r13.2. Have you made any modifications there?

[Bug bootstrap/115006] Bootstrap with clang 17 on macOS & CLT 15.3 fails to compile gcov.cc

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Francois-Xavier Coudert  ---
Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632

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

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||ilg at livius dot net

--- Comment #27 from Francois-Xavier Coudert  ---
*** Bug 115006 has been marked as a duplicate of this bug. ***

[Bug c++/115007] New: [modules] ICE in maybe_clone_body when calling virtual destructor from instantiated template

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

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

Bug ID: 115007
   Summary: [modules] ICE in maybe_clone_body when calling virtual
destructor from instantiated template
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

The following sample ICEs on trunk:


  // a.cpp
  module;
  struct S {
virtual ~S() = default;
virtual void f() = 0;
  };
  module M:a;
  S *p;
  template  void format(T) { p->~S(); }
  template void format(int);

  // m.cpp
  export module M;
  import :a;


'g++ -fmodules-ts -Wno-global-module -S a.cpp m.cpp' results in:

m.cpp: In destructor ‘S@M:a::~S()’:
m.cpp:2:11: internal compiler error: Segmentation fault
2 | import :a;
  |   ^
0x1bad37f crash_signal
../../gcc/gcc/toplev.cc:319
0x7ffb375cc51f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x1076395 maybe_clone_body(tree_node*)
../../gcc/gcc/cp/optimize.cc:705
0x11e00d9 expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.cc:5098
0x11e040b expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.cc:5133
0xf54666 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5362
0x1322ee7 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1329


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c++/115008] New: ICE with modules on amd64-freebsd*

[gerald at pfeifer dot com via Gcc-bugs]

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

Bug ID: 115008
   Summary: ICE with modules on amd64-freebsd*
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
CC: developer at lorenzosalvadore dot it, nathan at acm dot org,
nshead at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-unknown-freebsd13.2
Target: x86_64-unknown-freebsd13.2
 Build: x86_64-unknown-freebsd13.2

Looking at recent test results, but even back to January 1st, I noticed
that 1349 modules related tests fail on FreeBSD/amd64.

Running some of them manually I see

  ~/gcc-ref13-amd64/bin/g++ g++.dg/modules/freeze-1_a.C \
   -std=c++17 -fmodules-ts
  g++.dg/modules/freeze-1_a.C:5:19: internal compiler error: Segmentation fault
5 | export void bob ();
  |   ^
  0x82a85b4ae handle_signal
/usr/src/lib/libthr/thread/thr_sig.c:301
  0x82a85aa6a thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:244
  0x8287134a3 ???
/usr/src/lib/libc/amd64/string/memmove.S:304

alas am not able to get a core dump for some reason (surely unrelated
to GCC).

[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds

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

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

--- Comment #16 from Sam James  ---
(In reply to Peter Bergner from comment #14)
> (In reply to Niels Möller from comment #13)
> > I'm not that familiar with gcc development procedures. Do I understand you
> > correctly, that a fix for this bug will not be included in gcc-14 (according
> > to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended several
> > months ago), it will have to wait for gcc-15?
> 
> Correct, I meant waiting for GCC 15 stage1.  I want it to burn-in on trunk
> for a long while, because it had the potential to disrupt distro package
> builds.  It seems clean so far with the practice Gentoo builds, but I'll
> feel more comfortable when other distros start using it too. 

FWIW, we're keeping it going forward (so it'll be in e.g. our GCC 14 patchset
when we unleash that on the masses). Just keep in mind that very few
distributions build with > release checking.

We only do default-checking for the branch when it's in development still and
also optionally via USE=debug. So, while testing by others is still valuable, I
don't expect you'll get that much - at least without people specifically
knowing to turn on checking and ensure stuff doesn't break.

(Of course, making sure release checking works fine now too is important, but
you get my point.)

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

[ilg at livius dot net via Gcc-bugs]

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

--- Comment #28 from Liviu Ionescu  ---
(In reply to Francois-Xavier Coudert from comment #27)
> *** Bug 115006 has been marked as a duplicate of this bug. ***

11506 is related to gcov.cc, does the existing fixes also apply to this file?

[Bug c/115009] New: [15 regression] AVR: ICE in alloc, at value-range-storage.cc:598

[manuel.lauss at googlemail dot com via Gcc-bugs]

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

Bug ID: 115009
   Summary: [15 regression] AVR: ICE in alloc, at
value-range-storage.cc:598
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.lauss at googlemail dot com
  Target Milestone: ---

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

Building avr-libc-2.1.0/avr/lib/avr2/strftime.c with latest gcc-15 snapshot:

avr-gcc -c strftime-avr.i -Os
during GIMPLE pass: evrp
../../../libc/time/strftime.c: In function ‘pgm_copystring’:
../../../libc/time/strftime.c:322:1: internal compiler error: in alloc, at
value-range-storage.cc:598
  322 | }
  | ^

-Os is essential to trigger it.

# gcc -v
Reading specs from /usr/lib/gcc/avr/15/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/15/lto-wrapper
Target: avr
Configured with:
/tmp-ram/portage/cross-avr/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --target=avr --build=x86_64-pc-linux-gnu
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/avr/gcc-bin/15
--includedir=/usr/lib/gcc/avr/15/include --datadir=/usr/share/gcc-data/avr/15
--mandir=/usr/share/gcc-data/avr/15/man
--infodir=/usr/share/gcc-data/avr/15/info
--with-gxx-include-dir=/usr/lib/gcc/avr/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/avr/15/python --enable-languages=c
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 15.0. p, commit
f525de00d17a460aebb382c0d34529ddc383fb9d' --with-gcc-major-version-only
--enable-lto --disable-libstdcxx-pch --enable-poison-system-directories
--enable-shared --disable-threads --disable-gcov --disable-bootstrap
--enable-multilib --disable-fixed-point --disable-libgomp --disable-libssp
--disable-libada --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--disable-libsanitizer --disable-default-pie --enable-host-pie
--disable-host-bind-now --disable-default-ssp --disable-fixincludes
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240509 (experimental)
2790195500ec523cad9c7292816540e2fc19f456

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

[dimitry at andric dot com via Gcc-bugs]

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

--- Comment #29 from Dimitry Andric  ---
(In reply to Liviu Ionescu from comment #28)
> (In reply to Francois-Xavier Coudert from comment #27)
> > *** Bug 115006 has been marked as a duplicate of this bug. ***
> 
> 11506 is related to gcov.cc, does the existing fixes also apply to this file?

https://gcc.gnu.org/g:9970b576b7e4ae337af1268395ff221348c4b34a fixes system.h
which is also included by gcov.cc, so I would expect that to work. Which
version of gcc were you building?

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

[ilg at livius dot net via Gcc-bugs]

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

--- Comment #30 from Liviu Ionescu  ---
(In reply to Dimitry Andric from comment #29)
> ... fixes system.h which is also included by gcov.cc

ok, great.

> Which version of gcc were you building?

in the reported bug I was building 13.2.

was the fix backported to older versions?

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #31 from Iain Sandoe  ---
(In reply to Liviu Ionescu from comment #30)
> (In reply to Dimitry Andric from comment #29)
> > ... fixes system.h which is also included by gcov.cc
> 
> ok, great.
> 
> > Which version of gcc were you building?
> 
> in the reported bug I was building 13.2.
> 
> was the fix backported to older versions?

so far, the fix has baeen back ported for 13.3 .. it is on the list to be back
ported for 12.4 and 11.5,

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #32 from Jakub Jelinek  ---
(In reply to Liviu Ionescu from comment #30)
> in the reported bug I was building 13.2.
> 
> was the fix backported to older versions?

Yes, it was, as can be seen above.  Though only in March 2024, so it couldn't
have affected gcc 13.2 which was released more than 9 months ago.  It is fixed
on gcc 13.2.1 snapshots after those commits and will be in gcc 13.3, right now
planned for release in less than 2 weeks from now.

[Bug target/115010] New: m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

Bug ID: 115010
   Summary: m68k: invalid subl instruction generated
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ad...@tho-otto.de
  Target Milestone: ---

While configuring a cross-compiler for m68k, and then trying to use that
cross-compiler to build a native compiler, a wrong subl instruction gets
generated:

Assembler messages:
/tmp/ccpLXgrk.s:16664: Error: operands mismatch -- statement sub.l
-402(%fp),-446(%fp)' ignored
/tmp/ccpLXgrk.s:16813: Error: operands mismatch -- statement sub.l
-274(%fp),-302(%fp)' ignored
make[1]: *** [Makefile:1202: tree-data-ref.o] Error 1

That instruction is invalid, because atleast one of the operands must be a data
register.

Unfortunately the steps to reproduce are a bit complicated, using a bare
m68k-elf target not work, because for the 2nd step you will also need a working
c-library. And of course you also need binutils for that target.

I should also mention that the same bug already happened in gcc 11.4.0, but
strangely not in gcc 13.2.0 or gcc 12.3.0 (but maybe this was just by
incident).
The problem also disappears when compiling tree-data-ref.c using -Os instead of
-O2.

I'm not that really familiar with the machine description files, but to me

(define_insn "subsi3"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=md,ma,m,d,a")
(minus:SI (match_operand:SI 1 "general_operand" "0,0,0,0,0")
  (match_operand:SI 2 "general_src_operand"
"I,I,dT,mSrT,mSrs")))]
  ""
  "@
   subq%.l %2, %0
   subq%.l %2, %0
   sub%.l %2,%0
   sub%.l %2,%0
   sub%.l %2,%0"
  [(set_attr "type" "aluq_l,aluq_l,alu_l,alu_l,alu_l")
   (set_attr "opy" "2")
   (set_attr "flags_valid" "noov,unchanged,noov,noov,unchanged")])


Looks suspicious. If i'm not wrong, that pattern is used to turn something like
"x = x - y" into "x -= y". But alternative 3 can match a memory operand for
operand 0, and constraint 'T' for operand 2 is defined as

(define_constraint "T"
  "Used for operands that satisfy 's' when -mpcrel is not in effect."
  (and (match_code "symbol_ref,label_ref,const")
   (match_test "!TARGET_PCREL")
   (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))

so it can match a symbol_ref. Could that be the cause?

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

[ilg at livius dot net via Gcc-bugs]

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

--- Comment #33 from Liviu Ionescu  ---
> Yes, it was...

Great, thank you.

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[chz0808 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Chen Chen  ---
(In reply to chenglulu from comment #11)
> (In reply to Chen Chen from comment #0)
> > We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux
> > operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we
> > found the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered
> > significant regressions from 14% to 28% with various compiling options.
> > 
> > The rate-1 results are following:
> > 
> > after snapshot 20240317 score 14.3-19.3% lower with parameters "-g -Ofast
> > -march=native":
> > 13.2.0:11.7 (223s) [gcc 13.2.0, system default]
> Hi：
> 
>  I can't reproduce the score of r13.2. Have you made any modifications there?

No. I used system default gcc. How big is the difference? A little fluctuation
is normal. I once got scores 11.3(232s)、11.5(227s) with parameters "-g -Ofast
-march=native" in previous tests too. To be fair, in each test presented above
I always free page cache by the command "echo 3 > /proc/sys/vm/drop_caches" and
then run the test.

[Bug tree-optimization/115011] New: [14/15 Regression] Missed optimization: (bool) (f ? 1: t) ==> 1 when bool t = (0 >= f) + x;

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

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

Bug ID: 115011
   Summary: [14/15 Regression] Missed optimization: (bool) (f ? 1:
t) ==> 1 when bool t = (0 >= f) + x;
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that the code below can be optimized as stated in the title,
but gcc -O3 seems to have missed it.


Reduced code:
https://godbolt.org/z/xE6GEEn7j

bool x;
bool fn3(unsigned long long int f) {
bool t = (0 >= f) + x;
return f ? 1: t;
}

GCC -O3:
fn3(unsigned long long):
movzx   eax, BYTE PTR x[rip]
cmp rdi, 1
adc eax, 0
testeax, eax
setne   al
testrdi, rdi
setne   dl
or  eax, edx
ret

Expected code (GCC-13.2):
fn3(unsigned long long):
mov eax, 1
ret

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug c++/115012] New: noptr-abstract-pack-declarator parsing bug with T... [N]

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

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

Bug ID: 115012
   Summary: noptr-abstract-pack-declarator parsing bug with T...
[N]
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, egor.pugin at gmail 
dot com,
mpolacek at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
Depends on: 113798
Blocks: 110338
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #113798 +++

As mentioned in the https://wg21.link/P2662R3 paper, we aren't parsing
correctly T...[N] parameters.

template 
void
foo (T... x[N])
{
}

template 
void
bar (T [N])
{
}

template 
void
baz (T... [N])
{
}

template 
void
qux (T... [N][N])
{
}

void
corge (int a[10], double b[10], int c[5][5], float d[5][5])
{
  foo <10, int, double> (a, b);
  bar <10, int> (a);
  baz <10, int, double> (a, b);
  qux <5, int, float> (c, d);
}

is accepted by clang++ but not by GCC nor MSCV.
This is going to change in C++26 with pack indexing, but in C++11 .. C++23 it
should be valid.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
[Bug 110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113798
[Bug 113798] [C++26] P2662R3 - Pack indexing

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

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

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

--- Comment #13 from Xi Ruoyao  ---
(In reply to Chen Chen from comment #12)

> No. I used system default gcc.

AOSC backports *many* changes not in upstream GCC 13.2 to their "13.2":
https://github.com/AOSC-Dev/aosc-os-abbs/tree/stable/core-devel/gcc/01-runtime/patches

So the default GCC is simply not GCC 13.2.

[Bug c++/113798] [C++26] P2662R3 - Pack indexing

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

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

--- Comment #1 from Jakub Jelinek  ---
Note, I wonder if the paper didn't go too far with the
noptr-abstract-pack-declarator [ constant-expression[opt] ]
attribute-specifier-seq[opt]
production removal.  It removes the unwanted
T...[4]
case which ought to be parsed as pack indexing, sure, but doesn't it also
unnecessarily
make

void foo (T...(int)[10])
{
}
invalid as well?

[Bug c++/115012] noptr-abstract-pack-declarator parsing bug with T... [N]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

--- Comment #2 from Jeffrey A. Law  ---
I don't care about the terminology.  We have 3 insns in play.  A, B and C.

We try to combine A -> B which succeeded before resulting in A, B' and C and
which in turn allowed a subsequent A -> C combination resulting in a final B',
C' sequence, eliminating A.  After the combiner patch in question no
combinations are done.

So, let's move past the argument on terminology and discuss the technical
issue.  This is something that worked in gcc-14 without the combiner patch. 
This is important for code generation.

How do you propose we address the regression?

[Bug c/115013] New: LRA: PR114810 fix result in ICE in the RISC-V Vector

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

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

Bug ID: 115013
   Summary: LRA: PR114810 fix result in ICE in the RISC-V Vector
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

The patch:
[PR114810][LRA]: Recognize alternatives with lack of available registers for
insn and demote them.

Results in some ICE in the rvv.exp of RISC-V backend.

   = Summary of gcc testsuite =
| # of unexpected case / # of unique unexpected
case
|  gcc |  g++ | gfortran |
rv64gcv/  lp64d/ medlow | 1061 /69 |0 / 0 |  - |
make: *** [Makefile:1096: report-gcc-newlib] Error 1

Just pick one imm_loop_invariant-10.c as below.

.../gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c:20:1:
error: unrecognizable insn:
(insn 265 0 0 (parallel [
(set (reg:RVVMF8QI 309 [239])
(unspec:RVVMF8QI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))
(clobber (scratch:SI))
]) -1
 (nil))
during RTL pass: reload
…. gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c:20:1:
internal compiler error: in extract_insn, at recog.cc:2812
0xa9d309 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../.././gcc/gcc/rtl-error.cc:108
0xa9d32b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../.././gcc/gcc/rtl-error.cc:116
0xa9bc07 extract_insn(rtx_insn*)
../.././gcc/gcc/recog.cc:2812
0x10e5ad2 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
../.././gcc/gcc/ira.cc:5381
0x112868f remove_insn_scratches
../.././gcc/gcc/lra.cc:2154
0x112868f lra_emit_move(rtx_def*, rtx_def*)
../.././gcc/gcc/lra.cc:513
0x1136883 match_reload
../.././gcc/gcc/lra-constraints.cc:1184
0x1142ae4 curr_insn_transform
../.././gcc/gcc/lra-constraints.cc:4778
0x11443cb lra_constraints(bool)
../.././gcc/gcc/lra-constraints.cc:5481
0x112b192 lra(_IO_FILE*, int)
../.././gcc/gcc/lra.cc:2442
0x10e0e7f do_reload
../.././gcc/gcc/ira.cc:5973
0x10e0e7f execute
../.././gcc/gcc/ira.cc:6161

reproduced by below command:
riscv64-unknown-elf-gcc -c -S
gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c
-march=rv32gcv -mabi=ilp32 -o -

[Bug target/114991] [14/15 Regression] AArch64: LDP pass does not handle some structure copies

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

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-09
 Status|UNCONFIRMED |NEW
 CC||acoplan at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||missed-optimization, ra

--- Comment #1 from Alex Coplan  ---
Confirmed.  There is a lot to unpack here.  Of course, the include isn't needed
in this testcase and the problem can be seen more clearly with a slightly
smaller array size:

typedef struct { int arr[16]; } S;

void g (S *);
void h (S);
void f(int x)
{
  S s;
  g (&s);
  h (s);
}

In this case sizeof(S) = 64 so we should be able to do the copy with 2 LDPs + 2
STPs.

So just for clarity, the missed ldp/stp started when we turned off the early
ldp/stp formation in memcpy expansion, i.e. with
r14-9373-g19b23bf3c32df3cbb96b3d898a1d7142f7bea4a0 .

However, things already started to regress earlier for this testcase with
r14-4944-gf55cdce3f8dd8503e080e35be59c5f5390f6d95e i.e.

commit f55cdce3f8dd8503e080e35be59c5f5390f6d95e
Author: Vladimir N. Makarov 
Date:   Thu Oct 26 14:50:40 2023

[RA]: Modfify cost calculation for dealing with equivalences

before that RA change we get:

f:
stp x29, x30, [sp, -144]!
mov x29, sp
add x0, sp, 80
bl  g
ldp q29, q28, [sp, 80]
add x0, sp, 16
ldp q31, q30, [sp, 112]
stp q29, q28, [sp, 16]
stp q31, q30, [sp, 48]
bl  h
ldp x29, x30, [sp], 144
ret

and afterwards we get:

f:
stp x29, x30, [sp, -160]!
mov x29, sp
str x19, [sp, 16]
add x19, sp, 96
mov x0, x19
bl  g
add x0, sp, 32
ldp q29, q28, [x19]
ldp q31, q30, [x19, 32]
stp q29, q28, [x0]
stp q31, q30, [x0, 32]
bl  h
ldr x19, [sp, 16]
ldp x29, x30, [sp], 160
ret

which is really not great as now we have a save/restore of x19 and the accesses
end up using different (non-sp) registers which I suspect doesn't help with the
ldp/stp formation (on trunk).

I will try to give a detailed analysis on what goes wrong with the ldp/stp
formation at the RTL level shortly (there are a lot of different issues), but I
think that RA change is a contributing factor.

[Bug target/113652] [14/15 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

[erhard_f at mailbox dot org via Gcc-bugs]

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

--- Comment #27 from Erhard F.  ---
(In reply to Peter Bergner from comment #25)
> I think this is the solution we want, meaning if the target we're building
> supports VSX, then we'll build the IEEE128 bits, otherwise, we won't build
> them.  I think that is the only sane answer.
> 
> I also believe that if the user specifies a -mcpu= option (either implicitly
> or explicitly) that doesn't support VSX (eg, power4, or 7450, etc.) and they
> also explicitly use -mvsx, then we should emit an error message saying the
> -mcpu= option doesn't support using -mvsx at the same time.  Ditto for
> -maltivec, -mmma, etc.  We should not be silently enabling instruction
> support over and above their -mcpu= selection just because its needed for
> VSX/Altivec/MMA/etc. support.  Currently we don't emit an error and instead
> silently enable generating instructions not supported by their -mcpu= option.
As user I would favor this approach.

Because that way I get an error message I actually understand at the early
stages of building a package. Not silently broken code and illegal
opcode/unrecognized opcode messages later on which make me wonder where they
come from when I specified -mcpu=7450 or -mcpu=970.

Unrelated to libgcc but similar issues would be bug #97367 or my Gentoo
Downstream bug report about nettle-3.9.1 (https://bugs.gentoo.org/920234).

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

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

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

--- Comment #8 from seurer at gcc dot gnu.org ---
tests ran OK too.

[Bug tree-optimization/115011] [14/15 Regression] Missed optimization: (bool) (f ? 1: t) ==> 1 when bool t = (0 >= f) + x;

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |14.2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-09
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is caused by r14-1597.

[Bug tree-optimization/115011] [14/15 Regression] Missed optimization: (bool) (f ? 1: t) ==> 1 when bool t = (0 >= f) + x;

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2024-05-09 00:00:00 |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #2 from Andrew Pinski  ---
Confirmed. this was "exposed/caused" by my r14-3486-gd9a0d692ffc695 .

We miss this in previous releases too (LLVM is only able to optimize it for
LLVM 18+):
```
bool x;
bool fn3(unsigned long long int f) {
bool t = (0 >= f) + x;
bool t1 = t | (f != 0);
return t1;
}
```

I will look into this in a few weeks since I suspect it is a minor regression.

[Bug middle-end/111009] [12/13 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andrew Macleod
:

https://gcc.gnu.org/g:421311a31a12b96143eb901fde0e020771fe71d4

commit r13-8739-g421311a31a12b96143eb901fde0e020771fe71d4
Author: Andrew MacLeod 
Date:   Wed May 8 10:22:23 2024 -0400

Fix range-ops operator_addr.

Lack of symbolic information prevents op1_range from being able to draw
the same conclusions as fold_range can.

PR tree-optimization/111009
gcc/
* range-op.cc (operator_addr_expr::op1_range): Be more restrictive.
* value-range.h (contains_zero_p): New.

gcc/testsuite/
* gcc.dg/pr111009.c: New.

[Bug tree-optimization/115011] [14/15 Regression] Missed optimization: (bool) (f ? 1: t) ==> 1 when bool t = (0 >= f) + x;

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||104292

--- Comment #3 from Andrew Pinski  ---
The easiest way to fix this is to optimize t_12 in:
```
  _1 = f_10(D) == 0;
  _2 = (int) _1; //[0,1]
  x.0_3 = x;
  _4 = (int) x.0_3; //[0,1]
  _5 = _2 + _4;
  t_12 = _5 != 0;
  _7 = f_10(D) != 0;
  _14 = _7 | t_12;
```

Into:
``
  x.0_3 = x;
  _1 = f_10(D) == 0;
  t_12 = _1 | x.0_3; // <-- this
  _7 = f_10(D) != 0;
  _14 = _7 | t_12;
```
Which then will be optimized into true as _1 and _7 are opposites.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104292
[Bug 104292] (bool)(bool0 + bool1) should be simplified into bool0 | bool1

[Bug target/115010] m68k: invalid subl instruction generated

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
The m,0,s alternative exists since the beginning.

[Bug tree-optimization/115011] [14/15 Regression] Missed optimization: (bool) (f ? 1: t) ==> 1 when bool t = (0 >= f) + x;

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

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

--- Comment #4 from Andrew Pinski  ---
So depends on PR 104292.

[Bug c++/115012] noptr-abstract-pack-declarator parsing bug with T... [N]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #58147|0   |1
is obsolete||

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

Updated patch which also handles the T...(args) case.

[Bug tree-optimization/104292] (bool)(bool0 + bool1) should be simplified into bool0 | bool1

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

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

--- Comment #5 from Andrew Pinski  ---
Note LLVM started to do this "trick" in 17.1.0.

[Bug tree-optimization/115009] [15 regression] AVR: ICE in alloc, at value-range-storage.cc:598

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code
  Component|c   |tree-optimization

[Bug target/115014] New: GCC generates incorrect instructions for addressing the data segment through EBP register

[mdoucha at suse dot cz via Gcc-bugs]

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

Bug ID: 115014
   Summary: GCC generates incorrect instructions for addressing
the data segment through EBP register
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdoucha at suse dot cz
  Target Milestone: ---

Created attachment 58149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58149&action=edit
Preprocessed reproducer source file

Target: x86 (32bit)

While writing a new KVM test for the Linux Test Project, I ran into some
mysterious virtual machine crashes due to stack segment fault exception. The
test is essentially a tiny kernel that'll bootstrap a virtual CPU into
protected mode, run a few operations to test something and return results in a
predefined block of memory to the controller process running on the host
machine.

The cause of the crashes turns out to be a combination of custom stack segment
limit and GCC generating unprefixed instructions for accessing data segment
addresses through the EBP register. For example, GCC generates this
instruction:
movzbl 0x1(%ebp),%eax

When it should generate a prefixed one instead:
movzbl %ds:0x1(%ebp),%eax

This would not be a problem on most systems because the stack and data segments
are usually identical but due to the embedded nature of the KVM test, the stack
segment has special settings and the address in EBP happens to be a pointer to
string constant stored outside the stack segment limit.

The fix should be simple:
1) If the address in EBP was calculated from stack pointer value, generate
unprefixed instructions.
2) Otherwise add data segment prefix.
This condition should be applied at least if the source file is compiled for
32bit x86 with the -ffreestanding argument.

The attached source file contains a minimal reimplementation of standard C
library functions for the embedded environment. The vsprintf() reimplementation
is where the issue manifests. The source file was compiled with the following
command line options:
gcc -I../testcases/kernel/kvm/include -DCOMPILE_PAYLOAD -ffreestanding -O2
-Wall -fno-asynchronous-unwind-tables -fno-stack-protector -mno-mmx -mno-sse
-save-temps -m32 -fno-pie -c -o lib_guest.o ../testcases/kernel/kvm/lib_guest.c

Note that this is not the full KVM test which you could run to trigger the
stack segment fault exception. The full test would require:
- CPU bootstrap file in assembly[1] (see below)
- the attached reproducer file
- main test source
- test controller source
- custom linker script
- build script to tie it all together

Instead, you can just see the assembly output and look for the movzbl
instruction mentioned above.

The GCC package used for building the KVM test comes from SUSE, but I've
already talked to the SUSE maintainer (Martin Jambor) and he asked me to open
an upstream bug.


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure CFLAGS=' -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g'
CXXFLAGS=' -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' XCFLAGS=' -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g'
TCFLAGS=' -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' GDCFLAGS=' -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit,m2
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --enable-offload-defaulted
--without-cuda-driver --enable-host-shared --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/13
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-13 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-serialization
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #2 from Thorsten Otto  ---
Yes, i'm aware of that. And as already mentioned, the bug is not triggered by
all gcc versions. Is there something i can do to track down the issue?
tree-data-ref.cc is quite large.

[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-09
   Severity|normal  |enhancement
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
I am not so sure this is wanted. GCC assumes a flat memory system for stack and
normal memory accesses .

>1) If the address in EBP was calculated from stack pointer value, generate 
>unprefixed instructions.

This fix is not simple really because addresses don't need to be just in EBP
really and even can be stored off into stack memory and then loaded back.

It seems like there must be a better way of implementing this inside your
kernel as a flat memory system between stack and data segments is not going to
change because it would add a very complex tracking.

[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register

[mdoucha at suse dot cz via Gcc-bugs]

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

--- Comment #2 from Martin Doucha  ---
(In reply to Andrew Pinski from comment #1)
> I am not so sure this is wanted. GCC assumes a flat memory system for stack
> and normal memory accesses .

This is certainly not wanted in the most common case where the flat memory
assumption is correct. But it should be used for compiling embedded binaries
with -ffreestanding argument.

> >1) If the address in EBP was calculated from stack pointer value, generate 
> >unprefixed instructions.
> 
> This fix is not simple really because addresses don't need to be just in EBP
> really and even can be stored off into stack memory and then loaded back.
> 
> It seems like there must be a better way of implementing this inside your
> kernel as a flat memory system between stack and data segments is not going
> to change because it would add a very complex tracking.

The worst case for adding prefixes where they're not needed is slight binary
size and possibly performance penalty. The worst case for not adding them is
stack segment exception. The tracking does not need to be perfect.

[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #11 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #10)
> Vlad, do you plan to backport this to 13.3?  One of the 2 release blockers
> we have for that release.

Ok, I'll port it to releases/gcc-13 branch today.  The patch should be safe.

[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Doucha from comment #2)
> 
> This is certainly not wanted in the most common case where the flat memory
> assumption is correct. But it should be used for compiling embedded binaries
> with -ffreestanding argument.

I think most embedded targets use a flat memory system even on x86_64. I really
think you are barking up the wrong tree on getting this implemented in GCC (or
even LLVM) because of the complexity of tracking the memory.

It is not just about adding ds for ebp accesses.

Maybe the easiest fix is to use -fno-omit-frame-pointer to force always the use
of EBP as stack accesses only.

[Bug target/114991] [14/15 Regression] AArch64: LDP pass does not handle some structure copies

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

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

--- Comment #2 from Alex Coplan  ---
Here is some analysis on why we miss some of these opportunities in ldp_fusion.
So initially in 267r.vregs we have some very clean RTL:

6: r101:DI=sfp:DI-0x40
7: x0:DI=r101:DI
8: call [`g'] argc:0
  REG_CALL_DECL `g'
9: r102:DI=sfp:DI-0x80
   10: r103:DI=sfp:DI-0x40
   11: r104:V4SI=[r103:DI]
   13: r105:V4SI=[r103:DI+0x10]
   15: r106:V4SI=[r103:DI+0x20]
   17: r107:V4SI=[r103:DI+0x30]
   12: [r102:DI]=r104:V4SI
   14: [r102:DI+0x10]=r105:V4SI
   16: [r102:DI+0x20]=r106:V4SI
   18: [r102:DI+0x30]=r107:V4SI

if were to run the ldp/stp pass on this it should form the pairs without a
problem.  Of course things go downhill from here.  The first slightly strange
thing is that fwprop propagates the sfp into the first of each group of
accesses (i.e. with offset 0), but not the others:

9: r102:DI=sfp:DI-0x80
   11: r104:V4SI=[sfp:DI-0x40]
   13: r105:V4SI=[r101:DI+0x10]
   15: r106:V4SI=[r101:DI+0x20]
   17: r107:V4SI=[r101:DI+0x30]
  REG_DEAD r103:DI
   12: [sfp:DI-0x80]=r104:V4SI
   14: [r102:DI+0x10]=r105:V4SI
  REG_DEAD r105:V4SI
   16: [r102:DI+0x20]=r106:V4SI
  REG_DEAD r106:V4SI
   18: [r102:DI+0x30]=r107:V4SI

the RTL then stays mostly unchanged until sched1, where things really start to
go downhill:

   11: r104:V4SI=[sfp:DI-0x40]
9: r102:DI=sfp:DI-0x80
   13: r105:V4SI=[r101:DI+0x10]
   20: x0:DI=r102:DI
  REG_DEAD r102:DI
  REG_EQUAL sfp:DI-0x80
   15: r106:V4SI=[r101:DI+0x20]
   12: [sfp:DI-0x80]=r104:V4SI
  REG_DEAD r104:V4SI
   17: r107:V4SI=[r101:DI+0x30]
  REG_DEAD r101:DI
   14: [r102:DI+0x10]=r105:V4SI
  REG_DEAD r105:V4SI
   16: [r102:DI+0x20]=r106:V4SI
  REG_DEAD r106:V4SI
   18: [r102:DI+0x30]=r107:V4SI

here the first of the stores (i12) has been moved up between the last pair of
loads (i15, i17).  Now the interesting thing is how sched1 knows that it is
safe to perform this transformation.  In the ldp_fusion1 pass we miss this pair
because we think that the loads may alias with i12:

cannot form pair (15,17) due to alias conflicts (12,12)

so it would be good to look into how our alias analysis differs from what
sched1 is doing.  It's worth further noting that while the loads have MEM_EXPR
information (they point to the var_decl for s) the stores do not.  Presumably
this is because the copy of s mandated by the ABI doesn't necessarily have a
tree decl representation that the MEM_EXPRs could point to.

Separately to the aliasing issue, because:
 - there is no MEM_EXPR information for the stores, and
 - forwprop1 substituted the sfp in for the first store
ldp_fusion fails to discover the (i12,i14) store pair opportunity.  As a result
we unfortunately end up forming an stp in the middle.

Interestingly if I turn off fwprop1 then we still fail to form the
(12,14) pair due to aliasing.

So it seems the main thing to investigate is how sched1 does its alias
analysis and how that differs from what we're doing in ldp_fusion.

I have some WIP patches that should improve the pair discovery and could
potentially be extended to help with the case of the (12,14) pair here.
Another thing that could help with that is if we populated the MEM_EXPR for the
stores of the structure copy.

[Bug middle-end/114855] ICE: Segfault

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #8 from Andrew Macleod  ---
(In reply to Andrew Macleod from comment #7)
> LOoks like the primary culprits now are:
> 
> dominator optimization : 666.73 (  7%)   0.77 (  2%) 671.76 ( 
> 7%)   170M (  4%)
> backwards jump threading   :7848.77 ( 85%)  21.04 ( 65%)7920.05 (
> 85%)  1332M ( 29%)
> 
> TOTAL  :9250.99 32.58   9341.40 
> 4619M

If I turn off threading, then VRP opps up with 400, so I took a look at VRP.

The biggest problem is that this testcase has on the order of 400,000 basic
blocks, with a pattern of a block of code followed by a lot of CFG diamonds
using a number of differense ssa-names from within the block over and over.  
When we are calculating /storing imports and exports for every block, then
utilizing that info to try to find outgoing ranges that maybe we can use, it
simply adds up.

For VRP, we currently utilize different cache models depoending on the number
of block.. Im wondering if maybe this might not be a good testcase to actually
use a different VRP when the number of block are excessive.  I wroite the fast
VRP pass last year, which currently isnt being used.  I'm goign to experiment
with it to see if we turn it on for CFGs that above a threasdhold (100,000 BB?
), we enable the lower overhead fast VRP instead for all VRP passes. 

The threading issue probably needs to have some knobs added or tweaked for such
very large BBs. there would be a LOT of threading opportunities in the code I
saw, so I can see why it would be so busy.  I saw a lot fo branches to branches
using the same SSA_NAMe.

[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register

[mdoucha at suse dot cz via Gcc-bugs]

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

--- Comment #4 from Martin Doucha  ---
(In reply to Andrew Pinski from comment #3)
> I think most embedded targets use a flat memory system even on x86_64. I
> really think you are barking up the wrong tree on getting this implemented
> in GCC (or even LLVM) because of the complexity of tracking the memory.

x86_64 targets have no choice about using flat memory because segment limits
are ignored by hardware in long mode. This issue is 32bit only.

> It is not just about adding ds for ebp accesses.

As far as I can tell, EBP and ESP are the only registers that default to stack
segment. What else would be needed?

> Maybe the easiest fix is to use -fno-omit-frame-pointer to force always the
> use of EBP as stack accesses only.

That's the first thing I've tried and it didn't help. I had to use -ffixed-ebp
as a workaround but that results in a worse performance penalty than prefixes.

[Bug target/114991] [14/15 Regression] AArch64: LDP pass does not handle some structure copies

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #3 from Alex Coplan  ---
Mine for the aliasing issues/investigation, might be worth splitting off the RA
problem to track that separately.

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
  Component|c   |rtl-optimization
   Keywords||ra
Summary|LRA: PR114810 fix result in |[15 Regression] LRA:
   |ICE in the RISC-V Vector|PR114810 fix result in ICE
   ||in the RISC-V Vector

[Bug target/115010] m68k: invalid subl instruction generated

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||m68k-linux-gnu
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-09

--- Comment #3 from Andrew Pinski  ---
Can you attach the preprocessed source of tree-data-ref.ii ?  That will remove
the second/third steps (andd needing a libc)?

This is mentioned in https://gcc.gnu.org/bugs/ after all.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

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

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

--- Comment #9 from David Edelsohn  ---
The patch in comment 6 succeeds for me, but it seems more of a heavy-handed
band-aid that confirms the symptom, but covers up the problem.

Something in GCC apparently has generated invalid IR that was not caught
earlier.  GCC should not generate

POINTER = POINTER CMP POINTER

But the trunk should not be left in a broken state as per GCC development
policy.  The broken trunk interferes with the work of other developers and may
mask other broken patches being committed.

This patch should be reverted until the source of the problem is discovered and
fixed.

[Bug tree-optimization/115005] [gcc-13] bogus -Warray-bounds warning

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

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

--- Comment #2 from Andrew Pinski  ---
Folding statement: _336 = cmd_8bits[numbits_181];
Folded into: _336 = cmd_8bits[4294967295];


Which comes from:

uint32 d = get_bits(in, numbits+1, &bb);

if (d >= cmd_8bits[numbits]) {

get_bits:
static uint32 get_bits(HIO_HANDLE *f, int n, struct bit_buffer *bb)
{
uint32 bits;

if (n == 0) {
return 0;
}

There is a jump threading there handling n==0 (aka numbits==-1u) and that is
causing the warning. Now if I understand it numbits can't be more than 128 (or
even 16 in the 16bit case).

Adding `if (numbits >= 128) __builtin_unreachable();` right before the git_bits
gets rid of the warning and seems like would produce better code.

The reason why using smaller types works is well (numbits+1) can never be 0.

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #4 from Thorsten Otto  ---
Created attachment 58150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58150&action=edit
preprocessed source & assembler output of tree-data-ref.cc

[Bug target/115010] m68k: invalid subl instruction generated

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug target/115010] m68k: invalid subl instruction generated

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #5 from Sam James  ---
(In reply to Thorsten Otto from comment #4)
> Created attachment 58150 [details]
> preprocessed source & assembler output of tree-data-ref.cc

You should be able to reduce this with cvise if you're willing.

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

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

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

--- Comment #1 from Andrew Pinski  ---
Note this works with the IR coming out of the C front-end but NOT the IR coming
out from the C++ front-end.

Yes the front-ends are different.

[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Vladimir Makarov
:

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

commit r13-8740-ge30211cb0b3a2b88959e9bc40626a17461de52de
Author: Vladimir N. Makarov 
Date:   Thu Apr 4 16:04:04 2024 -0400

[PR114415][scheduler]: Fixing wrong code generation

  For the test case, the insn scheduler (working for live range
shrinkage) moves insns modifying stack memory before an insn reserving
the stack memory. Comments in the patch contains more details about
the problem and its solution.

gcc/ChangeLog:

PR rtl-optimization/114415
* sched-deps.cc (add_insn_mem_dependence): Add memory check for mem
argument.
(sched_analyze_1): Treat stack pointer modification as memory read.
(sched_analyze_2, sched_analyze_insn): Add memory guard for
processing pending_read_mems.
* sched-int.h (deps_desc): Add comment to pending_read_mems.

gcc/testsuite/ChangeLog:

PR rtl-optimization/114415
* gcc.target/i386/pr114415.c: New test.

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #6 from Thorsten Otto  ---
Oh, yes, of course.

command line that failed:
m68k-atari-mint-g++-14.1.0 -m68020-60 "-fno-PIE" "-c" "-O2"
"-fomit-frame-pointer" "-DIN_GCC" "-fno-exceptions" "-fno-rtti"
"-fasynchronous-unwind-tables" "-W" "-Wall" "-Wno-narrowing" "-Wwrite-strings"
"-Wcast-qual" "-Wmissing-format-attribute" "-Wconditionally-supported"
"-Woverloaded-virtual" "-pedantic" "-Wno-long-long" "-Wno-variadic-macros"
"-Wno-overlength-strings" "-DHAVE_CONFIG_H" "-fno-PIE" "-I." "-I."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcpp/include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcody"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber/dpd"
"-I../libdecnumber" "-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libbacktrace"
"-o" "tree-data-ref.o" "-save-temps"
"/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc"

(where /home/sebilla/m68k-atari-mint-gcc is the source directory of the repo)

The original cross-compiler (m68k-atari-mint-g++-14.1.0) was configured with:

/home/sebilla/m68k-atari-mint-gcc/configure --target=m68k-atari-mint
--build=x86_64-suse-linux-gnu --prefix=/usr --libdir=/usr/lib64
--bindir=/usr/bin --libexecdir='' 'CFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer
-include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h' CFLAGS='-O2
-fomit-frame-pointer -include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h'
'CXXFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer ' CXXFLAGS='-O2
-fomit-frame-pointer' 'BOOT_CFLAGS=-O2 -fomit-frame-pointer'
'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_TARGET=-O2
-fomit-frame-pointer' LDFLAGS_FOR_BUILD= LDFLAGS= GNATMAKE_FOR_HOST=gnatmake-14
GNATBIND_FOR_HOST=gnatbind-14 GNATLINK_FOR_HOST=gnatlink-14
--with-pkgversion='MiNT 20240507' --disable-libcc1 --disable-werror
--with-gxx-include-dir=/usr/m68k-atari-mint/sys-root/usr/include/c++/14
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-gcc-major-version-only
--with-gcc --with-gnu-as --with-gnu-ld --with-system-zlib
--without-static-standard-libraries --without-stage1-ldflags --disable-libgomp
--without-libatomic --without-newlib --disable-libstdcxx-pch --disable-threads
--disable-win32-registry --disable-lto --enable-ssp --enable-libssp
--disable-plugin --disable-decimal-float --disable-nls
--with-libiconv-prefix=/usr --with-libintl-prefix=/usr
--with-sysroot=/usr/m68k-atari-mint/sys-root
--enable-languages=c,c++,fortran,ada,d,m2

The compiler that i'm trying to build was configured with:

'--target=m68k-atari-mint' '--host=m68k-atari-mint'
'--build=x86_64-suse-linux-gnu' '--prefix=/usr' '--libdir=/usr/lib'
'--bindir=/usr/bin' '--libexecdir=${libdir}' '--with-pkgversion=MiNT 20240507'
'--disable-libcc1' '--disable-werror'
'--with-gxx-include-dir=/usr/include/c++/14'
'--with-libstdcxx-zoneinfo=/usr/share/zoneinfo' '--with-gcc-major-version-only'
'--with-gcc' '--with-gnu-as' '--with-gnu-ld' '--with-system-zlib'
'--disable-libgomp' '--without-newlib' '--disable-libstdcxx-pch'
'--disable-threads' '--disable-win32-registry' '--disable-lto' '--enable-ssp'
'--enable-libssp' '--disable-plugin' '--disable-decimal-float' '--disable-nls'
'--with-cpu=m68020-60' '--with-build-sysroot=/usr/m68k-atari-mint/sys-root'
'build_alias=x86_64-suse-linux-gnu' 'host_alias=m68k-atari-mint'
'target_alias=m68k-atari-mint' 'CC=m68k-atari-mint-gcc-14.1.0 -m68020-60'
'CFLAGS=-O2 -fomit-frame-pointer' 'LDFLAGS=-Wl,-stack,512k'
'CXX=m68k-atari-mint-g++-14.1.0 -m68020-60' 'CXXFLAGS=-O2 -fomit-frame-pointer'
'CC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'CXX_FOR_TARGET=m68k-atari-mint-g++-14.1.0'
'GCC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'GFORTRAN_FOR_TARGET=m68k-atari-mint-gfortran-14.1.0'
'GOC_FOR_TARGET=m68k-atari-mint-goc-14.1.0'
'AS_FOR_TARGET=/home/sebilla/mintstd/binary7-package/usr/bin/m68k-atari-mint-as'
'RANLIB_FOR_TARGET=m68k-atari-mint-ranlib'
'STRIP_FOR_TARGET=m68k-atari-mint-strip' '--enable-languages=c,c++'

compiler output was:

/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
siv_subscript_p(const_tree, const_tree)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3587:15: warning: this
statement may fall through [-Wimplicit-fallthrough=]
 3587 |   if (CHREC_VARIABLE (chrec_a) != CHREC_VARIABLE (chrec_b))
  |   ^~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3591:13: note: here
 3591 | default:
  | ^~~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
get_references_in_stmt(gimple*, vec*)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:5888:25: warning: this
statement may fall through [-Wimplicit-fallthrough=]
 5888 | ref.is_read = true;
  | ^~
/home/sebilla/m68k-atari-mint-gcc

[Bug c++/85889] lambda expression can capture structured bindings

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

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

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

https://gcc.gnu.org/g:46bafd9a6b9b776142e0b1424a6ac02e3a2fd300

commit r15-348-g46bafd9a6b9b776142e0b1424a6ac02e3a2fd300
Author: Marek Polacek 
Date:   Fri Mar 1 17:13:02 2024 -0500

c++: lambda capturing structured bindings [PR85889]

 clarifies that it's OK to capture structured
bindings.

[expr.prim.lambda.capture]/4 says "The identifier in a simple-capture shall
denote a local entity" and [basic.pre]/3: "An entity is a [...] structured
binding".

It doesn't appear that this was made a DR, so, strictly speaking, we
should have a -Wc++20-extensions warning, like clang++.

PR c++/85889

gcc/cp/ChangeLog:

* lambda.cc (add_capture): Add a pedwarn for capturing structured
bindings.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/decomp3.C: Use -Wno-c++20-extensions.
* g++.dg/cpp1z/decomp60.C: New test.