From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DC2A73858D39; Fri, 2 Sep 2022 23:59:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC2A73858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662163142; bh=rgKYpdfmdOCDqISL72+vMiAtTsiCyURzOCfLD/ks2lQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PcxLCN+OlRU5n53+izSxi9LVNH/2NZdvblWKToJz56GE60XhYSW1K1h+Z5BimSfxw 6408wwFsSQPk9v/3ES1iewSx568ceGRlebBx/TskrxmCmF6+6xp1bI2CbXleUh2Jgl ov8HJ/J9gcI8xdHMOarYTc9EOjypkHqvrAz6g3sg= From: "palmer at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/106818] code is genereated differently with or without 'extern' Date: Fri, 02 Sep 2022 23:59:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: palmer at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106818 --- Comment #8 from palmer at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) > (In reply to baoshan from comment #6) > > > really of unknown alignment then sharing the lui might not work. > > Can you elaborate why shareing the lui might not work? Unless I've managed to screw up some bit arithmetic here, it's just overflow that we're not detecting at link time: $ cat test.c=20 extern char glob[4]; int _start(void) { int *i =3D (int *)glob; return *i; } $ cat glob.s=20 .section .sdata .balign 4096 .global empty empty: .rep 2046 .byte 0 .endr .global glob glob: .byte 1, 2, 3, 4 $ riscv64-linux-gnu-gcc test.c glob.s -O3 -o test -static -fno-PIE -mcmodel=3Dmedlow -mexplicit-relocs -nostdlib $ riscv64-linux-gnu-objdump -d test ... 000000000001010c <_start>: 1010c: 66c9 lui a3,0x12 1010e: 7ff6c703 lbu a4,2047(a3) # 127ff 10112: 7fe6c603 lbu a2,2046(a3) 10116: 8006c783 lbu a5,-2048(a3) 1011a: 8016c503 lbu a0,-2047(a3) ... So that's going to load a3 =3D 0x127ff=20 a2 =3D 0x127fd a5 =3D 0x11800 a6 =3D 0x11801 Which is wrong. We can't detect it at link time because both relocations are being processed correctly, they just don't know about each other (and really can't, because there's nothing coupling them together). > Linker relaxation not coming in and relaxing it to be use gp offsets inst= ead. > It is one of the worst parts of the riscv toolchain ... Though this time linker relaxation is actually biting us twice: First, it's masking this problem for small programs: if these accesses are = all within range of GP we end up producing executables that function fine, as t= he relaxation calculates the full addresses to use as GP offsets. Second, the GP relaxations just don't work when we share LUIs for possibly-misaligned symbols because we delete the LUI if the first low-half= is within GP range. For example: $ cat glob.s=20 .section .sdata .global empty empty: .rep 4090 .byte 0 .endr .global glob glob: .byte 1, 2, 3, 4 $ riscv64-linux-gnu-gcc test.c glob.s -O3 -o test -static -fno-PIE -mcmodel=3Dmedlow -mexplicit-relocs --save-temps -nostdlib $ riscv64-linux-gnu-objdump -d test ... 000000000001010c <_start>: 1010c: 7fb1c703 lbu a4,2043(gp) # 12127 10110: 7fa1c603 lbu a2,2042(gp) # 12126 10114: 1286c783 lbu a5,296(a3) 10118: 1296c503 lbu a0,297(a3) ... We had that problem with the AUIPC->GP relaxation as well, but could fix it there because the low half points to the high half. Here I think there's a= lso nothing we can do in the linker, as there's no way to tell when the result = of the LUI is completely unused -- we could deal with simple cases like this, = but with control flow there's no way to handle all of them.=