RFR: 8161145: The min/max macros make hotspot tests fail to build with GCC 6
Kim Barrett
kim.barrett at oracle.com
Fri Jul 15 18:35:08 UTC 2016
> 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.
More information about the hotspot-dev
mailing list