On 2 February 2016 at 17:45, Eric Blake <ebl...@redhat.com> wrote: > On 02/02/2016 10:26 AM, Peter Maydell wrote: >> On 2 February 2016 at 14:51, Eric Blake <ebl...@redhat.com> wrote: >>> Commit 86f4b687 broke compilation on MIPS, which has a preprocessor >>> pollution of '#define mips 1'. Treat it the same way as we do for >>> the pollution with 'unix', so that QMP remains backwards compatible >>> and only the C code needs to use the alternative 'q_mips' spelling. >>> >>> CC: James Hogan <james.ho...@imgtec.com> >>> Signed-off-by: Eric Blake <ebl...@redhat.com> >>> --- > >>> # namespace pollution: >>> - polluted_words = set(['unix', 'errno']) >>> + polluted_words = set(['unix', 'errno', 'mips']) >>> name = name.translate(c_name_trans) >>> if protect and (name in c89_words | c99_words | c11_words | gcc_words >>> | cpp_words | polluted_words): >> >> Looking at commit 86f4b687 I think we also need to add 'sparc' to the >> polluted_words list (Solaris defines that). I would also be unsurprised >> to find that some PPC platforms define 'ppc'. (Tricore is probably >> new enough to have escaped this namespace pollution and we don't >> support it as a host CPU anyway.) > > Do we have anyone that can confirm on these platforms? Obviously, I > proved that it's fairly easy to work around, and I don't mind doing the > followup patch(es), but only if we have concrete cases where we know it > is needed.
I just started up the elderly debian sparc VM image I have lying around and installed the compiler, which is enough to confirm that it does "#define sparc 1". We know PPC Linux doesn't define 'ppc' because the ppc64be build I do as part of pull request processing worked OK. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728710#25 suggests it uses "powerpc" and "PPC" so we're OK there. thanks -- PMM
