> On Jul 6, 2016, at 1:23 AM, Andrew Hughes <gnu.and...@redhat.com> wrote:
>
> ----- Original Message -----
>>> On Jul 5, 2016, at 1:33 PM, Andrew Hughes <gnu.and...@redhat.com> wrote:
>>>
>>> ----- Original Message -----
>>>>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes <gnu.and...@redhat.com> wrote:
>>>> common/autoconf/flags.m4
>>>> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}"
>>>>
>>>> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It
>>>> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about
>>>> the BUILD/TARGET distinction.
>>>
>>> This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS
>>> and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the
>>> FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used
>>> in several places. I think this is outside the scope of this patch and
>>> something which should be fixed by completing the current half-hearted
>>> cross-compilation support. My aim here is just to fix the regression
>>> which breaks the GCC 6 support on build==target builds, and I'd rather
>>> whoever was working on the cross-compilation build continued that work.
>>> There is a solution already in the handling of the warning argument
>>> check, but it needs to be generalised to the other cases.
>>
>> I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope
>> for this patch.
>>
>> What I'm worried about is that by keeping those checks we might get
>> and use the wrong answer in some cases where the BUILD and TARGET
>> compilers are of different vintage. Maybe that will just encourage
>> someone to fix them...
>
> Thanks. I agree it's an issue. I just don't think I'm the right person
> to undertake rewiring all that, as I've never even used the cross-compilation
> support so far.
Yeah, I feel the same way. While I've dealt with cross-compilation
issues of this sort enough to recognize the presence of problems, that
work wasn't with this build system.
> Do you know if there's already a bug for this? If not, I'll file one.
I didn't find any relevant bugs.
>> In the specific case of -std=gnu++98, it seems unlikely we'll see such
>> a misconfiguration any time soon. That option was introduced in
>> gcc3.3, and it seems unlikely to me that anyone is building the JDK
>> with such an old compiler (though it wouldn't be the first time I've
>> been surprised in that way). OTOH, if the compiler is very new and has
>> dropped support for that standard (e.g. some as yet not even announced
>> version of gcc), we actually want a build failure, since our code was
>> written for that standard and not some later one. So we're unlikely to
>> be hurt by the use of xxx_CHECK_ARGUMENTS here.
>>
>
> I agree it's more likely that gnu++98 is going to be dropped at some point,
> than we had a compiler that doesn't support the -std option. Hopefully,
> making what was an implicit default before now explicit will encourage
> developers to look at moving the code forward to a later version of the
> standard. That's probably something for JDK 10+ though.
I think there is interest in that direction.
>> I think there are some more that are outside of HotSpot.
>>
>> Searching the build directory for *.o.cmdline files that don’t contain
>> -std=gnu++98, e.g.
>>
>> find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print
>> | xargs dirname | uniq
>>
>> produces a lot of stuff in ./support/native, the afore mentioned adlc, and a
>> smattering of others.
>>
>> I think those might be better addressed by more followups, to get what we’ve
>> got so far in.
>
> Thanks for the .cmdline trick. I wasn't aware of that.
The .o.cmdline files are a feature of the new build system that I
like a lot.
> The -std=gnu++98 switch is only appropriate for the C++ compiler. Most of the
> support/native object files are C files.
>
> C++ code is used in the following:
> […]
> Using find . -name "*.o.cmdline" -exec egrep -q -e "g\+\+" {} \; ! -exec
> egrep -q -e "-std=gnu\+\+98" {} \; -print
> I don't see any remaining files with the latest patch.
Yay!
>> But you will need that fix for JDK-8157358. I guess I should post an
>> RFR for it... or you can just incorporate it into this patch if I don’t get
>> that RFR done soon.
>
> I wasn't planning to either, but it was likewise bugging me when I
> was trying to fix the GCC 6 issue. Ironically, it took much longer to
> work out what was going on there than it did to realise I needed to
> add the flags to JVM_CFLAGS :(
>
> I've included the fix in this patch, assuming that's ok with you.
Yes, that’s fine with me.
> If gcc is not being used, CXXSTD_CXXFLAG won't be set so this should be a
> safe no-op.
Oh, right.
> Revised webrevs:
>
> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root
> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot
These look good to me.
> I'm also now seeing a problem with GCC 6 only that is unique to the latest
> OpenJDK 9
> and what looks like the gtest code. It seems to be the result of the header
> changes
> also documented in [0] which were introduced in January [1] (and so probably
> weren't
> in earlier test versions of GCC 6). I'm able to work around it and get a
> completed
> build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be
> something
> to do with the changes to stdlib.h in GCC 6. Something for a separate bug.
What fun!
> [0] https://gcc.gnu.org/gcc-6/porting_to.html
> [1]
> https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
