[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988 --- Comment #11 from Richard Biener --- (In reply to Alexandre Oliva from comment #9) > ISTM that the test invokes undefined behavior because the assignment and the > increment in the loop both modify the same storage without an intervening > sequence point. ISTM that the dynamic type of that storage is thus > uncertain, and accessing it afterwards, without an intervening store that > resolves its type either way, would also invoke undefined behavior. I think the source can be rewritten to *b = x; b++; and still show the original issue on the GIMPLE side.
[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 --- Comment #5 from GCC Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:7af0f1e107a480fbfe882cb985603960114aefb5 commit r14-9023-g7af0f1e107a480fbfe882cb985603960114aefb5 Author: Kito Cheng Date: Fri Jan 19 10:29:10 2024 +0800 RISC-V: Add new option -march=help to print all supported extensions The output of -march=help is like below: ``` All available -march extensions for RISC-V: NameVersion i 2.0, 2.1 e 2.0 m 2.0 a 2.0, 2.1 f 2.0, 2.2 d 2.0, 2.2 ... ``` Also support -print-supported-extensions and --print-supported-extensions for clang compatibility. gcc/ChangeLog: PR target/109349 * common/config/riscv/riscv-common.cc (riscv_arch_help): New. * config/riscv/riscv-protos.h (RISCV_MAJOR_VERSION_BASE): New. (RISCV_MINOR_VERSION_BASE): Ditto. (RISCV_REVISION_VERSION_BASE): Ditto. * config/riscv/riscv-c.cc (riscv_ext_version_value): Use enum rather than magic number. * config/riscv/riscv.h (riscv_arch_help): New. (EXTRA_SPEC_FUNCTIONS): Add riscv_arch_help. (DRIVER_SELF_SPECS): Handle -march=help, -print-supported-extensions and --print-supported-extensions. * config/riscv/riscv.opt (march=help): New. (print-supported-extensions): New. (-print-supported-extensions): New. * doc/invoke.texi (RISC-V Options): Document -march=help. Reviewed-by: Christoph Müllner
[Bug target/63672] xbegin/xend/xabort missing memory barriers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63672 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-16 Status|UNCONFIRMED |NEW Keywords||wrong-code Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- This patch was never applied, though I am not 100% sure it even matters as x86 RTM is not really used anywhere.
[Bug middle-end/36109] GET_MODE_SIZE is inefficient for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36109 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |5.0 Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed by r5-128-g92f0f3ec9210d5 .
[Bug middle-end/53103] bug locating unsigned type for non-standard precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53103
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |4.8.0
--- Comment #2 from Andrew Pinski ---
unsigned_type_for/signed_type_for was actally fixed on the trunk, a month
before this bug report was filed, by r0-115650-g7ee6fd6836b487 .
I tested:
```
__int24 xi;
__int24 addit () { xi += 0x54321L; }
```
On AVR and it has worked at least since GCC 5 when __int24 was added.
[Bug tree-optimization/106615] redundant load and store introduced in if-true-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106615
--- Comment #2 from absoler at smail dot nju.edu.cn ---
(In reply to Andrew Pinski from comment #1)
> Reduced testcase:
> int g_44;
>
> void func_16(int *a, unsigned long int b) {
> *a = 5;
> if ((g_44 = 1) <= b)
> ;
> else
> *a = 0;
> }
>
> CUT
> So CSElim on the gimple level goes from:
>
> *a_3(D) = 5;
> g_44 = 1;
> if (b_6(D) != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870913]:
> *a_3(D) = 0;
>
>[local count: 1073741824]:
> return;
>
> to:
>
> *a_3(D) = 5;
> g_44 = 1;
> if (b_6(D) != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870912]:
> cstore_8 = MEM [(void *)a_3(D)];
>
>[local count: 1073741824]:
> # cstore_9 = PHI
> MEM [(void *)a_3(D)] = cstore_9;
>
> Thinking it might be able to remove the load inside the if branch (for an
> example at -O2 with 1 instead of 5, GCC can remove the load).
> And then nothing afterwards will undo that transformation.
Now I found a similar interesting case. It will introduce redundant load
on gcc-13.2.0 with "-O2 -ffinite-loops" but not with only "-O1", while it can
be triggered on gcc-12.2.0 with only "-O2" flag.
source:
```
int g_4[1][1][1] = {{{1L}}};
int g_80 = 0L;
int g_161 = 0x37FF6474L;
int *g_160 = _161;
int **g_159 = _160;
char f;
void func_1() {
int *a[4];
int b = 0, c;
for (; b < 4; b++)
a[b] = (int *)g_4;
*a[3] |= 6;
**g_159 = g_80;
int d[1][1];
unsigned e;
for (b = 0; b < 1; b++)
for (c = 0; c < 1; c++)
d[b][c] = e;
if (0 > f)
*a[3] = 0;
}
```
problematic binary generated by gcc-13.2.0 -O2 -ffinite-loops, or gcc-12.2.0
-O2
```
004016e0 :
func_1():
4016e0: mov0x29c9(%rip),%rax# 4040b0
4016e7: mov0x105bb(%rip),%edx# 411ca8
/root/myCSmith/test/output2.c:42
4016ed: orl$0x6,0x29ec(%rip)# 4040e0
/root/myCSmith/test/output2.c:43
4016f4: mov(%rax),%rax
4016f7: mov%edx,(%rax)
/root/myCSmith/test/output2.c:50
4016f9: xor%eax,%eax
/root/myCSmith/test/output2.c:49
4016fb: cmpb $0x0,0x2992(%rip)# 404094
401702: js 40170a
/root/myCSmith/test/output2.c:50
401704: mov0x29d6(%rip),%eax# 4040e0
40170a: mov%eax,0x29d0(%rip)# 4040e0
/root/myCSmith/test/output2.c:51
401710: retq
401711: data16 nopw %cs:0x0(%rax,%rax,1)
40171c: nopl 0x0(%rax)
```
better binary generated by gcc-13.2.0 -O2:
```
00401470 :
func_1():
/root/myCSmith/test/output2.c:41
401470: mov0x2be9(%rip),%rax# 404060
401477: mov0x1072f(%rip),%edx# 411bac
/root/myCSmith/test/output2.c:40
40147d: orl$0x6,0x2bf0(%rip)# 404074
/root/myCSmith/test/output2.c:47
401484: cmpb $0x0,0x1071d(%rip)# 411ba8
/root/myCSmith/test/output2.c:41
40148b: mov(%rax),%rax
40148e: mov%edx,(%rax)
/root/myCSmith/test/output2.c:47
401490: js 401498
/root/myCSmith/test/output2.c:49
401492: retq
401493: nopl 0x0(%rax,%rax,1)
/root/myCSmith/test/output2.c:48
401498: movl $0x0,0x2bd2(%rip)# 404074
/root/myCSmith/test/output2.c:49
4014a2: retq
4014a3: data16 nopw %cs:0x0(%rax,%rax,1)
4014ae: xchg %ax,%ax
```
[Bug target/19799] sibcall-3.c and sibcall-4.c xfailed on hppa64-*-hpux*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19799 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail, xfail Last reconfirmed|2006-01-15 20:40:09 |2024-2-15 --- Comment #9 from Andrew Pinski --- hppa*64*-*-* is still there.
[Bug middle-end/48504] Add Variable Length Array (VLA) support for -fstack-protector(-all)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48504 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- -fstack-protector has worked for VLA since at least GCC 4.1.2 (which was released in 2007). So closing as works for me.
[Bug target/45335] Use ldrd to load two consecutive words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45335
Andrew Pinski changed:
What|Removed |Added
Known to work||14.0, 7.3.0
Status|NEW |RESOLVED
Resolution|--- |FIXED
Known to fail||4.6.4, 5.4.0
Target Milestone|--- |7.0
--- Comment #2 from Andrew Pinski ---
6.3.0 produced:
sub r1, r4, #16
ldr r4, [r4, #-4]
ldr r0, .L3+4
ldm r1, {r1, r2, r3}
5.4.0 produced:
sub r1, r4, #16
ldr r4, [r4, #-4]
ldr r0, .L3+4
ldmia r1, {r1, r2, r3}
7.40 produced:
ldrdr2, r3, [r4, #-12]
ldr r1, [r4, #-16]
ldrdr4, r5, [r4, #-4]
ldr r0, .L4+4
strdr4, r5, [sp]
Which was changed by r7-4653-g2fe3721128b991 or r7-991-g37923729c5ab01 .
The ldrd support was added originally with r0-122648-g4542a38a21fea5 (for GCC
4.9.0).
So closing as fixed.
[Bug middle-end/33780] different results between O3 and O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33780 --- Comment #7 from Andrew Pinski --- I can only reproduce this these days on 32bit x86 when x87 is in use ...
[Bug testsuite/12010] g++.exp and libstdc++.exp fail to find testsuite_flags when cross-compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12010 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |3.4.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Actually this was fixed with r0-46571-ga15791b0c9f8ab in GCC 3.4.0. And then r0-50801-g7dfa28ba07d486 removed the non-v3 related changes too. The patch was not needed when it was posted nor it was needed for a GCC 3.4.0.
[Bug target/113955] New: Finish LRA transition for mips by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955 Bug ID: 113955 Summary: Finish LRA transition for mips by removing -mlra Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: syq at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please complete the port to LRA (see PR113932) by dropping -mlra and always using it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113954] New: Finish LRA transition for arc by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954 Bug ID: 113954 Summary: Finish LRA transition for arc by removing -mlra Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: amylaar at gcc dot gnu.org, claziss at gmail dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please complete the port to LRA (see PR113932) by dropping -mlra and always using it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113953] New: Finish LRA transition for s390 by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953 Bug ID: 113953 Summary: Finish LRA transition for s390 by removing -mlra Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: krebbel at gcc dot gnu.org, uweigand at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please complete the port to LRA (see PR113932) by dropping -mlra and always using it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113952] New: Finish LRA transition for sparc by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113952 Bug ID: 113952 Summary: Finish LRA transition for sparc by removing -mlra Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: davem at davemloft dot net, ebotcazou at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please complete the port to LRA (see PR113932) by dropping -mlra and always using it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/50774] Internal Compiler Error when march=bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50774 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Target Milestone|--- |4.9.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Can't reproduce for a long time so closing.
[Bug target/113780] [ARM] Incorrect indirect tailcall generated for PAC-enabled function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780 Tejas Belagod changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Tejas Belagod --- Fixed on trunk
[Bug target/113780] [ARM] Incorrect indirect tailcall generated for PAC-enabled function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780 --- Comment #3 from GCC Commits --- The master branch has been updated by Tejas Belagod : https://gcc.gnu.org/g:f436a2ab6ad15968275c9bbf3bd56647e5559e68 commit r14-9022-gf436a2ab6ad15968275c9bbf3bd56647e5559e68 Author: Tejas Belagod Date: Thu Jan 25 16:05:36 2024 +0530 Arm: Fix incorrect tailcall-generation for indirect calls [PR113780] This patch fixes a bug that causes indirect calls in PAC-enabled functions to be tailcalled incorrectly when all argument registers R0-R3 are used. 2024-02-07 Tejas Belagod PR target/113780 * config/arm/arm.cc (arm_function_ok_for_sibcall): Don't allow tailcalls for indirect calls with 4 or more arguments in pac-enabled functions. * lib/target-supports.exp (v8_1m_main_pacbti): Add __ARM_FEATURE_PAUTH. * gcc.target/arm/pac-sibcall.c: New.
[Bug target/113951] New: regression redundant load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113951
Bug ID: 113951
Summary: regression redundant load
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
Hi, here's the code:
```
typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef signed short int int16_t;
typedef unsigned short int uint16_t;
typedef signed int int32_t;
typedef unsigned int uint32_t;
typedef signed long int int64_t;
typedef unsigned long int uint64_t;
struct S1 {
uint64_t f0;
uint64_t f1;
uint32_t f2;
};
/* --- GLOBAL VARIABLES --- */
int32_t g_5 = 0xB779C63CL;
struct S1 g_441 = {0x387DADCAC0CA1ED2LL,18446744073709551606UL,4294967295UL};
uint16_t g_558 = 65534UL;
int32_t *g_560 = _5;
struct S1 *g_677 = _441;
uint32_t g_740 = 0UL;
struct S1 g_752 = {0UL,0xD68240D217006E9ALL,4294967295UL};
int f = 1;
int c;
void func_1() {
int32_t b[1];
if (g_5) {
int32_t **d = _560;
if (g_558) {
*d = g_560;
**d = 0;
} else {
int32_t e = (int)b;
g_677 = _441;
}
} else {
uint32_t f[5];
b[0] = (int)f;
}
if (f)
for (; c; c++)
g_740--;
*g_677 = g_752;
}
```
with -O2 flag, gcc-11.2.0 and gcc-13.2.0 with an extra option
"-fschedule-insns" can both generate the same following binary code:
```
00401680 :
func_1():
/root/myCSmith/test/output2.c:52
401680: mov0x2a4e(%rip),%ecx# 4040d4
/root/myCSmith/test/output2.c:68
401686: mov0x29fb(%rip),%rax# 404088
/root/myCSmith/test/output2.c:52
40168d: test %ecx,%ecx
40168f: je 4016af
/root/myCSmith/test/output2.c:54
401691: cmpw $0x0,0x29ff(%rip)# 404098
401699: je 4016f0
/root/myCSmith/test/output2.c:56
40169b: mov0x29ee(%rip),%rdx# 404090
/root/myCSmith/test/output2.c:68
4016a2: mov0x29df(%rip),%rax# 404088
/root/myCSmith/test/output2.c:56
4016a9: movl $0x0,(%rdx)
/root/myCSmith/test/output2.c:65
4016af: mov0x29ab(%rip),%edx# 404060
4016b5: test %edx,%edx
4016b7: je 4016d3
/root/myCSmith/test/output2.c:66 (discriminator 1)
4016b9: mov0x10549(%rip),%edx# 411c08
4016bf: test %edx,%edx
4016c1: je 4016d3
4016c3: add%edx,0x10543(%rip)# 411c0c
4016c9: movl $0x0,0x10535(%rip)# 411c08
/root/myCSmith/test/output2.c:68
4016d3: movdqa 0x2995(%rip),%xmm0# 404070
4016db: movups %xmm0,(%rax)
4016de: mov0x299b(%rip),%rdx# 404080
4016e5: mov%rdx,0x10(%rax)
/root/myCSmith/test/output2.c:69
4016e9: retq
4016ea: nopw 0x0(%rax,%rax,1)
/root/myCSmith/test/output2.c:59
4016f0: movq $0x4040a0,0x298d(%rip)# 404088
4016fb: mov$0x4040a0,%eax
401700: jmp4016af
401702: data16 nopw %cs:0x0(%rax,%rax,1)
40170d: nopl (%rax)
```
we can see g_677 has been load repeatedly both at 0x401686 and 0x4016a2 at
runtime, it's not necessary
[Bug c++/110894] [modules] Program terminates with signal SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 Bug 110894 depends on bug 109953, which changed state. Bug 109953 Summary: [c++modules] segmentation fault with import "functional" during program execution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109953 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/109953] [c++modules] segmentation fault with import "functional" during program execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109953 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #2 from Nathaniel Shead --- Looks to be fixed on GCC 14 trunk.
[Bug c++/110894] [modules] Program terminates with signal SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 Nathaniel Shead changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nshead at gcc dot gnu.org Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #4 from Nathaniel Shead --- Looks to be fixed on GCC 14 trunk.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 110894, which changed state. Bug 110894 Summary: [modules] Program terminates with signal SIGSEGV https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 Peter Bergner changed: What|Removed |Added Last reconfirmed||2024-02-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Peter Bergner --- Confirmed.
[Bug target/113950] New: PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
Bug ID: 113950
Summary: PowerPC, ICE with -O1 or higher compiling
__builtin_vsx_splat_2di test case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carll at gcc dot gnu.org
Target Milestone: ---
Power 10 LE
Fedora 38
Test of the __builtin_vsx_splat_2di ICEs on GCC 12 and later.
The following test case generates an ICE for -O1 and above. It does work for
-O0.
void abort (void);
int main ()
{
int i;
vector signed long long vsll_result, vsll_expected_result;
signed long long sll_arg1;
sll_arg1 = 300;
vsll_expected_result = (vector signed long long) {300, 300};
vsll_result = __builtin_vsx_splat_2di (sll_arg1); //ISSUE
for (i = 0; i < 2; i++)
if (vsll_result[i] != vsll_expected_result[i])
abort();
return 0;
}
The test case compiles fine with -O0.
Here is the output when I try to compile with -O1:
gcc -g -O1 compiler-bug.c -o compiler-bug
compiler-bug.c: In function ‘main’:
compiler-bug.c:19:1: error: unrecognizable insn:
19 | }
| ^
(insn 14 13 15 2 (set (reg:V2DI 117 [ _1 ])
(vec_duplicate:V2DI (const_int 300 [0x12c]))) "compiler-bug.c":12:17 -1
(nil))
during RTL pass: vregs
compiler-bug.c:19:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source.
See for instructions.
Preprocessed source stored into /tmp/ccnoI5lr.out file, please attach this to
your bugreport.
[Bug tree-optimization/112508] [14 Regression] Size regression when using -Os starting with r14-4089-gd45ddc2c04e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112508 Roger Sayle changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||roger at nextmovesoftware dot com Last reconfirmed||2024-02-15 --- Comment #2 from Roger Sayle --- The issue appears to be with (poor costing in) loop invariant store motion. Adding the command line option "-fno-move-loop-stores" reduces the .s file from 149 lines to 54 lines, and the size of main (as reported by objdump -d) from 317 bytes to 73 bytes. To confirm that this isn't specific to this (possibly pathological/obscure) test case, I ran the CSiBE benchmark on x86_64, comparing "-Os" to "-Os -fno-move-loop-stores", which shows a net saving of 1606 bytes with -fno-move-loop-stores. There are cases where -fno-move-loop-stores reduces code size (on x86_64, and I've not investigated other targets), so I guess it would be preferrable to use more accurate size costs instead of just disabling this sub-pass. Note that the bigger hammer, -fno-tree-loop-im, also avoids the code growth, but the more precise/specific -fno-move-loop-stores is sufficient.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #4 from Antoni --- I might be able to soon create a reproducer, but for now, I can say it might be related to __attribute__ ((always_inline)).
[Bug analyzer/111289] [13/14 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289 David Malcolm changed: What|Removed |Added Summary|Unwarranted |[13/14 Regression] |-Wanalyzer-va-arg-type-mism |Unwarranted |atch warning|-Wanalyzer-va-arg-type-mism ||atch warning Ever confirmed|0 |1 Last reconfirmed||2024-02-15 Status|UNCONFIRMED |NEW --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Trunk: https://godbolt.org/z/aK9adEYdT GCC 13.2: https://godbolt.org/z/G1E1o4sbr The warning was introduced in GCC 13 so can't affect earlier releases
[Bug analyzer/111266] [13 Regression] Missing -Wanalyzer-out-of-bounds for concrete offset overwrite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111266 David Malcolm changed: What|Removed |Added Summary|[13/14 Regression] Missing |[13 Regression] Missing |-Wanalyzer-out-of-bounds|-Wanalyzer-out-of-bounds |for concrete offset |for concrete offset |overwrite. |overwrite. Status|NEW |ASSIGNED --- Comment #3 from David Malcolm --- Should be fixed on trunk by the above patch. Keeping open to track backport to gcc 13 branch.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #22 from rguenther at suse dot de ---
> Am 15.02.2024 um 19:53 schrieb tnfchris at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
>
> --- Comment #21 from Tamar Christina ---
> (In reply to Richard Biener from comment #18)
>> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
>> index 7cf9504398c..8deeecfd4aa 100644
>> --- a/gcc/tree-vect-slp.cc
>> +++ b/gcc/tree-vect-slp.cc
>> @@ -1280,8 +1280,11 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
>> *swap,
>>&& rhs_code.is_tree_code ()
>>&& (TREE_CODE_CLASS (tree_code (first_stmt_code))
>>== tcc_comparison)
>> - && (swap_tree_comparison (tree_code (first_stmt_code))
>> - == tree_code (rhs_code)))
>> + && ((swap_tree_comparison (tree_code (first_stmt_code))
>> +== tree_code (rhs_code))
>> + || ((TREE_CODE_CLASS (tree_code (alt_stmt_code))
>> +== tcc_comparison)
>> + && rhs_code == alt_stmt_code)))
>> && !(STMT_VINFO_GROUPED_ACCESS (stmt_info)
>>&& (first_stmt_code == ARRAY_REF
>>|| first_stmt_code == BIT_FIELD_REF
>>
>> should get you SLP but:
>>
>> t.c:8:26: note: === vect_slp_analyze_operations ===
>> t.c:8:26: note: ==> examining statement: pretmp_29 = *_28;
>> t.c:8:26: missed: unsupported load permutation
>> t.c:10:30: missed: not vectorized: relevant stmt not supported: pretmp_29
>> = *_28;
>>
>> t.c:8:26: note: op template: pretmp_29 = *_28;
>> t.c:8:26: note: stmt 0 pretmp_29 = *_28;
>> t.c:8:26: note: stmt 1 pretmp_29 = *_28;
>> t.c:8:26: note: load permutation { 0 0 }
>
> hmm with that applied I get:
>
> sve-mis.c:8:26: note: ==> examining statement: pretmp_29 = *_28;
> sve-mis.c:8:26: note: Vectorizing an unaligned access.
> sve-mis.c:8:26: note: vect_model_load_cost: unaligned supported by hardware.
> sve-mis.c:8:26: note: vect_model_load_cost: inside_cost = 1, prologue_cost =
> 0 .
>
> but it bails out at:
>
> sve-mis.c:8:26: missed: Not using elementwise accesses due to variable
> vectorization factor.
> sve-mis.c:10:25: missed: not vectorized: relevant stmt not supported:
> .MASK_STORE (_5, 8B, _27, pretmp_29);
> sve-mis.c:8:26: missed: bad operation or unsupported loop bound.
>
> for me
I’ve used -fno-cost-model and looked at the SVE variant only.
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.
[Bug analyzer/111266] [13/14 Regression] Missing -Wanalyzer-out-of-bounds for concrete offset overwrite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111266
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:617bd59c659dcf6e5391409a2e9f64f75e905a96
commit r14-9018-g617bd59c659dcf6e5391409a2e9f64f75e905a96
Author: David Malcolm
Date: Thu Feb 15 16:01:36 2024 -0500
analyzer: remove offset_region size overloads [PR111266]
PR analyzer/111266 reports a missing -Wanalyzer-out-of-bounds when
accessing relative to a concrete byte offset.
Root cause is that offset_region::get_{byte,bit}_size_sval were
attempting to compute the size that's valid to access, rather than the
size of the access attempt.
Fixed by removing these vfunc overrides from offset_region as the
base class implementation does the right thing.
gcc/analyzer/ChangeLog:
PR analyzer/111266
* region.cc (offset_region::get_byte_size_sval): Delete.
(offset_region::get_bit_size_sval): Delete.
* region.h (region::get_byte_size): Add comment clarifying that
this relates to the size of the access, rather than the size
that's valid to access.
(region::get_bit_size): Likewise.
(region::get_byte_size_sval): Likewise.
(region::get_bit_size_sval): Likewise.
(offset_region::get_byte_size_sval): Delete.
(offset_region::get_bit_size_sval): Delete.
gcc/testsuite/ChangeLog:
PR analyzer/111266
* c-c++-common/analyzer/out-of-bounds-pr111266.c: New test.
Signed-off-by: David Malcolm
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 --- Comment #1 from dave.anglin at bell dot net --- On 2024-02-15 2:01 p.m., sjames at gcc dot gnu.org wrote: > People are getting eager to require LRA. Please port the PA target to LRA (see > PR113932). Having tried this once, I know it's non trivial on PA.
[Bug target/113949] Switch vax to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113949 Maciej W. Rozycki changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |macro at orcam dot me.uk Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |15.0 Last reconfirmed||2024-02-15 --- Comment #1 from Maciej W. Rozycki --- Scheduled for GCC 15 (but the EH unwinder needs to be fixed first).
[Bug target/113778] ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1506 with -march=armv9-a+sme -fhardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113778 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-02-15 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from Richard Sandiford --- Possibly the same as PR113220
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 107191, which changed state. Bug 107191 Summary: [modules] ICE when importing module partition (internal compiler error: in tree_node, at cp/module.cc:9061) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/107191] [modules] ICE when importing module partition (internal compiler error: in tree_node, at cp/module.cc:9061)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- GCC 14 no longer ICEs.
[Bug target/113947] Switch pdp11 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113947 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-15 Ever confirmed|0 |1
[Bug c++/99336] [modules] ICE combining unordered_map, memory, module partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99336 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |13.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Patrick Palka --- This ICE seems gone since GCC 13.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 99336, which changed state. Bug 99336 Summary: [modules] ICE combining unordered_map, memory, module partitions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99336 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/111229] -fanalyzer confused about conditional operator branch name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111229 --- Comment #1 from David Malcolm --- Thanks for filing this. Probably a duplicate of PR 100116.
[Bug analyzer/110014] [13 Regression] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/109577] [13 Regression] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/112974] [14 Regression] -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112974 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug analyzer/112975] [14 Regression] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's drivers/xen/privcmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112975 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-15
[Bug analyzer/110928] [14 Regression] ICE with -fanalyzer on -Wanalyzer-out-of-bounds checker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110928 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-02-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug analyzer/109131] [13/14 Regression] -Wanalyzer-deref-before-check false positive seen in git's builtin/show-ref.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109131 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-15
[Bug c++/113930] [modules] checking ICE in register_duplicate when using partitioned modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930 Patrick Palka changed: What|Removed |Added Blocks||103524 Summary|[modules] ICE in|[modules] checking ICE in |register_duplicate when |register_duplicate when |using partitioned modules |using partitioned modules Status|UNCONFIRMED |NEW Keywords||ice-checking, ||ice-on-valid-code Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Last reconfirmed||2024-02-15 --- Comment #1 from Patrick Palka --- Confirmed, we're tripping over a checking-only assert; release builds don't ICE. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug target/113946] Switch ft32 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113946 Sam James changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Sam James --- (In reply to Sam James from comment #1) > ft32 has a maintainer (James Bowman) but I can't find a BZ account for him > to CC. The target was added in commit fef939d6a96bde0f924152e6b9e22701c28f8880 Author: James Bowman AuthorDate: Sat May 16 23:49:08 2015 + Commit: James Bowman CommitDate: Sat May 16 23:49:08 2015 + FT32 target added. Approved by Jeff Law [l...@redhat.com] From-SVN: r223261 CCing Jeff for advice.
[Bug target/113946] Switch ft32 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113946 --- Comment #1 from Sam James --- ft32 has a maintainer (James Bowman) but I can't find a BZ account for him to CC.
[Bug target/113949] New: Switch vax to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113949 Bug ID: 113949 Summary: Switch vax to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: macro at orcam dot me.uk, m...@3am-software.com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the rx target to LRA (see PR113932). There's a -mlra option which is off by default for this target... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113948] New: Switch rx to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113948 Bug ID: 113948 Summary: Switch rx to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: nickc at redhat dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the rx target to LRA (see PR113932). There's a -mlra option which is off by default for this target... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113947] New: Switch pdp11 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113947 Bug ID: 113947 Summary: Switch pdp11 to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: ni1d at arrl dot net Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the pdp11 target to LRA (see PR113932). There's a -mlra option which is off by default for this target... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113946] New: Switch ft32 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113946 Bug ID: 113946 Summary: Switch ft32 to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the ft32 target to LRA (see PR113932). We have -mlra on this target but it is default-off... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 --- Comment #1 from Andrew Pinski --- ft32: Target Var(ft32_lra_flag) Init(0) Save pdp11, rx and vax has a TARGET_MASK which are not turned on by default either.
[Bug target/113945] New: Switch visium to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113945 Bug ID: 113945 Summary: Switch visium to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the visium target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113944] New: Switch rl78 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113944 Bug ID: 113944 Summary: Switch rl78 to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the rl78 target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113943] New: Switch m32c to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113943 Bug ID: 113943 Summary: Switch m32c to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the m32c target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113942] New: Switch msp430 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113942 Bug ID: 113942 Summary: Switch msp430 to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: nickc at redhat dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the msp430 target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113941] New: Switch mn10300 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113941 Bug ID: 113941 Summary: Switch mn10300 to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: aoliva at gcc dot gnu.org, law at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the mn10300 target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113940] New: Switch mcore to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113940 Bug ID: 113940 Summary: Switch mcore to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: nickc at redhat dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the mcore target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113939] New: Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 Bug ID: 113939 Summary: Switch m68k to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: law at gcc dot gnu.org, schwab at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the PA target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #12 from GCC Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:da93a3d0976ad42aa6b4f5742119f3189ea21400 commit r11-11241-gda93a3d0976ad42aa6b4f5742119f3189ea21400 Author: Jakub Jelinek Date: Thu Feb 15 20:04:01 2024 +0100 testsuite: Require lra effective target for pr107385.c Old reload doesn't support asm goto with output operands. We have lra effective target (though, strangely it returns 0 just for 2 targets out of at least 16 targets with no LRA support), so this patch uses it, similarly how it is done in other asm goto tests with output operands. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: Require lra effective target. (cherry picked from commit 0d5d1c75f5c68b6064640c3154ae5f4c0b464905)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7c81fed21c355565182e00bed58375e2f3dcf01c commit r12-10160-g7c81fed21c355565182e00bed58375e2f3dcf01c Author: Jakub Jelinek Date: Thu Feb 15 20:04:01 2024 +0100 testsuite: Require lra effective target for pr107385.c Old reload doesn't support asm goto with output operands. We have lra effective target (though, strangely it returns 0 just for 2 targets out of at least 16 targets with no LRA support), so this patch uses it, similarly how it is done in other asm goto tests with output operands. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: Require lra effective target. (cherry picked from commit 0d5d1c75f5c68b6064640c3154ae5f4c0b464905)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2354ccb493ddca6d2e1af9cc76ad45367932f1e2 commit r13-8330-g2354ccb493ddca6d2e1af9cc76ad45367932f1e2 Author: Jakub Jelinek Date: Thu Feb 15 20:04:01 2024 +0100 testsuite: Require lra effective target for pr107385.c Old reload doesn't support asm goto with output operands. We have lra effective target (though, strangely it returns 0 just for 2 targets out of at least 16 targets with no LRA support), so this patch uses it, similarly how it is done in other asm goto tests with output operands. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: Require lra effective target. (cherry picked from commit 0d5d1c75f5c68b6064640c3154ae5f4c0b464905)
[Bug target/113938] New: Switch frv to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113938 Bug ID: 113938 Summary: Switch frv to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: aoliva at gcc dot gnu.org, nickc at redhat dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the frv target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113937] New: Switch fr30 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113937 Bug ID: 113937 Summary: Switch fr30 to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: nickc at redhat dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the fr30 target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0d5d1c75f5c68b6064640c3154ae5f4c0b464905 commit r14-9017-g0d5d1c75f5c68b6064640c3154ae5f4c0b464905 Author: Jakub Jelinek Date: Thu Feb 15 20:04:01 2024 +0100 testsuite: Require lra effective target for pr107385.c Old reload doesn't support asm goto with output operands. We have lra effective target (though, strangely it returns 0 just for 2 targets out of at least 16 targets with no LRA support), so this patch uses it, similarly how it is done in other asm goto tests with output operands. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: Require lra effective target.
[Bug target/113936] New: Switch c6x to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113936 Bug ID: 113936 Summary: Switch c6x to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: bernds at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the c6x target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113935] New: Switch bfin to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113935 Bug ID: 113935 Summary: Switch bfin to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: jzhang918 at gmail dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the bfin target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113934] New: Switch avr to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934 Bug ID: 113934 Summary: Switch avr to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: chertykov at gmail dot com Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the avr target to LRA (see PR113932). I remember some patch for this on the ML but I don't think it went in. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113933] New: Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 Bug ID: 113933 Summary: Switch pa to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: danglin at gcc dot gnu.org, law at gcc dot gnu.org Blocks: 113932 Target Milestone: --- People are getting eager to require LRA. Please port the PA target to LRA (see PR113932). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 [Bug 113932] [meta-bug] Targets which should be ported to LRA
[Bug target/113932] New: [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 Bug ID: 113932 Summary: [meta-bug] Targets which should be ported to LRA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: segher at gcc dot gnu.org Depends on: 55212, 66207, 90785 Target Milestone: --- LRA is already the default for GCC for quite some time: https://gcc.gnu.org/wiki/LRAIsDefault. The remaining targets are using reload via opt-ins. Please port to LRA as soon as possible, as there's a fair bit of interest in killing reload by this point: https://inbox.sourceware.org/gcc-patches/283c45ca085ced958cbce6e64331252c83a5899f.1682268126.git.seg...@kernel.crashing.org/#t >From jakub: ``` $ grep TARGET_LRA_P.*void_false */*.cc alpha/alpha.cc:#define TARGET_LRA_P hook_bool_void_false avr/avr.cc:#define TARGET_LRA_P hook_bool_void_false bfin/bfin.cc:#define TARGET_LRA_P hook_bool_void_false c6x/c6x.cc:#define TARGET_LRA_P hook_bool_void_false fr30/fr30.cc:#define TARGET_LRA_P hook_bool_void_false frv/frv.cc:#define TARGET_LRA_P hook_bool_void_false ia64/ia64.cc:#define TARGET_LRA_P hook_bool_void_false lm32/lm32.cc:#define TARGET_LRA_P hook_bool_void_false m32c/m32c.cc:#define TARGET_LRA_P hook_bool_void_false m68k/m68k.cc:#define TARGET_LRA_P hook_bool_void_false mcore/mcore.cc:#define TARGET_LRA_P hook_bool_void_false mn10300/mn10300.cc:#define TARGET_LRA_P hook_bool_void_false msp430/msp430.cc:#define TARGET_LRA_P hook_bool_void_false pa/pa.cc:#define TARGET_LRA_P hook_bool_void_false rl78/rl78.cc:#define TARGET_LRA_P hook_bool_void_false visium/visium.cc:#define TARGET_LRA_P hook_bool_void_false ``` Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 [Bug 55212] [SH] Switch to LRA https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207 [Bug 66207] Switch alpha to LRA https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90785 [Bug 90785] [ia64] switch to LRA
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #21 from Tamar Christina ---
(In reply to Richard Biener from comment #18)
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 7cf9504398c..8deeecfd4aa 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -1280,8 +1280,11 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
> *swap,
> && rhs_code.is_tree_code ()
> && (TREE_CODE_CLASS (tree_code (first_stmt_code))
> == tcc_comparison)
> - && (swap_tree_comparison (tree_code (first_stmt_code))
> - == tree_code (rhs_code)))
> + && ((swap_tree_comparison (tree_code (first_stmt_code))
> +== tree_code (rhs_code))
> + || ((TREE_CODE_CLASS (tree_code (alt_stmt_code))
> +== tcc_comparison)
> + && rhs_code == alt_stmt_code)))
>&& !(STMT_VINFO_GROUPED_ACCESS (stmt_info)
> && (first_stmt_code == ARRAY_REF
> || first_stmt_code == BIT_FIELD_REF
>
> should get you SLP but:
>
> t.c:8:26: note: === vect_slp_analyze_operations ===
> t.c:8:26: note: ==> examining statement: pretmp_29 = *_28;
> t.c:8:26: missed: unsupported load permutation
> t.c:10:30: missed: not vectorized: relevant stmt not supported: pretmp_29
> = *_28;
>
> t.c:8:26: note: op template: pretmp_29 = *_28;
> t.c:8:26: note: stmt 0 pretmp_29 = *_28;
> t.c:8:26: note: stmt 1 pretmp_29 = *_28;
> t.c:8:26: note: load permutation { 0 0 }
hmm with that applied I get:
sve-mis.c:8:26: note: ==> examining statement: pretmp_29 = *_28;
sve-mis.c:8:26: note: Vectorizing an unaligned access.
sve-mis.c:8:26: note: vect_model_load_cost: unaligned supported by hardware.
sve-mis.c:8:26: note: vect_model_load_cost: inside_cost = 1, prologue_cost =
0 .
but it bails out at:
sve-mis.c:8:26: missed: Not using elementwise accesses due to variable
vectorization factor.
sve-mis.c:10:25: missed: not vectorized: relevant stmt not supported:
.MASK_STORE (_5, 8B, _27, pretmp_29);
sve-mis.c:8:26: missed: bad operation or unsupported loop bound.
for me
[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #20 from Andrew Pinski ---
(In reply to Barry Revzin from comment #19)
> Another example of this:
>
> int get();
>
> int const& f() {
> int const r = get();
> return r;
> }
>
> int const& g() {
> int const& r = get();
> return r;
> }
>
> gcc trunk warns on the incorrect use in f, but it does not currently warn on
> the incorrect use in g (which is the exact same bug). clang warns on both.
GCC trunk does warn on g but only with optimizations turned on.
[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment #19 from Barry Revzin ---
Another example of this:
int get();
int const& f() {
int const r = get();
return r;
}
int const& g() {
int const& r = get();
return r;
}
gcc trunk warns on the incorrect use in f, but it does not currently warn on
the incorrect use in g (which is the exact same bug). clang warns on both.
[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988 --- Comment #10 from Alexandre Oliva --- Reasoning that the concurrent stores invoke undefined behavior would enable us to assume that the stores don't alias, which invalidates the reasoning in comment 1. Alas, I don't think gimple preserves enough information for us to tell that two statements used to be concurrent so as to derive optimization opportunities from them.
[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #9 from Alexandre Oliva --- ISTM that the test invokes undefined behavior because the assignment and the increment in the loop both modify the same storage without an intervening sequence point. ISTM that the dynamic type of that storage is thus uncertain, and accessing it afterwards, without an intervening store that resolves its type either way, would also invoke undefined behavior.
[Bug analyzer/111802] New analyser diagram failures since commit b365e9d57ad4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111802
--- Comment #2 from Thiago Jung Bauermann
---
Thank you for responding.
Yes, I checked commit 5266f930bed0 ("Daily bump.") from yesterday and it's
still present.
[Bug analyzer/109191] GCC static analyzer does not warning `*b = 1` where `b` is 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from David Malcolm --- Resolving as "INVALID"; feel free to reopen if there's a response to the above questions.
[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791 --- Comment #6 from Marek Polacek --- Stage 1 work. Putting this aside for GCC 15.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #11 from Jerry DeLisle --- Having done all this, I found: C8102 (R868) The namelist-group-name shall not be a name accessed by use association. What does this mean in the context of renamed?
[Bug libstdc++/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 --- Comment #3 from Jonathan Wakely --- Oh but I did rerun that one and still missed the FAIL.
[Bug libstdc++/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Jonathan Wakely changed: What|Removed |Added Component|other |libstdc++ Ever confirmed|0 |1 Keywords||testsuite-fail Target Milestone|--- |14.0 Last reconfirmed||2024-02-15 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jonathan Wakely --- Doh - that's what I get for only rerunning a subset of tests after removing a line.
[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791 --- Comment #5 from Marek Polacek --- Looking. It's https://cplusplus.github.io/CWG/issues/1895.html which we don't implement yet.
[Bug other/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The first line of the static_assert is indeed line 270 rather than 271.
[Bug analyzer/112889] [11/12/13 Regression] ICE with -fanalyzer seen on Linux kernel drivers/infiniband/hw/cxgb4/cm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112889 David Malcolm changed: What|Removed |Added Summary|ICE with -fanalyzer seen on |[11/12/13 Regression] ICE |Linux kernel|with -fanalyzer seen on |drivers/infiniband/hw/cxgb4 |Linux kernel |/cm.c |drivers/infiniband/hw/cxgb4 ||/cm.c --- Comment #4 from David Malcolm --- Bug is at least present but latent on older releases (from gcc 11 onwards)
[Bug analyzer/113496] [12/13/14 Regression] ICE: in cmp, at analyzer/constraint-manager.cc:782 with -fanalyzer -fdump-analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113496 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-15 Summary|ICE: in cmp, at |[12/13/14 Regression] ICE: |analyzer/constraint-manager |in cmp, at |.cc:782 with -fanalyzer |analyzer/constraint-manager |-fdump-analyzer |.cc:782 with -fanalyzer ||-fdump-analyzer --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed; affects gcc 12 onwards: Trunk: https://godbolt.org/z/h11fhE75b GCC 13.2: https://godbolt.org/z/z9Eosesff GCC 12.3: https://godbolt.org/z/GKqcoaPsz Doesn't seem to affect GCC 11.4: https://godbolt.org/z/1qMbxsPEv
[Bug testsuite/113278] analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 --- Comment #4 from GCC Commits --- The master branch has been updated by Torbjorn Svensson : https://gcc.gnu.org/g:8e8c2d2b34971bb29e74341a3efc625f1db06639 commit r14-9015-g8e8c2d2b34971bb29e74341a3efc625f1db06639 Author: Torbjörn SVENSSON Date: Thu Feb 15 17:46:24 2024 +0100 testsuite: Define _POSIX_SOURCE for tests [PR113278] As the tests assume that fileno() is visible (only part of POSIX), define the guard to ensure that it's visible. Currently, glibc appears to always have this defined in C++, newlib does not. Without this patch, fails like this can be seen: Testing analyzer/fileno-1.c, -std=c++98 .../fileno-1.c: In function 'int test_pass_through(FILE*)': .../fileno-1.c:5:10: error: 'fileno' was not declared in this scope FAIL: c-c++-common/analyzer/fileno-1.c -std=c++98 (test for excess errors) Patch has been verified on Linux. gcc/testsuite/ChangeLog: PR testsuite/113278 * c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE. * c-c++-common/analyzer/flex-with-call-summaries.c: Same. * c-c++-common/analyzer/flex-without-call-summaries.c: Same. Signed-off-by: Torbjörn SVENSSON
[Bug other/113931] New: [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Bug ID: 113931 Summary: [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:c9ce332b557bb95987d038d98ea929cdfd1eae1d, r14-8998-gc9ce332b557bb9 make -k check RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc" FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 271) FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) # of expected passes1 # of unexpected failures2 FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) Excess errors: /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:270: error: static assertion failed: template argument must be a floating point type commit c9ce332b557bb95987d038d98ea929cdfd1eae1d (HEAD) Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Use 128-bit arithmetic for std::linear_congruential_engine [PR87744]
[Bug testsuite/113278] analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 Torbjörn SVENSSON changed: What|Removed |Added CC||torbjorn.svensson at foss dot st.c ||om --- Comment #3 from Torbjörn SVENSSON --- Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645731.html
[Bug c++/113929] GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
This is IMHO different, because the grammar is:
template-parameter:
type-parameter
parameter-declaration
parameter-declaration:
attribute-specifier-seq[opt] this[opt] decl-specifier-seq declarator
attribute-specifier-seq[opt] decl-specifier-seq declarator =
initializer-clause
attribute-specifier-seq[opt] this[opt] decl-specifier-seq
abstract-declarator[opt]
attribute-specifier-seq[opt] decl-specifier-seq abstract-declarator[opt] =
initializer-clause
So, unlike the other cases, the grammar allows this specifier in there, just
https://eel.is/c++draft/dcl.fct#6 says it is invalid, because it is not the
first parameter-declaration of a parameter-declaration-list (because it is a
parameter-declaration of a template-parameter-list instead).
I'd go with (on top of PR113802 fix):
2024-02-15 Jakub Jelinek
PR c++/113929
* parser.cc (cp_parser_parameter_declaration): Diagnose this specifier
on template parameter declaration.
* g++.dg/parse/pr113929.C: New test.
--- gcc/cp/parser.cc.jj 2024-02-15 17:33:11.641453437 +0100
+++ gcc/cp/parser.cc2024-02-15 17:40:29.592447265 +0100
@@ -25724,8 +25724,15 @@ cp_parser_parameter_declaration (cp_pars
for a C-style variadic function. */
token = cp_lexer_peek_token (parser->lexer);
- bool const xobj_param_p
+ bool xobj_param_p
= decl_spec_seq_has_spec_p (_specifiers, ds_this);
+ if (xobj_param_p && template_parm_p)
+{
+ error_at (decl_specifiers.locations[ds_this],
+ "% specifier in template parameter declaration");
+ xobj_param_p = false;
+ decl_specifiers.locations[ds_this] = 0;
+}
bool diag_xobj_parameter_pack = false;
if (xobj_param_p && (declarator && declarator->parameter_pack_p))
--- gcc/testsuite/g++.dg/parse/pr113929.C.jj2024-02-15 17:43:18.500129688
+0100
+++ gcc/testsuite/g++.dg/parse/pr113929.C 2024-02-15 17:42:54.564458109
+0100
@@ -0,0 +1,7 @@
+// PR c++/113929
+// { dg-do compile }
+
+template // { dg-error "'this' specifier in template
parameter declaration" }
+struct S {};
+template// { dg-error "'this' specifier in template
parameter declaration" }
+struct T {};
[Bug c++/113930] New: [modules] ICE in register_duplicate when using partitioned modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930
Bug ID: 113930
Summary: [modules] ICE in register_duplicate when using
partitioned modules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickbegg at gmail dot com
Target Milestone: ---
Created attachment 57434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57434=edit
-freport-bug output
/home/nick/gcc-trunk-debug-inst/include/c++/14.0.1/bits/basic_string.h:643:16:
internal compiler error: in register_duplicate, at cp/module.cc:11621
643 | template>
|^~~~
// submod.mpp
module;
#include
export module modA:submod;
// modA.mpp
module;
export module modA;
export import :submod;
// main.cpp
#include
import modA;
std::string test_func() {
return "";
}
Tested with GCC 14 (trunk), git rev bbb30f12a7e5ce008f59ec26c9e4cc65ee79fe56
[Bug target/112575] Segfault in libgccjit due to not cleaning up some target specific cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112575 Antoni changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Antoni --- This patch is not necessary anymore, presumable due to this: "However, as of r14-4003-geaa8e8541349df ggc_common_finalize zeroes everything marked with GTY. The array target_attribute_cache does have a GTY marking, so perhaps as of that commit this patch isn't necessary"
[Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-15 Summary|ICE: SIGSEGV in |[14 Regression] ICE: |tree_class_check|SIGSEGV in tree_class_check |(tree.h:3766) with -O |(tree.h:3766) with -O |-fdump-analyzer -fanalyzer |-fdump-analyzer -fanalyzer --- Comment #1 from David Malcolm --- Confirmed: Trunk: https://godbolt.org/z/hMM5GK9s9 Doesn't affect GCC 13.2
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Should be fixed now for GCC 14.1+, 13.3+, 12.4+ and 11.5.
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #8 from GCC Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a6005ed4f1200ce59501cfadd2d8f558ad90 commit r11-11240-ga6005ed4f1200ce59501cfadd2d8f558ad90 Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test. (cherry picked from commit 5459a9074afabf700f055fc8164f88dadb1c39b0)
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #14 from GCC Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a6e9e70ea88061981c5565c043985d8cde9ecc8 commit r11-11239-g7a6e9e70ea88061981c5565c043985d8cde9ecc8 Author: Jakub Jelinek Date: Thu Feb 15 15:53:01 2024 +0100 expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921] The Linux kernel and the following testcase distilled from it is miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some fixups on some of the edges (but doesn't commit edge insertions). Later expand_asm_stmt emits further instructions on the same edge. Now the problem is that expand_asm_stmt uses insert_insn_on_edge to add its own fixups, but that function appends to the existing sequence on the edge if any. And the bug triggers when the fixup sequence emitted by eliminate_phi uses a pseudo which the fixup sequence emitted by expand_asm_stmt later on sets. So, we end up with (set (reg A) (asm_operands ...)) and on one of the edges queued sequence (set (reg C) (reg B)) // added by eliminate_phi (set (reg B) (reg A)) // added by expand_asm_stmt That is wrong, what we emit by expand_asm_stmt needs to be as close to the asm_operands as possible (they aren't known until expand_asm_stmt is called, the PHI fixup code assumes it is reg B which holds the right value) and the PHI adjustments need to be done after it. So, the following patch introduces a prepend_insn_to_edge function and uses it from expand_asm_stmt, so that we queue (set (reg B) (reg A)) // added by expand_asm_stmt (set (reg C) (reg B)) // added by eliminate_phi instead and so the value from the asm_operands output propagates correctly to the PHI result. 2024-02-15 Jakub Jelinek PR middle-end/113921 * cfgrtl.h (prepend_insn_to_edge): New declaration. * cfgrtl.c (insert_insn_on_edge): Clarify behavior in function comment. (prepend_insn_to_edge): New function. * cfgexpand.c (expand_asm_stmt): Use prepend_insn_to_edge instead of insert_insn_on_edge. * gcc.target/i386/pr113921.c: New test. (cherry picked from commit 2b4efc5db2aedb59196987300e14951d08cd7106)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d2ebd5948bd21f54fdbc5ea99e391be59d0af64c commit r12-10159-gd2ebd5948bd21f54fdbc5ea99e391be59d0af64c Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test. (cherry picked from commit 5459a9074afabf700f055fc8164f88dadb1c39b0)
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #13 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba09da9787e8db8903b2b0f7c647c0d7af68bb74 commit r12-10158-gba09da9787e8db8903b2b0f7c647c0d7af68bb74 Author: Jakub Jelinek Date: Thu Feb 15 15:53:01 2024 +0100 expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921] The Linux kernel and the following testcase distilled from it is miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some fixups on some of the edges (but doesn't commit edge insertions). Later expand_asm_stmt emits further instructions on the same edge. Now the problem is that expand_asm_stmt uses insert_insn_on_edge to add its own fixups, but that function appends to the existing sequence on the edge if any. And the bug triggers when the fixup sequence emitted by eliminate_phi uses a pseudo which the fixup sequence emitted by expand_asm_stmt later on sets. So, we end up with (set (reg A) (asm_operands ...)) and on one of the edges queued sequence (set (reg C) (reg B)) // added by eliminate_phi (set (reg B) (reg A)) // added by expand_asm_stmt That is wrong, what we emit by expand_asm_stmt needs to be as close to the asm_operands as possible (they aren't known until expand_asm_stmt is called, the PHI fixup code assumes it is reg B which holds the right value) and the PHI adjustments need to be done after it. So, the following patch introduces a prepend_insn_to_edge function and uses it from expand_asm_stmt, so that we queue (set (reg B) (reg A)) // added by expand_asm_stmt (set (reg C) (reg B)) // added by eliminate_phi instead and so the value from the asm_operands output propagates correctly to the PHI result. 2024-02-15 Jakub Jelinek PR middle-end/113921 * cfgrtl.h (prepend_insn_to_edge): New declaration. * cfgrtl.cc (insert_insn_on_edge): Clarify behavior in function comment. (prepend_insn_to_edge): New function. * cfgexpand.cc (expand_asm_stmt): Use prepend_insn_to_edge instead of insert_insn_on_edge. * gcc.target/i386/pr113921.c: New test. (cherry picked from commit 2b4efc5db2aedb59196987300e14951d08cd7106)
[Bug middle-end/107385] [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:407b04b59f712ba41d1bcfbf86eba68c52e7917f commit r13-8329-g407b04b59f712ba41d1bcfbf86eba68c52e7917f Author: Jakub Jelinek Date: Thu Feb 15 15:55:25 2024 +0100 testsuite: Add testcase for already fixed PR [PR107385] This testcase has been fixed by the PR113921 fix, but unlike testcase in there this one is not target specific. 2024-02-15 Jakub Jelinek PR middle-end/107385 * gcc.dg/pr107385.c: New test. (cherry picked from commit 5459a9074afabf700f055fc8164f88dadb1c39b0)
