PR target/47779 - detecting when compiling libgcc

PR target/47779 - detecting when compiling libgcc

[Henderson, Stuart]

Hi,
In order to fix PR target/47779, an enum in a uClibc header (sys/ucontext.h) must be excluded during the compilation of libgcc to avoid a name clash between it and the various register macros in insn-constants.h.

Is there an established/good practice way to do this?

The only macro I can see that is defined specifically during the compilation of libgcc is IN_LIBGCC2, however this is in the user's namespace so can't be used in the header.  Is this by design to prevent the use of the macro in headers?

Any help or advice appreciated,
Stu

Re: PR target/47779 - detecting when compiling libgcc

[Ian Lance Taylor]

"Henderson, Stuart" <Stuart.Henderson@analog.com> writes:

> In order to fix PR target/47779, an enum in a uClibc header (sys/ucontext.h) must be excluded during the compilation of libgcc to avoid a name clash between it and the various register macros in insn-constants.h.
>
> Is there an established/good practice way to do this?
>
> The only macro I can see that is defined specifically during the compilation of libgcc is IN_LIBGCC2, however this is in the user's namespace so can't be used in the header.  Is this by design to prevent the use of the macro in headers?

As I tried to say last time around, the fix is for gcc to not define
those macros when it includes sys/ucontext.h.  As Joseph says in the PR,
the clean way to do this is to avoid including tm.h.  The ugly but much
simpler way is to avoid defining those macros in tm.h, either by never
defining them or by only defining them when IN_LIBGCC2 is not defined.

That is, don't try to fix sys/ucontext.h.  Fix gcc.

Ian

RE: PR target/47779 - detecting when compiling libgcc

[Henderson, Stuart]

>As I tried to say last time around, the fix is for gcc to not define
>those macros when it includes sys/ucontext.h.
I had planned to implement your original suggestion (of renaming the constants), however I thought this would cause significant extra work when changes were merged back upstream from blackfin.uclinux.org.  Someone suggested a more pragmatic fix would be to avoid defining the enum in uclibc, which is why I was looking at that.  I'm happy to make the fix in GCC though.

>As Joseph says in the PR,
>the clean way to do this is to avoid including tm.h.
As much as I'd like to do this, I think it is slightly beyond what I should be attempting whilst I'm still learning about GCC.

>The ugly but much
>simpler way is to avoid defining those macros in tm.h, either by never
>defining them or by only defining them when IN_LIBGCC2 is not defined.
I would appreciate some help here to achieve the latter.  The macros are in the generated insn-constants.h and I don't see a way to add conditional code to this header from the .md file, or know if this is advisable.  Avoiding including insn-constants.h from tm.h when IN_LIBGCC2 would resolve the problem, but I'm unclear on the wider implications of doing this and the reason behind the change that triggered this (r160579) in the first place.
Or do you mean something else altogether?

Thanks again,
Stu

Re: PR target/47779 - detecting when compiling libgcc

[Ian Lance Taylor]

"Henderson, Stuart" <Stuart.Henderson@analog.com> writes:

>>As I tried to say last time around, the fix is for gcc to not define
>>those macros when it includes sys/ucontext.h.
> I had planned to implement your original suggestion (of renaming the constants), however I thought this would cause significant extra work when changes were merged back upstream from blackfin.uclinux.org.  Someone suggested a more pragmatic fix would be to avoid defining the enum in uclibc, which is why I was looking at that.  I'm happy to make the fix in GCC though.
>
>>As Joseph says in the PR,
>>the clean way to do this is to avoid including tm.h.
> As much as I'd like to do this, I think it is slightly beyond what I should be attempting whilst I'm still learning about GCC.
>
>>The ugly but much
>>simpler way is to avoid defining those macros in tm.h, either by never
>>defining them or by only defining them when IN_LIBGCC2 is not defined.
> I would appreciate some help here to achieve the latter.  The macros are in the generated insn-constants.h and I don't see a way to add conditional code to this header from the .md file, or know if this is advisable.  Avoiding including insn-constants.h from tm.h when IN_LIBGCC2 would resolve the problem, but I'm unclear on the wider implications of doing this and the reason behind the change that triggered this (r160579) in the first place.
> Or do you mean something else altogether?

Hmmm, yeah, that is somewhat painful.

If you want to fix this in uClibc, that's fine with me.

The change to include insn-constants.h unconditionally appears to have
just been a cleanup.

http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01179.html

I've CC'ed Richard Sandiford to confirm.  However, it's not hard to
imagine that, now that it works, somebody will expect to be able to use
constants defined in insn-constants.h in ways that matter for libgcc2.c.
So perhaps we should leave that as it is unless Richard thinks
otherwise.

I suppose if you can't fix uClibc then I think you should change the
constants in bfin.md and deal with merges in some other way.  This is
something you should raise with the bfin maintainers, Bernd and Jie.

Ian

Re: PR target/47779 - detecting when compiling libgcc

[Richard Sandiford]

Ian Lance Taylor <iant@google.com> writes:
> The change to include insn-constants.h unconditionally appears to have
> just been a cleanup.
>
> http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01179.html
>
> I've CC'ed Richard Sandiford to confirm.

Actually, it was more than that.  The idea was to allow target headers
such as mips.h to use constants defined in .md files.  This avoided
some cases where the same constant or enum had to appear in both.

Richard

RE: PR target/47779 - detecting when compiling libgcc

[Henderson, Stuart]

>Ian:
> Hmmm, yeah, that is somewhat painful.
>If you want to fix this in uClibc, that's fine with me.
>I've CC'ed Richard Sandiford to confirm.  However, it's not hard to
>imagine that, now that it works, somebody will expect to be able to use
>constants defined in insn-constants.h in ways that matter for libgcc2.c.
>So perhaps we should leave that as it is unless Richard thinks
>otherwise.

>Richard:
>Actually, it was more than that.  The idea was to allow target headers
>such as mips.h to use constants defined in .md files.  This avoided
>some cases where the same constant or enum had to appear in both.


So if I'm to go ahead and fix this in uClibc, would a reasonable fix be to...
GCC: add -D__IN_LIBGCC2 to TARGET_LIBGCC2_CFLAGS in gcc/config/bfin/t-bfin-*
uClibc: include the enum in uClibc #ifndef __IN_LIBGCC2
?

Stu

Re: PR target/47779 - detecting when compiling libgcc

[Ian Lance Taylor]

"Henderson, Stuart" <Stuart.Henderson@analog.com> writes:

>>Ian:
>> Hmmm, yeah, that is somewhat painful.
>>If you want to fix this in uClibc, that's fine with me.
>>I've CC'ed Richard Sandiford to confirm.  However, it's not hard to
>>imagine that, now that it works, somebody will expect to be able to use
>>constants defined in insn-constants.h in ways that matter for libgcc2.c.
>>So perhaps we should leave that as it is unless Richard thinks
>>otherwise.
>
>>Richard:
>>Actually, it was more than that.  The idea was to allow target headers
>>such as mips.h to use constants defined in .md files.  This avoided
>>some cases where the same constant or enum had to appear in both.
>
>
> So if I'm to go ahead and fix this in uClibc, would a reasonable fix be to...
> GCC: add -D__IN_LIBGCC2 to TARGET_LIBGCC2_CFLAGS in gcc/config/bfin/t-bfin-*
> uClibc: include the enum in uClibc #ifndef __IN_LIBGCC2
> ?

I would not accept that if I were a uClibc maintainer, but, sure, that
seems fine from a gcc point of view.

Ian