* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
@ 2022-12-17 8:00 ` jakub at gcc dot gnu.org
2022-12-17 22:09 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-17 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
One of the build is without my PR108147 fix, 2 of them are with it. I don't
see m2rte plugin stuff anywhere in the backtrace (two intermingled ones).
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
2022-12-17 8:00 ` [Bug modula2/108153] " jakub at gcc dot gnu.org
@ 2022-12-17 22:09 ` jakub at gcc dot gnu.org
2022-12-18 9:32 ` gaius at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-17 22:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, non-lto profiledbootstrap with modula2 passed on i686, x86_64, aarch64,
s390x and ppc64le (all with the PR108147 patch). It is just lto
profiledbootstrap that doesn't work.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
2022-12-17 8:00 ` [Bug modula2/108153] " jakub at gcc dot gnu.org
2022-12-17 22:09 ` jakub at gcc dot gnu.org
@ 2022-12-18 9:32 ` gaius at gcc dot gnu.org
2022-12-19 8:38 ` marxin at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: gaius at gcc dot gnu.org @ 2022-12-18 9:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #3 from Gaius Mulley <gaius at gcc dot gnu.org> ---
On x86_64 the build succeed using MAKEFLAGS=profiledbootstrap-lean
CONFIGFLAGS=--with-build-config=bootstrap-lto-lean
however I do see many ODR violations (from the output of the bootstrap tool
mc). It would be interesting to double check there is no use of varags here.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2022-12-18 9:32 ` gaius at gcc dot gnu.org
@ 2022-12-19 8:38 ` marxin at gcc dot gnu.org
2022-12-19 17:02 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-12-19 8:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marxin at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2022-12-19
Status|UNCONFIRMED |NEW
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2022-12-19 8:38 ` marxin at gcc dot gnu.org
@ 2022-12-19 17:02 ` jakub at gcc dot gnu.org
2022-12-20 15:28 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-19 17:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've tried to reproduce it on gcc112.fsffrance.org with
../configure --enable-languages=c,c++,lto,m2 --with-build-config=bootstrap-lto
--enable-link-serialization=1 --disable-libsanitizer
make -j160 profiledbootstrap
but it works there.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2022-12-19 17:02 ` jakub at gcc dot gnu.org
@ 2022-12-20 15:28 ` jakub at gcc dot gnu.org
2022-12-20 15:37 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-20 15:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dje at gcc dot gnu.org,
| |segher at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What fails is:
./cc1gm2 -msecure-plt -quiet -dumpbase SYSTEM.mod -dumpbase-ext .mod
-mtune=power8 -mcpu=power8 -version -fpim -fno-scaffold-main
-fno-scaffold-dynamic -fno-scaffold-static -fno-m2-plugin -fdump-system-exports
-B ./ -B /usr/ppc64le-redhat-linux/bin/ -c -fpim -fno-scaffold-main
-fno-scaffold-dynamic -fno-scaffold-static -fno-m2-plugin -fdump-system-exports
-I ../../gcc/m2/gm2-libs -I /usr/lib/gcc/ppc64le-redhat-linux/13/m2/m2pim -I
/usr/lib/gcc/ppc64le-redhat-linux/13/m2/m2log -I
/usr/lib/gcc/ppc64le-redhat-linux/13/m2/m2iso ../../gcc/m2/gm2-libs/SYSTEM.mod
-o /tmp/ccgDXY6u.s
and the ICE is because m2assert_AssertLocation inlined into
m2statement_BuildAssignmentTree sees a difference on
M2Options_OverrideLocation (location) != location
location (in $r30) is 0x80000007, while M2Options_OverrideLocation returned (in
$r3)
0xffffffff80000007 instead.
M2Options_OverrideLocation ends with
0x00000000102396e0 <+32>: extsw r3,r3
before returning, so it clearly sign extends the 32-bit return value to 64-bit.
And the caller compares whole 64-bits:
0x00000000101c7488 <m2statement_BuildAssignmentTree(location_t, tree,
tree)+40>: mr r30,r3
0x00000000101c748c <m2statement_BuildAssignmentTree(location_t, tree,
tree)+44>: mr r29,r4
0x00000000101c7490 <m2statement_BuildAssignmentTree(location_t, tree,
tree)+48>: mr r31,r5
0x00000000101c7494 <m2statement_BuildAssignmentTree(location_t, tree,
tree)+52>: ble 0x101c74a8 <m2statement_BuildAssignmentTree(location_t,
tree, tree)+72>
0x00000000101c7498 <m2statement_BuildAssignmentTree(location_t, tree,
tree)+56>: bl 0x102396c8
<M2Options_OverrideLocation(m2linemap_location_t)+8>
0x00000000101c749c <m2statement_BuildAssignmentTree(location_t, tree,
tree)+60>: nop
=> 0x00000000101c74a0 <m2statement_BuildAssignmentTree(location_t, tree,
tree)+64>: cmpd r3,r30
So, I bet there must be some mismatch on whether M2Options_OverrideLocation
returns a signed or unsigned 32-bit value.
I believe the powerpc64le-linux ABI (and probably various other ABIs) returns
(and passes?) signed 32-bit values sign-extended from 32-bits to 64-bits, and
returns (and passes?) unsigned 32-bit values zero-extended from 32-bits to
64-bits.
Say x86_64-linux doesn't do this, the upper 32 bits when passing or returning
32-bit values are undefined.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2022-12-20 15:28 ` jakub at gcc dot gnu.org
@ 2022-12-20 15:37 ` jakub at gcc dot gnu.org
2022-12-20 15:39 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-20 15:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
libcpp/cpplib.h has
line-map.h:typedef unsigned int location_t;
The modula 2 source has:
FROM m2linemap IMPORT location_t ;
...
PROCEDURE OverrideLocation (location: location_t) : location_t ;
BEGIN
IF ForcedLocation
THEN
RETURN( ForcedLocationValue )
ELSE
RETURN( location )
END
END OverrideLocation ;
and
TYPE
location_t = INTEGER ;
So, I just wonder if it shouldn't be location_t = CARDINAL ; instead.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2022-12-20 15:37 ` jakub at gcc dot gnu.org
@ 2022-12-20 15:39 ` jakub at gcc dot gnu.org
2022-12-20 16:35 ` segher at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-20 15:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54133&action=edit
gcc13-pr108153.patch
Same in patch form. Let me test if that helps.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2022-12-20 15:39 ` jakub at gcc dot gnu.org
@ 2022-12-20 16:35 ` segher at gcc dot gnu.org
2022-12-20 16:36 ` segher at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: segher at gcc dot gnu.org @ 2022-12-20 16:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> So, I bet there must be some mismatch on whether M2Options_OverrideLocation
> returns a signed or unsigned 32-bit value.
> I believe the powerpc64le-linux ABI (and probably various other ABIs)
> returns (and passes?) signed 32-bit values sign-extended from 32-bits to
> 64-bits, and returns (and passes?) unsigned 32-bit values zero-extended from
> 32-bits to 64-bits.
ELFv2 says
Follow these rules for parameter passing:
[...]
• Map simple integer types (char, short, int, long, enum) to a single
doubleword. Sign or zero extend values shorter than a doubleword to a
doubleword based on whether the source data type is signed or unsigned.
(Older ABIs said just
Simple integer types (char, short, int, long, enum) are mapped to a
single doubleword. Values shorter than a doubleword are sign or zero
extended as necessary.)
> Say x86_64-linux doesn't do this, the upper 32 bits when passing or
> returning 32-bit values are undefined.
It in general is cheaper for the caller to extend than for the callee (it
often can be done for free in the caller). It also saves code size. Finally,
undefined bits in your calling convention easily cause problems (besides being
wasteful of course).
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2022-12-20 16:35 ` segher at gcc dot gnu.org
@ 2022-12-20 16:36 ` segher at gcc dot gnu.org
2022-12-20 18:01 ` gaius at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: segher at gcc dot gnu.org @ 2022-12-20 16:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
That patch looks good btw :-)
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2022-12-20 16:36 ` segher at gcc dot gnu.org
@ 2022-12-20 18:01 ` gaius at gcc dot gnu.org
2022-12-21 8:18 ` cvs-commit at gcc dot gnu.org
2022-12-21 8:27 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: gaius at gcc dot gnu.org @ 2022-12-20 18:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #10 from Gaius Mulley <gaius at gcc dot gnu.org> ---
LGTM yes indeed, location_t should be CARDINAL
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (10 preceding siblings ...)
2022-12-20 18:01 ` gaius at gcc dot gnu.org
@ 2022-12-21 8:18 ` cvs-commit at gcc dot gnu.org
2022-12-21 8:27 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-12-21 8:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:88709c4a1e6f8b69a33897a1ab46b8d66c4569c4
commit r13-4824-g88709c4a1e6f8b69a33897a1ab46b8d66c4569c4
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Dec 21 09:10:35 2022 +0100
modula2: Fix lto profiledbootstrap on powerpc64le-linux and s390x-linux
[PR108153]
Lto profiledbootstrap was failing for me on {powerpc64le,s390x}-linux with
modula 2 enabled, with:
cc1gm2: internal compiler error: the location value is corrupt
0x11a3d2d m2assert_AssertLocation(unsigned int)
../../gcc/m2/gm2-gcc/m2assert.cc:40
0x11a3d2d m2statement_BuildAssignmentTree
../../gcc/m2/gm2-gcc/m2statement.cc:177
ICE. The problem was that caller (m2assert_AssertLocation used
location_t M2Options_OverrideLocation (location_t);
prototype with the libcpp/line-map.h
typedef unsigned int location_t;
typedef, but the callee defined in Modula 2 was using:
TYPE
location_t = INTEGER ;
and
PROCEDURE OverrideLocation (location: location_t) : location_t ;
Now, on powerpc64le-linux unsigned int is returned and passed zero extended
into 64-bits, while signed int is returned and passed sign-extended into
64-bits
and Modula 2 INTEGER is signed 32-bit type, so when the caller then
compared
M2Options_OverrideLocation (location) != location
and powerpc64le-linux performed the comparison as 64-bit compare, there
was a mismatch for location_t of 0x8000007 or others with the MSB set.
Fixed by making Modula 2 location_t a CARDINAL, which is 32-bit unsigned
type.
2022-12-21 Jakub Jelinek <jakub@redhat.com>
PR modula2/108153
* gm2-gcc/m2linemap.def (location_t): Use CARDINAL instead of
INTEGER.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug modula2/108153] Profiled lto bootstrap failure with modula2
2022-12-17 7:57 [Bug modula2/108153] New: Profiled lto bootstrap failure with modula2 jakub at gcc dot gnu.org
` (11 preceding siblings ...)
2022-12-21 8:18 ` cvs-commit at gcc dot gnu.org
@ 2022-12-21 8:27 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-21 8:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 14+ messages in thread