public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/46596] New: misbehavior when mixing always_inline and alias attributes in the same compilation unit
@ 2010-11-22  3:50 vapier at gentoo dot org
  2010-11-22  4:58 ` [Bug c/46596] " vapier at gentoo dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: vapier at gentoo dot org @ 2010-11-22  3:50 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46596

           Summary: misbehavior when mixing always_inline and alias
                    attributes in the same compilation unit
           Product: gcc
           Version: 4.5.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vapier@gentoo.org


i have a function "foo".  its header sets up an always_inline function that
does sanity checks when constants are involved.  otherwise it delays the
non-constant checking to another function.  here is the portion from the
header:
  extern void foo(int i);
  extern void __in(int i);
  extern inline __attribute__((always_inline))
  void foo(int i) { __in(i); }

where i actually define "foo", there is an alias used to setup multiple
symbols.  also in that file is another function which calls the inline checking
function.  together, gcc barfs.  here is the portion of the file:
  void bar(int i) { foo(i + 1234); }
  void __foo(int i) {}
  extern typeof(__foo) foo __attribute__((alias("__foo")));

combine them into one and compile like so (this is 4.5.1):
  gcc -O2 -c test.c -std=gnu99 -fgnu89-inline -Winline

this produces the error:
test.c: In function ‘bar’:
test.c:18:22: sorry, unimplemented: inlining failed in call to ‘foo’: function
body not available
test.c:14:5: sorry, unimplemented: called from here

that doesnt seem right since the function body *is* available.  if i split the
__foo/foo definitions into their own dedicated file, then everything compiles
just fine as i'd expect.

what's even more odd though is that -Winline affects code generation.  if you
compile without that flag, you dont get any errors, but the generated code is
wrong:
  gcc -O2 -c test.c -std=gnu99 -fgnu89-inline
  objdump -dr test.o
...
0000000000000000 <bar>:
   0:   81 c7 d2 04 00 00       add    $0x4d2,%edi
   6:   e9 00 00 00 00          jmpq   b <bar+0xb>
                        7: R_X86_64_PC32        foo-0x4
   b:   0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
...

clearly it's just jumping straight to the definition of foo rather than going
through the inline function.

doesnt seem to be a regression ... every gcc version ive tested fails in the
same way: 4.0.4, 4.1.2, 4.2.4, 4.3.5, 4.4.4, 4.5.1.  versions before 4.2.x had
the -fgnu89-inline flag dropped since that was the default behavior and so was
unnecessary (and unrecognized).


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-03-01 23:09 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-22  3:50 [Bug c/46596] New: misbehavior when mixing always_inline and alias attributes in the same compilation unit vapier at gentoo dot org
2010-11-22  4:58 ` [Bug c/46596] " vapier at gentoo dot org
2010-11-22 11:11 ` rguenth at gcc dot gnu.org
2010-11-22 19:02 ` vapier at gentoo dot org
2012-02-29  9:44 ` jyasskin at gcc dot gnu.org
2012-02-29 15:16 ` hubicka at ucw dot cz
2012-02-29 16:22 ` vapier at gentoo dot org
2024-03-01 23:09 ` [Bug ipa/46596] " pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).