fastdebug builds broken for jdk9/hs tree?

[Severin Gehwolf]

Hi,

Recently, a fastdebug build of a server JVM fails for me on Linux
x86_64 with older sys/sdt.h and/or GCC. The same failure shows up since
a couple of days on the Zero builder[1]:

/home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp: In static member function ‘static void ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)’:
/home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp:148: error: cannot reload integer constant operand in ‘asm’
/home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp:148: error: cannot reload integer constant operand in ‘asm’
gmake[4]: *** [/home/sgehwolf/openjdk9-hs-pristine/build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/libjvm/objs/classLoadingService.o] Error 1
gmake[4]: Leaving directory `/home/sgehwolf/openjdk9-hs-pristine/hotspot/make'

On that line is a macro for dtrace:

void ClassLoadingService::notify_class_loaded(InstanceKlass* k, bool shared_class) {
  DTRACE_CLASSLOAD_PROBE(loaded, k, shared_class); // <<< This fails

If I compile the same file *without* -DDTRACE_ENABLE it compiles fine.
A slowdebug build compiles fine too. I was able to *reproduce* this on
RHEL 6. It *does not* reproduce on F23.

I had a brief look at the preprocessed compilation unit for
classLoadingService and the code that gets included for the dtrace
macro looks different.

So here the questions:

1.) Has anything related to dtrace macros changed recently?
2.) Has anybody else been seeing this?

Thanks,
Severin

[1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/227/console