fastdebug builds broken for jdk9/hs tree?

[Severin Gehwolf]

On Fri, 2016-04-29 at 15:30 +0200, Severin Gehwolf wrote:
> On Fri, 2016-04-29 at 09:21 +0100, Andrew Haley wrote:
> > 
> > On 29/04/16 08:56, Severin Gehwolf wrote:
> > > 
> > > 
> > > Here you go (DTRACE_CLASSLOAD_PROBE(loaded, k, shared_class);
> > OK.  Now take that expansion, run indent on it, and paste it in
> > to the program where the macro was.  Then we'll be able to get
> > much better info about the reload failure.
> For the curious, this is the bit that trips up GCC 4.4.7 and GCC 4.7.2
> and seems to work fine on GCC 5.3.1:
> 
> --- /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp.fail_mini	2016-04-29 14:56:30.711924152 +0200
> +++ /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp	2016-04-29 14:57:00.102527106 +0200
> @@ -170,7 +170,7 @@
>                              "\n"::
>                              [_SDT_S3]
>                              "n" ( 1 ),
> -                            [_SDT_A3] "nor" ( ((k)->class_loader ())));
> +                            [_SDT_A3] "nor" ( 1 ));
>        __asm__ __volatile__ (".ifndef _.stapsdt.base" "\n"
>                              ".pushsection .stapsdt.base" "," "\"aG\"" ","
>                              "\"progbits\"" "," ".stapsdt.base" "," "comdat"
> 
> Affected GCC versions choke on the "(k)->class_loader ()" bit with -O3
> :-(

The real cause for this is the extra code compiled in when
CHECK_UNHANDLED_OOPS is defined. That's the case for fastdebug builds
only. I'm not sure why this shows up now, but I've filed this bug in
any case:

https://bugs.openjdk.java.net/browse/JDK-8155828

Cheers,
Severin