[Bug modula2/108153] New: Profiled lto bootstrap failure with modula2

[Bug modula2/108153] New: Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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

            Bug ID: 108153
           Summary: Profiled lto bootstrap failure with modula2
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: modula2
          Assignee: gaius at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Some builds but not all fail for me in the distro
--with-build-config=bootstrap-lto --enable-link-serialization=1
profiledbootstrap build.
https://koji.fedoraproject.org/koji/getfile?taskID=95445665&volume=DEFAULT&name=build.log&offset=-40000
https://koji.fedoraproject.org/koji/getfile?taskID=95448682&volume=DEFAULT&name=build.log&offset=-40000
https://koji.fedoraproject.org/koji/getfile?taskID=95448683&volume=DEFAULT&name=build.log&offset=-40000
2 of them are on s390x, one on powerpc64le, all look like:
In function 'SYSTEM_ShiftVal':
cc1gm2: internal compiler error: the location value is corrupt
In function 'ShiftVal':
cc1gm2: internal compiler error: the location value is corrupt
0x11a3d2d m2assert_AssertLocation(unsigned int)
        ../../gcc/m2/gm2-gcc/m2assert.cc:40
0x11a3d2d m2assert_AssertLocation(unsigned int)
        ../../gcc/m2/gm2-gcc/m2assert.cc:40
0x11a3d2d m2assert_AssertLocation(unsigned int)
        ../../gcc/m2/gm2-gcc/m2assert.cc:32
0x11a3d2d m2statement_BuildAssignmentTree
        ../../gcc/m2/gm2-gcc/m2statement.cc:177
0x11a3d2d m2assert_AssertLocation(unsigned int)
        ../../gcc/m2/gm2-gcc/m2assert.cc:32
0x11a3d2d m2statement_BuildAssignmentTree
        ../../gcc/m2/gm2-gcc/m2statement.cc:177
0x11ff5d5 CodeModM2Check
        m2/gm2-compiler-boot/M2GenGCC.c:5078
0x11ff5d5 CodeModM2Checked
        m2/gm2-compiler-boot/M2GenGCC.c:5061
0x11ff5d5 CodeModM2Check
        m2/gm2-compiler-boot/M2GenGCC.c:5078
0x11ff5d5 CodeModM2Checked
        m2/gm2-compiler-boot/M2GenGCC.c:5061
0x11ff5d5 CodeStatement
        m2/gm2-compiler-boot/M2GenGCC.c:1775
0x11ff5d5 M2GenGCC_ConvertQuadsToTree
        m2/gm2-compiler-boot/M2GenGCC.c:8456
0x11ff5d5 CodeStatement
        m2/gm2-compiler-boot/M2GenGCC.c:1775
0x11ff5d5 M2GenGCC_ConvertQuadsToTree
        m2/gm2-compiler-boot/M2GenGCC.c:8456
0x122db9d M2Scope_ForeachScopeBlockDo
        m2/gm2-compiler-boot/M2Scope.c:660
0x122db9d M2Scope_ForeachScopeBlockDo
        m2/gm2-compiler-boot/M2Scope.c:660
0x11d007f M2Code_CodeBlock
        m2/gm2-compiler-boot/M2Code.c:511
0x11a1a43 Lists_ForeachItemInListDo
        m2/gm2-compiler-boot/Lists.c:393
0x11d0245 M2Code_CodeBlock
        m2/gm2-compiler-boot/M2Code.c:543
0x11e02d9 DoCodeBlock
        m2/gm2-compiler-boot/M2Code.c:270
0x11e02d9 M2Code_Code
        m2/gm2-compiler-boot/M2Code.c:474
0x11e1af1 Compile
        m2/gm2-compiler-boot/M2Comp.c:211
0x11e1af1 M2Comp_compile
        m2/gm2-compiler-boot/M2Comp.c:760
0x11d007f M2Code_CodeBlock
        m2/gm2-compiler-boot/M2Code.c:511
0x11a1a43 Lists_ForeachItemInListDo
        m2/gm2-compiler-boot/Lists.c:393
0x11d0245 M2Code_CodeBlock
        m2/gm2-compiler-boot/M2Code.c:543
0x11e02d9 DoCodeBlock
        m2/gm2-compiler-boot/M2Code.c:270
0x11e02d9 M2Code_Code
        m2/gm2-compiler-boot/M2Code.c:474
0x11e1af1 Compile
        m2/gm2-compiler-boot/M2Comp.c:211
0x11e1af1 M2Comp_compile
        m2/gm2-compiler-boot/M2Comp.c:760
0x1182b55 gm2_parse_input_files
        ../../gcc/m2/gm2-lang.cc:451
0x1182b55 gm2_langhook_parse_file
        ../../gcc/m2/gm2-lang.cc:458
0x1182b55 gm2_parse_input_files
        ../../gcc/m2/gm2-lang.cc:451
0x1182b55 gm2_langhook_parse_file
        ../../gcc/m2/gm2-lang.cc:458
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
SYSTEM module creates type: LOC
SYSTEM module creates type: WORD
SYSTEM module creates type: BYTE
SYSTEM module creates type: ADDRESS
SYSTEM module creates type: INTEGER8
SYSTEM module creates type: INTEGER16
SYSTEM module creates type: INTEGER32
SYSTEM module creates type: INTEGER64
SYSTEM module creates type: CARDINAL8
SYSTEM module creates type: CARDINAL16
SYSTEM module creates type: CARDINAL32
SYSTEM module creates type: CARDINAL64
SYSTEM module creates type: WORD16
SYSTEM module creates type: WORD32
SYSTEM module creates type: WORD64
SYSTEM module creates type: BITSET8
SYSTEM module creates type: BITSET16
SYSTEM module creates type: BITSET32
SYSTEM module creates type: REAL32
SYSTEM module creates type: REAL64
SYSTEM module creates type: REAL128
SYSTEM module creates type: COMPLEX32
SYSTEM module creates type: COMPLEX64
SYSTEM module creates type: COMPLEX128
SYSTEM module creates type: CSIZE_T
SYSTEM module creates type: CSSIZE_T

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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).

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[gaius at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[marxin at gcc dot gnu.org]

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

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[segher at gcc dot gnu.org]

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).

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[segher at gcc dot gnu.org]

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 :-)

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[gaius at gcc dot gnu.org]

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

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[cvs-commit at gcc dot gnu.org]

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.

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

[jakub at gcc dot gnu.org]

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.