Hi David, Thank you for doing this, this looks all very good.
I wish though we had a clear whitelist of features to use or blacklist for features to avoid. Most developers do not use Windows as a primary platform, so it will always be a surprise whether Windows breaks in submit tests. I am also (a bit) concerned about C99 features creeping in which would prevent verbatim backporting of patches to older releases. But let’s see if that is really a problem in practice. Thanks, Thomas On Tue 21. May 2019 at 02:58, David Holmes <david.hol...@oracle.com> wrote: > Thank you everyone for taking a look at this. > > Here is version 2: > > http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ > > Changes: > - set c99 rather than gnu99 > - Volker's change for xlc to match gcc and clang > - added short note to build doc (can do wiki later) > - cosmetic change of name to make variable based on other feedback > during the C++14 discussion > > Thanks, > David > > On 20/05/2019 5:40 pm, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > > > The need to remove a for-loop declaration expression to appease gcc 4.8 > > annoyed me enough to investigate setting C99 as our minimum allow > > C-language level when compiling. It turned out to be a lot more complex > > a situation than I thought due to toolchain quirks. See lots of details > > in the bug report. > > > > To summarise the changes: > > - gcc: force to -std=gnu99 > > - clang force to -std=gnu99 > > - Solaris studio - no effective change > > - Visual Studio - no change > > - xlc - no effective change (but we use the explicit flag rather than > > accepting it as default) > > > > I've checked how this works with all the toolchains except xlc as I have > > no access to that. Some assistance from someone who can verify the > > correctness on xlc would be appreciated. > > > > Thanks, > > David >
