This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Michael,
I just noticed that your patches are testing for the BFIN flag. Platform macros such as this are normally underscore-prefixed to avoid clashing with the user macro namespace.
Is there an __BFIN__ or __bfin__ alternative that can be used or is there some change required to the bfin compiler?
-- Jeff J.
Hi Jeff, I investigated further into this and I think I can safely say it's a typo (i.e. bug) in GCC.
What seems to happen is that when GCC sources are compiled the first time, the --with-newlib --with-headers=/opt/gnutools/newlib-1.14.0/newlib/libc/include indeed relies on the header files in the newlib sources.
However, when they are installed on the build host, the header files are not copied as is but the predefines are *expanded* to comply with the underscore naming convention.
On the second re-build (while the first build is still installed i.e.), the newlib header files from the previous installation is used instead (hmm, this is strange in itself). The prebuildt macro is still the same however (i.e. BFIN), and this mismatches with the one in the ieeefp.h header (hence the #ifdef not being recognized).
I.e. the macro gets expanded when it should not. To add sorrow to pain, this behaviour seems to differ between build hosts. I get the same behaviour building on a SuSe 9.2 and a RH9 machine, but building on a freshly installed Cygwin does not make this erroneous expansion.
My conclusion is that the problem seems related to the native build- (or install) tools, which could explain why no one saw this error before (quite possibly this is handled differently on newer build systems).
I know it might seem strange to rebuild the same tools over and over again, and it's in fact not a very good idea as a common practice. But I do this on sources I know I haven't changed and it annoys me to have to rip everything out.
After some experimentation I came up with a solution (see the enclosed patch update). For some (to me unknown) reason, when both BFIN and __BFIN__ are mentioned for the same #if, the expansion on the first macro will *not* occur. Note that it's still BFIN and not __BFIN__ that is the predefined macro. Since both are mentioned the re-build will pass however.
This is not a nice fix IMO, and I'll investigate further and see if I can't get GCC patched to use the underscore naming convention instead. Meanwhile the temporary solution should work and it should also be forwards compatible with the/any future GCC bug-fix.
Regards Michael
Attachment:
_newlib-bfin-more-060926.patch
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |