Opened 10 years ago
Last modified 10 years ago
#278 closed defect
gcc 4.7.x inline behaviour change — at Version 3
Reported by: | Yuri Dario | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | libc-0.6.6 |
Component: | libc | Version: | |
Severity: | major | Keywords: | |
Cc: |
Description (last modified by )
With newer gcc releases, code inlining is following a different path than before. This leads to many problems in the build of libc but also of other applications. See http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Inline.html for details.
At this time, this is fixed using -fgnu89-inline which restores old behaviour.
The right thing seems to use 'extern inline' instead of 'static inline'. But without a proper prototype, gcc will still ignore inlining.
Many headers defines code to be inlined without a prototype.
I'm leaving this ticket open for reference.
Change History (4)
Changed 10 years ago by
Attachment: | patch-278b.txt added |
---|
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Please, this isn't a place to educate people about the changes in gcc version changes. The defect completely lacks any real error messages and problem description. It will not be left open for reference, it will instead be close immediately the issues you've experienced (whatever they are) has been fully analyzed and addressed.
comment:3 Changed 10 years ago by
Description: | modified (diff) |
---|
I also fail to see the difference between inline
and __inline__
while in libc sources. You better look at the preprocessor output for those files with your compiler and see what really compiled, my guess would be that inline
is defined to an empty expression for some stupid reason.
There should also be no need for prototyping inlined functions. If you want to start doing that, I require a really good and valid reason for it.
Trunk doesn't need this patch. Time to check build flags and discover what is changed...