RE: PR target/47779 - detecting when compiling libgcc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux