Opened 11 years ago
Closed 11 years ago
#278 closed defect (worksforme)
gcc 4.7.x inline behaviour change
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.
Attachments (1)
Change History (5)
by , 11 years ago
Attachment: | patch-278b.txt added |
---|
comment:1 by , 11 years ago
comment:2 by , 11 years ago
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 by , 11 years ago
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.
comment:4 by , 11 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Trunk doesn't need this patch. Time to check build flags and discover what is changed...