https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Ulya changed:
What|Removed |Added
CC||skvadrik at gmail dot com
--- Comment #12 from Ul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ebotcazou at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
--- Comment #11 from Eric Botcazou ---
> Why those are handled differently? First looks like it works, second does
> not. It was my main signal to file a bug against gcc as asymmetry looked
> fishy.
Because the problematic bitfield path is only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
--- Comment #10 from Sergei Trofimovich ---
Oh, I have forgot to ask another question:
In attached reloc-bug.c there is seemingly two functionally identical samples:
extern char glo_u64_middle_hidden[] __attribute__((visibility("hidden")));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
--- Comment #9 from Sergei Trofimovich ---
Aha, makes sense! Proposed kernel tweak upstream as:
https://lkml.org/lkml/2018/2/2/914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Eric Botcazou changed:
What|Removed |Added
Component|c |middle-end
--- Comment #8 from Eric Botc