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

Kim Barrett kim.barrett at oracle.com
Mon Jul 11 21:44:29 UTC 2016


> On Jul 11, 2016, at 5:32 PM, Omair Majid <omajid at redhat.com> wrote:
> 
> Hi Kim,
> 
> Thanks for the review!
> 
> * Kim Barrett <kim.barrett at oracle.com> [2016-07-11 17:28]:
>>> On Jul 11, 2016, at 2:45 PM, Omair Majid <omajid at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161145
>>> Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8161145-gcc6-min-max-macros/00/
>> 
>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide
>> All .cpp files include precompiled.hpp as the first include line.
> 
> Thanks for the pointer. I was not aware of this.
> 
>> I think a different approach is needed.  Perhaps don't provided the
>> poisoned definitions at all.
> 
> That sounds like the best solution in the long term. But I am afraid to
> remove it because it was probably added for a reason and I am not
> familiar with the code.
> 
>> Or maybe we can use blue paint, e.g.
>> 
>>  #define min min
>>  #define max max
> 
> Should I implement this approach? Or should I look into removing the
> poisoned definitions?

I suspect the poisoning exists because these names are defined as
macros by a frequently used Windows system header (windefs.h?), and we
want to ensure Hotspot code doesn't accidentally use them.  I think
the blue paint approach would produce a similar result, but I haven't
tested it (and I'm not well versed in the foibles of Visual Studio's
preprocessor, though have seen many complaints about its
non-compliance).



More information about the hotspot-dev mailing list