Re: [PATCH] add bfin target

["Michael Ambrus" <ambrmi09 at gmail dot com>]

On 9/26/06, Jeff Johnston <jjohnstn@redhat.com> wrote:
> 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