[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx
From:       serguei.spitsyn () oracle ! com
Date:       2019-06-29 2:05:43
Message-ID: c6bc5842-9bcf-2e12-6ffe-f78f0d9a4726 () oracle ! com
[Download RAW message or body]

Hi Matthias,

The fix is good.
It worked before because both JVMTI_REFERENCE_ARRAY_ELEMENT
and JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT have the same value 3
as Gary noticed.

I'd suggest to fix it in 13 as it is the test fix.
I've added labels 'testbug' and 'noreg-self'.

Thanks,
Serguei

On 6/28/19 12:04 PM, David Holmes wrote:
> Hi Matthias,
> 
> Dropped build-dev and added serviceability-dev as this is a 
> servicability test.
> 
> On 28/06/2019 7:43 am, Baesken, Matthias wrote:
> > Hello please review this   small fix for a compile issue   on OSX .
> > Today I   compiled     jdk/jdk     on a machine   with     XCode 10.2   . It 
> > worked pretty well .
> > However this small issue showed up .
> > 
> > 
> > In file included from 
> > /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33:
> >  /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: \
> >  error:
> > comparison of two values with different enumeration types in switch 
> > statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') 
> > [-Werror,-Wenum-compare-switch]
> > 
> > 
> > And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT     is 
> > from a different   enumeration type   and should be replaced   with the 
> > value   from the correct enumeration type     .
> > 
> > Bug / webrev :
> > 
> > https://bugs.openjdk.java.net/browse/JDK-8226943
> > 
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/
> 
> The fix seems reasonable but the issue indicates a further problem 
> with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but 
> was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit 
> the default clause and failed the test. That suggests the test doesn't 
> actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place.
> 
> Cheers,
> David
> 
> > 
> > Thanks, Matthias
> > 


[prev in list] [next in list] [prev in thread] [next in thread]