public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c
@ 2024-01-23 15:55 hjl.tools at gmail dot com
2024-01-24 8:13 ` [Bug debug/113562] " rguenth at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: hjl.tools at gmail dot com @ 2024-01-23 15:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Bug ID: 113562
Summary: [14 Regression] FAIL: gcc.dg/guality/pr54796.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
On x86-64, r14-8346 caused:
FAIL: gcc.dg/guality/pr54796.c -O1 -DPREVENT_OPTIMIZATION line 17 a == 5
FAIL: gcc.dg/guality/pr54796.c -O1 -DPREVENT_OPTIMIZATION line 17 b == 6
FAIL: gcc.dg/guality/pr54796.c -O1 -DPREVENT_OPTIMIZATION line 17 c == 5
FAIL: gcc.dg/guality/pr54796.c -O2 -DPREVENT_OPTIMIZATION line 17 a == 5
FAIL: gcc.dg/guality/pr54796.c -O2 -DPREVENT_OPTIMIZATION line 17 b == 6
FAIL: gcc.dg/guality/pr54796.c -O2 -DPREVENT_OPTIMIZATION line 17 c == 5
FAIL: gcc.dg/guality/pr54796.c -O3 -g -DPREVENT_OPTIMIZATION line 17 a == 5
FAIL: gcc.dg/guality/pr54796.c -O3 -g -DPREVENT_OPTIMIZATION line 17 b == 6
FAIL: gcc.dg/guality/pr54796.c -O3 -g -DPREVENT_OPTIMIZATION line 17 c == 5
FAIL: gcc.dg/guality/pr54796.c -Os -DPREVENT_OPTIMIZATION line 17 a == 5
FAIL: gcc.dg/guality/pr54796.c -Os -DPREVENT_OPTIMIZATION line 17 b == 6
FAIL: gcc.dg/guality/pr54796.c -Os -DPREVENT_OPTIMIZATION line 17 c == 5
FAIL: gcc.dg/guality/pr54796.c -Og -DPREVENT_OPTIMIZATION line 17 a == 5
FAIL: gcc.dg/guality/pr54796.c -Og -DPREVENT_OPTIMIZATION line 17 b == 6
FAIL: gcc.dg/guality/pr54796.c -Og -DPREVENT_OPTIMIZATION line 17 c == 5
FAIL: gcc.dg/guality/pr54796.c -O2 -flto -fno-use-linker-plugin
-flto-partitio
n=none -DPREVENT_OPTIMIZATION line 17 a == 5
FAIL: gcc.dg/guality/pr54796.c -O2 -flto -fno-use-linker-plugin
-flto-partitio
n=none -DPREVENT_OPTIMIZATION line 17 b == 6
FAIL: gcc.dg/guality/pr54796.c -O2 -flto -fno-use-linker-plugin
-flto-partitio
n=none -DPREVENT_OPTIMIZATION line 17 c == 5
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
@ 2024-01-24 8:13 ` rguenth at gcc dot gnu.org
2024-01-24 11:00 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-24 8:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |i?86-*-*
Last reconfirmed| |2024-01-24
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
With -m32 only. Code generated is
Dump of assembler code for function foo:
0x080483ef <+0>: push %ebp
0x080483f0 <+1>: mov %esp,%ebp
0x080483f2 <+3>: push %ebx
0x080483f3 <+4>: sub $0x4,%esp
0x080483f6 <+7>: mov 0xc(%ebp),%eax
0x080483f9 <+10>: add $0xf,%eax
0x080483fc <+13>: and $0xfffffff0,%eax
0x080483ff <+16>: sub %eax,%esp
0x08048401 <+18>: mov %esp,%ebx
0x08048403 <+20>: sub $0x8,%esp
0x08048406 <+23>: push $0x2
0x08048408 <+25>: push %ebx
0x08048409 <+26>: call 0x80483e6 <bar>
=> 0x0804840e <+31>: add $0x8,%esp
0x08048411 <+34>: push $0x4
0x08048413 <+36>: push %ebx
0x08048414 <+37>: call 0x80483e6 <bar>
0x08048419 <+42>: add $0x10,%esp
0x0804841c <+45>: mov -0x4(%ebp),%ebx
0x0804841f <+48>: leave
0x08048420 <+49>: ret
the PC is where the function arguments and the 'c' stack local are no
longer visible to gdb. Code generation without the changes is the same
so it's very likely var-tracking that is affected by the alias analysis
changes possibly no longer disambiguating stack operations. In fact
after the
push $0x2
the variables are gone (I would have expected the call here). The
pushes are
(insn 22 21 23 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [2 S4 A32])
(const_int 2 [0x2]))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":16:3 60
{*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil)))
(insn 23 22 24 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [1 S4 A32])
(reg/f:SI 3 bx [108]))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":16:3 60
{*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
but the SP operation that's likely problematical is the feeding
(insn 16 15 17 2 (parallel [
(set (reg/f:SI 7 sp)
(minus:SI (reg/f:SI 7 sp)
(reg:SI 0 ax [107])))
(clobber (reg:CC 17 flags))
])
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":15:8 361
{*subsi_1}
(expr_list:REG_DEAD (reg:SI 0 ax [107])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))))
but we must come here via VALUE and
if (cselib_sp_based_value_p (val))
return static_reg_base_value[STACK_POINTER_REGNUM];
should still deal with this then (var-tracking sets this flag).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
2024-01-24 8:13 ` [Bug debug/113562] " rguenth at gcc dot gnu.org
@ 2024-01-24 11:00 ` rguenth at gcc dot gnu.org
2024-01-29 14:48 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-24 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the first difference is
@@ -4076,36 +4076,47 @@
fbt (0x7ffff700b468: (reg/f:SI 16 argp)) == (address:SI -4)
fbt (0x7ffff71f6a68: (plus:SI (minus:SI (value/u/j:SI 13:4329
@0x4a213b0/0x498b
600)
(value/u:SI 20:8682 @0x4a21458/0x498b750))
- (const_int -12 [0xfffffffffffffff4]))) == (address:SI -1)
-bac false
+ (const_int -12 [0xfffffffffffffff4]))) == (nil)
+bac true
and the obvioys thinbg to notice is that while we'll recurse through the
PLUS the MINUS has two VALUE operands which we'd give up upon (rightfully so).
Note this is disambiguating
(mem/c:SI (value/u:SI 1:1 @0x4a21290/0x498b3c0) [2 a+0 S4 A32])
against
(mem:SI (value/u/j:SI 24:21724 @0x4a214b8/0x498b810) [2 S4 A32])
with one address being (reg/f:SI 16 argp) and one
(plus:SI (minus:SI (value/u/j:SI 13:4329 @0x4a213b0/0x498b600)
(value/u:SI 20:8682 @0x4a21458/0x498b750))
(const_int -12 [0xfffffffffffffff4]))
where memrefs_conflict_p doesn't handle MINUS but wouldn't in this case
get to expansion of either VALUE anyway. But you can also see that
again a MEM_EXPR is mssing from the second MEM. Those are the push
instructions
(insn/f 38 5 39 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":13:1 60
{*pushsi2}
(nil))
(insn/f 40 39 41 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 3 bx))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":13:1 60
{*pushsi2}
where while spills use a special spill-slot decl the frame setup code
doesn't do anything like that so any MEM_EXPR based disambiguation
fails.
It's a bit hard to follow var-tracking in what insns it exactly sees to
disambiguate, as the frame setup code uses no MEM_EXPR and alias set zero
it seems to want to avoid any kind of disambiguation but at the same time
we can see the argp based accesses as to be non-conflicting?
The testcase has the variable sized stack allocation which now falls through
the cracks as being discovered as "stack-based" but as we're not
accessing it but only need the actual stack value it's odd we go to
true_dependence_1 for this.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
2024-01-24 8:13 ` [Bug debug/113562] " rguenth at gcc dot gnu.org
2024-01-24 11:00 ` rguenth at gcc dot gnu.org
@ 2024-01-29 14:48 ` rguenth at gcc dot gnu.org
2024-01-30 7:34 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-29 14:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Just to put it somewhere I ran dwlocstat on cc1plus before/after the offending
change and it looks almost the same. We go from
cov% samples cumul
0..10 1280217/38% 1280217/38%
11..20 55668/1% 1335885/40%
21..30 68004/2% 1403889/42%
31..40 70774/2% 1474663/44%
41..50 75554/2% 1550217/46%
51..60 91816/2% 1642033/49%
61..70 101139/3% 1743172/52%
71..80 135281/4% 1878453/56%
81..90 198470/5% 2076923/62%
91..100 1233822/37% 3310745/100%
to
cov% samples cumul
0..10 1280197/38% 1280197/38%
11..20 55669/1% 1335866/40%
21..30 68014/2% 1403880/42%
31..40 70773/2% 1474653/44%
41..50 75542/2% 1550195/46%
51..60 91800/2% 1641995/49%
61..70 101133/3% 1743128/52%
71..80 135259/4% 1878387/56%
81..90 198496/5% 2076883/62%
91..100 1233844/37% 3310727/100%
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
` (2 preceding siblings ...)
2024-01-29 14:48 ` rguenth at gcc dot gnu.org
@ 2024-01-30 7:34 ` rguenth at gcc dot gnu.org
2024-03-07 20:45 ` law at gcc dot gnu.org
2024-05-07 7:44 ` [Bug debug/113562] [14/15 " rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-30 7:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> Just to put it somewhere I ran dwlocstat on cc1plus before/after the
> offending change and it looks almost the same. We go from
>
> cov% samples cumul
> 0..10 1280217/38% 1280217/38%
> 11..20 55668/1% 1335885/40%
> 21..30 68004/2% 1403889/42%
> 31..40 70774/2% 1474663/44%
> 41..50 75554/2% 1550217/46%
> 51..60 91816/2% 1642033/49%
> 61..70 101139/3% 1743172/52%
> 71..80 135281/4% 1878453/56%
> 81..90 198470/5% 2076923/62%
> 91..100 1233822/37% 3310745/100%
>
> to
>
> cov% samples cumul
> 0..10 1280197/38% 1280197/38%
> 11..20 55669/1% 1335866/40%
> 21..30 68014/2% 1403880/42%
> 31..40 70773/2% 1474653/44%
> 41..50 75542/2% 1550195/46%
> 51..60 91800/2% 1641995/49%
> 61..70 101133/3% 1743128/52%
> 71..80 135259/4% 1878387/56%
> 81..90 198496/5% 2076883/62%
> 91..100 1233844/37% 3310727/100%
And with up-to-date elfutils to avoid some DWARF5 issues
cov% samples cumul
0..10 1280347/38% 1280347/38%
11..20 55720/1% 1336067/40%
21..30 68040/2% 1404107/42%
31..40 70805/2% 1474912/44%
41..50 75585/2% 1550497/46%
51..60 91850/2% 1642347/49%
61..70 101224/3% 1743571/52%
71..80 135406/4% 1878977/56%
81..90 198509/5% 2077486/62%
91..100 1233880/37% 3311366/100%
to
cov% samples cumul
0..10 1280327/38% 1280327/38%
11..20 55721/1% 1336048/40%
21..30 68050/2% 1404098/42%
31..40 70804/2% 1474902/44%
41..50 75573/2% 1550475/46%
51..60 91834/2% 1642309/49%
61..70 101218/3% 1743527/52%
71..80 135384/4% 1878911/56%
81..90 198535/5% 2077446/62%
91..100 1233902/37% 3311348/100%
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
` (3 preceding siblings ...)
2024-01-30 7:34 ` rguenth at gcc dot gnu.org
@ 2024-03-07 20:45 ` law at gcc dot gnu.org
2024-05-07 7:44 ` [Bug debug/113562] [14/15 " rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: law at gcc dot gnu.org @ 2024-03-07 20:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |law at gcc dot gnu.org
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug debug/113562] [14/15 Regression] FAIL: gcc.dg/guality/pr54796.c
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
` (4 preceding siblings ...)
2024-03-07 20:45 ` law at gcc dot gnu.org
@ 2024-05-07 7:44 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.0 |14.2
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-05-07 7:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-23 15:55 [Bug debug/113562] New: [14 Regression] FAIL: gcc.dg/guality/pr54796.c hjl.tools at gmail dot com
2024-01-24 8:13 ` [Bug debug/113562] " rguenth at gcc dot gnu.org
2024-01-24 11:00 ` rguenth at gcc dot gnu.org
2024-01-29 14:48 ` rguenth at gcc dot gnu.org
2024-01-30 7:34 ` rguenth at gcc dot gnu.org
2024-03-07 20:45 ` law at gcc dot gnu.org
2024-05-07 7:44 ` [Bug debug/113562] [14/15 " rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).