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