"Henderson, Stuart" <Stuart.Henderson@xxxxxxxxxx> 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
