BSD variables not declared? (jdk8 & jdk 9 builds)

[Kim Barrett]

On Apr 14, 2015, at 3:42 AM, David Holmes <david.holmes at 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