https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #54 from John David Anglin ---
The f-m-o issue is probably fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #53 from GCC Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:f0fda1aff0b752e4182c009c5526b9306bd35f7c
commit r14-9511-gf0fda1aff0b752e4182c009c5526b9306bd35f7c
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #52 from Manolis Tsamis ---
(In reply to Sam James from comment #51)
> manolis, did you have a chance to look at the remaining pass issue? You'll
> need to revert Dave's commit locally which made the issue latent for
> building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #51 from Sam James ---
manolis, did you have a chance to look at the remaining pass issue? You'll need
to revert Dave's commit locally which made the issue latent for building
Python.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #50 from CVS Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:d2934eb6ae92471484469d8ddd039eb34ef400b1
commit r14-5538-gd2934eb6ae92471484469d8ddd039eb34ef400b1
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #49 from John David Anglin ---
Created attachment 56576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56576=edit
Patch to improve reg+d address handling
This patch revise pa_legitimate_address_p to allow 14-bit displacements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #48 from Manolis Tsamis ---
(In reply to dave.anglin from comment #47)
> On 2023-11-13 4:33 a.m., manolis.tsamis at vrull dot eu wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
> >
> > --- Comment #44 from Manolis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #47 from dave.anglin at bell dot net ---
On 2023-11-13 4:33 a.m., manolis.tsamis at vrull dot eu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #44 from Manolis Tsamis ---
> (In reply to John David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #46 from Manolis Tsamis ---
I have reproduced the segfault with f-m-o limited to only fold insn 272 from
compiler_call_helper. The exact transformation is:
Memory offset changed from 0 to 388 for instruction:
(insn 273 272 276 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #45 from Manolis Tsamis ---
(In reply to Jeffrey A. Law from comment #41)
> I would agree. In fact,the whole point of the f-m-o pass is to bring those
> immediates into the memory reference. It'd be really useful to know why
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #44 from Manolis Tsamis ---
(In reply to John David Anglin from comment #39)
> In the f-m-o pass, the following three insns that set call clobbered
> registers r20-r22 are pulled from loop:
>
> (insn 186 183 190 29 (set (reg/f:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #43 from Jeffrey A. Law ---
I would expect allowing larger offsets before reload to be a significant
problem.
The core issue is integer memory operations allow 14 bits while FP only allows
5. During reloading we don't know if any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #42 from John David Anglin ---
The problem is we are limiting displacements to five bits in
pa_legitimate_address_p. The comment is somewhat confusing but
we may have reload issues if we allow 14-bit displacements before
reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #41 from Jeffrey A. Law ---
I would agree. In fact,the whole point of the f-m-o pass is to bring those
immediates into the memory reference. It'd be really useful to know why that
isn't happening.
The only thing I can think of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #40 from John David Anglin ---
Jeff,
I don't think these split instructions make a lot of sense on PA-RISC.
(insn 280 277 281 30 (set (reg/f:SI 20 %r20 [480])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #39 from John David Anglin ---
In the f-m-o pass, the following three insns that set call clobbered
registers r20-r22 are pulled from loop:
(insn 186 183 190 29 (set (reg/f:SI 22 %r22 [478])
(plus:SI (reg/f:SI 19 %r19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #37 from John David Anglin ---
(In reply to Sam James from comment #35)
> If you still need dumps off me, please let me know which. I've attached
> those w/ f-o-m on for the fold-mem-offsets pass. If you need others, just
> say.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #36 from John David Anglin ---
Created attachment 56562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56562=edit
fold_mem_offsets, prop_hardreg, rtl_dce and bbro dumps
Comment #33 is wrong. The issue is not reload. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #35 from Sam James ---
If you still need dumps off me, please let me know which. I've attached those
w/ f-o-m on for the fold-mem-offsets pass. If you need others, just say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #34 from John David Anglin ---
Same wrong code is generated with x86-64 cross to hppa-linux-gnu. This it seems
this bug is not due to gcc being miscompiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #33 from John David Anglin ---
Created attachment 56549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56549=edit
ira and reload dumps for compiler_call_helper
The incorrect code for insn 246 in compiler_call_helper appears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #32 from dave.anglin at bell dot net ---
At this point, I don't have gcc-14 builds that bracket the f-m-o change. Maybe
Sam can check.
I'm trying to determine RTL pass where things go bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #31 from Jeffrey A. Law ---
IIRC r21 is call-clobbered. So I guess the question turns into what was the
sequence before f-m-o got involved -- was it assuming r21 would be preserved,
or did f-m-o make r21 live across the call?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #30 from John David Anglin ---
0x0019c684 <+588>: stw r23,0(r22)
=> 0x0019c688 <+592>: stw ret1,0(r21)
0x0019c68c <+596>: stw r31,0(r20)
0x0019c690 <+600>: b,l 0x198d58 ,rp
0x0019c694 <+604>: stw ret0,0(r19)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #29 from John David Anglin ---
The miscompilation is in compiler_visit_expr:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #28 from dave.anglin at bell dot net ---
On 2023-11-08 7:07 p.m., law at gcc dot gnu.org wrote:
> Do we already have a dump for the key function? Presumably f-m-o doesn't
> trigger*that* much. And if this is triggering w/o LTO we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #27 from dave.anglin at bell dot net ---
On 2023-11-08 7:00 p.m., John David Anglin wrote:
> On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>>
>> --- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #26 from Jeffrey A. Law ---
As a compiler junkie, I tend to think compiler first until I can prove it
otherwise. I wouldn't get too hung up on aliasing issues and such at this
point.
Do we already have a dump for the key function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #25 from Sam James ---
I am having the same thoughts. It would not be the first time Python had
something dubious, like...
* https://wiki.gentoo.org/wiki/Project:Python/Strict_aliasing ->
https://www.python.org/dev/peps/pep-3123/
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #24 from dave.anglin at bell dot net ---
On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #23 from Sam James ---
> (In reply to Andrew Pinski from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #23 from Sam James ---
(In reply to Andrew Pinski from comment #21)
> The other option to try is -fstack-reuse=none. There is definitely known
> issues with the code that coalesces stack variables together too (see PR
> 111843 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #22 from John David Anglin ---
Created attachment 56542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56542=edit
Preprocessed source and assembly files for Python/compile.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #21 from Andrew Pinski ---
(In reply to dave.anglin from comment #20)
> Both -fno-strict-aliasing and -fno-schedule-insns2 applied to
> compiler_visit_expr()
> work around issue.
The other option to try is -fstack-reuse=none. There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #20 from dave.anglin at bell dot net ---
On 2023-11-08 2:07 p.m., pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #18 from Andrew Pinski ---
> I wonder if -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #19 from Jeffrey A. Law ---
f-m-o runs post-allocation, so the scope of where it's behavior can change
things is narrower. So testing with -fno-schedule-insns isn't going to be
useful, but -fno-schedule-insns2 might.
I'm a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #18 from Andrew Pinski ---
I wonder if -fno-strict-aliasing works around the issue too?
I get the feeling that `fold mem offset pass` allows the aliasing code to have
a better time with the offset and that might be expose more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #17 from dave.anglin at bell dot net ---
On 2023-11-08 9:42 a.m., jeffreyalaw at gmail dot com wrote:
> I'd probably continue with the process of narrowing down what code is
> affected using the attributes. We already know the file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #16 from Jeffrey A. Law ---
On 11/8/23 03:09, manolis.tsamis at vrull dot eu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #15 from Manolis Tsamis ---
> (In reply to Sam James from comment #13)
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #15 from Manolis Tsamis ---
(In reply to Sam James from comment #13)
> Created attachment 56527 [details]
> compile.c.323r.fold_mem_offsets.bad.xz
>
> Output from
> ```
> hppa2.0-unknown-linux-gnu-gcc -c -DNDEBUG -g -fwrapv -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #14 from dave.anglin at bell dot net ---
On 2023-11-07 8:36 p.m., sjames at gcc dot gnu.org wrote:
> If I instrument certain functions in compile.c with no optimisation attribuet
> or build the file with -fno-fold-mem-offsets, Python
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #13 from Sam James ---
Created attachment 56527
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56527=edit
compile.c.323r.fold_mem_offsets.bad.xz
Output from
```
hppa2.0-unknown-linux-gnu-gcc -c -DNDEBUG -g -fwrapv -O3 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #12 from Sam James ---
(In reply to Manolis Tsamis from comment #11)
> Hi all,
>
> I will also go ahead and try to reproduce that, although it may take me some
> time due to my limited experience with HPPA. Once I manage to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #11 from Manolis Tsamis ---
Hi all,
I will also go ahead and try to reproduce that, although it may take me some
time due to my limited experience with HPPA. Once I manage to reproduce, most
f-m-o issues are straightforward to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #10 from dave.anglin at bell dot net ---
On 2023-11-06 5:49 p.m., sjames at gcc dot gnu.org wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x412083f0 in _PyST_GetSymbol (name=0xf9a34a00, ste=) at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #9 from Sam James ---
I think the key object is Python/compile.o, but not certain yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #8 from Sam James ---
(In reply to Jeffrey A. Law from comment #6)
Program received signal SIGSEGV, Segmentation fault.
0x412083f0 in _PyST_GetSymbol (name=0xf9a34a00, ste=) at
Python/symtable.c:396
396 PyObject *v =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #7 from dave.anglin at bell dot net ---
On 2023-11-06 5:20 p.m., law at gcc dot gnu.org wrote:
> The biggest concern I'd have with f-m-o on the PA would be the
> implicit segment selection that happens on the base register -- but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #6 from Jeffrey A. Law ---
Do we have assembly code around the faulting point (x/20i $pc) and a register
dump (i r)? The biggest concern I'd have with f-m-o on the PA would be the
implicit segment selection that happens on the base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Sam James changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #4 from Sam James ---
Created attachment 56520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56520=edit
list_of_differing_files.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-11-06 4:00 p.m., sjames at gcc dot gnu.org wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #2 from Sam James ---
I'll grab a bad vs good build directory next and upload both, and then try see
which objects differ.
Dave, can you reproduce?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Sam James changed:
What|Removed |Added
Summary|[14 regression] Python 3.11 |[14 regression] Python 3.11
56 matches
Mail list logo
