On Mon, Dec 19, 2016 at 01:20:14PM -0500, Neal Gompa wrote: > >> The most common source is <altivec.h> from GCC. > > > > These days (for several GCC releases), powerpc as well as spu and recently > > also s390 (z13) use conditional macros for bool, vector, pixel and _Bool, > > which expand differently depending on what is the following token. > > But the conditional macros are defined only in the non-strict C/C++ modes, > > the above is compiled with -std=c++11 rather than -std=gnu++11, but then > > one shouldn't include altivec.h if they want standard behavior. > > Alternative is to include altivec.h and > > #undef vector > > #undef pixel > > #undef bool > > and then of course you need to use __vector, __pixel and __bool instead of > > vector, pixel or bool if you want the Altivec-ish behavior rather than > > standard. > > > > We're not including altivec.h, not directly. At least with main.cpp, > it looks like it's being pulled in by our usage of STL, specifically > set. There's also a strange error about vec_cond_expr not supported? The STL does not include altivec.h, so it must be something else. You can use g++ -E -dD ... to see what included it. > /home/fedora/lugaru-pkg/lugaru-1.1-mods/Source/main.cpp:665:25: error: > could not convert ‘#‘vec_cond_expr’ not supported by > dump_expr#<expression error>’ from ‘__vector(4) int’ to ‘bool’ That is just a consequence of bool meaning something completely different from what the code expects. So, first either find out what includes altivec.h and why, either avoid it or undef the keywords afterwards, or use -std=gnu++11 mode rather than -std=c++11 to make sure the macros are contextual. Jakub _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
