RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6

[Erik Österlund]

Hi,

I am bringing back this blast from the past. I also need a solution for 
this for the GC interface that wishes to use <limits>.
I propose to do what Kim suggested - to #define max max and #define min 
min. This way the innocent "max" identifiers that have nothing to do 
with any macros will build as they should, and any accidental consumer 
of a potential max() macro will find a compiler error as intended. Is 
anyone left unhappy with this solution?

Thanks,
/Erik

On 2016-08-16 15:25, Severin Gehwolf wrote:
> On Fri, 2016-07-15 at 14:35 -0400, Kim Barrett wrote:
>>>>> On Jul 13, 2016, at 3:12 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>> On Jul 12, 2016, at 2:21 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>>> The workaround that currently works for me is:
>>>>>
>>>>> diff -r b515beb3b4ad src/share/vm/utilities/globalDefinitions.hpp
>>>>>>>>> --- a/src/share/vm/utilities/globalDefinitions.hpp	Thu Jul 07 18:40:53 2016
>>>>> +0100
>>>>>>>>> +++ b/src/share/vm/utilities/globalDefinitions.hpp	Tue Jul 12 19:13:51 2016
>>>>> +0100
>>>>> @@ -1163,8 +1163,10 @@
>>>>> #undef min
>>>>> #endif
>>>>>
>>>>> +#ifndef _GLIBCXX_STDLIB_H
>>>>> #define max(a,b) Do_not_use_max_use_MAX2_instead
>>>>> #define min(a,b) Do_not_use_min_use_MIN2_instead
>>>>> +#endif
>>>>>
>>>>> // It is necessary to use templates here. Having normal overloaded
>>>>> // functions does not work because it is necessary to provide both 32-
>>>>>
>>>>>
>>>>> _GLIBCXX_STDLIB_H only exists in GCC 6. Earlier versions use stdlib.h from
>>>>> the
>>>>> C library. Thus this seems to provide the solution of only disabling
>>>>> those macros only on GCC >= 6 where they conflict with the functions
>>>>> max and min defined by this C++ stdlib.h wrapper (see stdlib.h changes
>>>>> in [0])
>>>> Since when does <stdlib.h> define / declare min or max?  To me, that seems
>>>> like a bug in this wrapper.
>>> It doesn't; it's defined in <limits>.
>>>
>>> The stdlib.h C++ wrapper is new to GCC 6, and thus so is the define, so we
>>> can use it to just disable these macros on that version.
>>>
>>> It also wouldn't surprise me that the error is down to one of these new
>>> wrapper headers bringing in other C++ headers, including limits. I
>>> can't find the exact path for such an inclusion, but this issue
>>> only shows up on GCC 6, where the wrapper headers are present.
>>> Including <stdlib.h> on earlier versions just uses the C
>>> header, not <cstdlib>.
>> That seems a likely explanation.
>>
>> If my conjecture about these being intended to poison the windefs.h
>> definitions is correct, then we could just move these definitions to
>> globalDefinitions_visCPP.hpp.  But I don't know if anyone could answer
>> that definitively.
>>
>> We try pretty hard to avoid platform-specific #ifdefs and the like in
>> otherwise generic code.  I think that's a good thing, hence my
>> reluctance to conditionalize on _GLIBCXX_STDLIB_H.
>>
>> After some experiments, my preferred solution would be the blue paint
>> approach I suggested as a possibility earlier, e.g.
>>
>> #define max max
>> #define min min
>>
>> A later attempt to (re)define without #undef would make the program
>> ill-formed, and all the compilers Oracle supports report such.
>>
>> In the absence of any attempt to redefine, the macros expand to
>> similarly named identifiers, e.g. it's as if the macro definitions
>> didn't exist, except for defined(max) &etc being true.
> Hi!
>
> How can we move forward with this? Fedora 24 has GCC 6 as default and
> anybody on that platform will need patches to get OpenJDK building.
>
> Thanks,
> Severin