On Fri, Oct 30, 2015 at 9:11 PM, Bernd Schmidt <bschm...@redhat.com> wrote: > On 10/30/2015 01:47 PM, Richard Biener wrote: >> >> On Fri, Oct 30, 2015 at 1:28 PM, Bernd Schmidt <bschm...@redhat.com> >> wrote: >>>> >>>> >>>> it's not target independent code. Are you suggesting to add a config/ >>>> to libobjc? IMHO for a not really mantained frontend / target lib >>>> that's >>>> an excessive requirement. >>> >>> >>> >>> If necessary, then yes that would be a better solution. >>> >>> Even just keeping the abstraction of the macro and putting definitions of >>> it >>> inside #ifdef at the top of the file would be an improvement over the >>> submitted patch, but IMO still not really compatible with our standards. >> >> >> I agree, that would make the source of the copy more obvious. > > > If we go down that path, there's another minimum requirement - adjust the > docs to say that the macro must be defined in two places. That's my main > worry, someone creating a new port, completely oblivious that they'd have to > modify library code for it to work.
That happens already with respect to libffi anyways. libffi knows the inter-working of how ABIs work and has many target specific assembly code. If you look at libsanitizer, the code is even worse with all the macros that need to be changed and I rather not go down that route where we have processor specific #ifdefs in the code. Yes libobjc is mostly just works but going the route of libsanitizer is just wrong and makes a really bad precedent of target libraries. Even libgomp has some target specific headers and is very short of the number of headers/defines you need to change to it working (most of the time none). Thanks, Andrew > > > Bernd
