On Apr 14, 2015, at 3:42 AM, David Holmes <david.hol...@oracle.com> wrote: > > On 14/04/2015 5:24 PM, Magnus Ihse Bursie wrote: >> On 2015-04-12 17:01, Martijn Verburg wrote: >>> Hi all, >>> >>> On Mac OS X 10.10.2 using gcc 4.8 run make clean images >>> >>> When compiling either jdk8 or jdk9 from scratch I get the following BSD >>> undefined errors: >>> >>> Compiling >>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp >>> >>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1150:7: >>> >>> error: "__FreeBSD__" is not defined [-Werror=undef] >>> #elif __FreeBSD__ >>> ^ >>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1152:7: >>> >>> error: "__OpenBSD__" is not defined [-Werror=undef] >>> #elif __OpenBSD__ >>> ^ >>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1154:7: >>> >>> error: "__NetBSD__" is not defined [-Werror=undef] >>> #elif __NetBSD__ >> >> That sounds strange. Why would an undefined preprocessor variable >> trigger an error? I have never heard about this before. > > "-Wundef option causes GCC to warn whenever it encounters an identifier which > is not a macro in an ‘#if’. " > > Hence we should be using > > #elif defined(__FreeBSD__) > > etc in this context. It may be the compiler normally doesn't look at the > erroneous else cases, but this compiler does (or else __APPLE__ is not > defined and so we hit these else cases where we don't normally.) ?? > >> Since it is in hotspot code, maybe you can get a better response by >> asking on a hotspot list. > > Yes looks like a hotspot issue. I filed: > > https://bugs.openjdk.java.net/browse/JDK-8077674 > > Follow ups on hotspot-runtime-dev please. > > David
Should we be building with -Wundef at all? The code being complained about is standards conforming and has a well defined meaning. The proposed changes could result in unexpectedly different behavior, either now or in the future. Do we know for sure that for all of the #elif IDENTIFIER => #elif defined(IDENTIFIER) changes there are no situations where IDENTIFIER might be defined 0? This might be of interest: https://gcc.gnu.org/gcc-4.4/porting_to.html Preprocessor conditionals always evaluated
