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

Erik Österlund erik.osterlund at oracle.com
Wed May 31 11:07:44 UTC 2017

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 . 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 GLIBCXXSTDLIBH #define max(a,b) DonotusemaxuseMAX2instead #define min(a,b) DonotuseminuseMIN2instead +#endif // It is necessary to use templates here. Having normal overloaded // functions does not work because it is necessary to provide both 32-

GLIBCXXSTDLIBH 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 . 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 . 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 globalDefinitionsvisCPP.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 GLIBCXXSTDLIBH. 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

More information about the hotspot-dev mailing list