[Bug lto/86442] Wrong error: global register variable follows a function definition when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 68384 (and maybe others). *** This bug has been marked as a duplicate of bug 68384 ***
[Bug lto/86442] Wrong error: global register variable follows a function definition when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Indeed, I think the build system should be passing -fno-lto for such translation units, as their ABI is different from the rest. I'm not sure limiting the inliner is enough, there's also IPA-RA and it's not obviously safe w.r.t global-reg-var differences. If there's a desire to support such usage "seamlessly", I'd really like to see the same solution for this and toplevel asms: making such input translation unit one LTO partition (i.e. not splitting or merging it with anything else).
[Bug lto/86442] Wrong error: global register variable follows a function definition when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
--- Comment #1 from Jan Hubicka ---
> Following wrong error is printed with LTO:
>
> $ cat global.cpp
> register int a __asm__("r12");
>
> class b {
> public:
> b();
> };
>
> b c;
>
> int main() { a = 3; }
>
> $ g++ global.cpp -O2 -flto
> global.cpp: In function ‘main’:
> global.cpp:1:14: error: global register variable follows a function definition
> register int a __asm__("r12");
> ^
> lto-wrapper: fatal error: g++ returned 1 exit status
> compilation terminated.
> /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
> error:
> lto-wrapper failed
> collect2: error: ld returned 1 exit status
Global register variables are not really working with LTO (because they should
be part of the function context since they may differ across units).
We could try to fix them for gcc 9. I was thinking a bit about it, but it
would
need to attach the information somewhere into optimization node and make
inliner
to not inline across different globally allocated registers.
It is overall questionable how global registers should interact with the symbol
table.
Honza
