Re: PR target/47779 - detecting when compiling libgcc

[Ian Lance Taylor <iant at google dot com>]

"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