RFR: 8224087: Compile C code for at least C99 Standard compliance

[David Holmes]

Hi Dean,

On 21/05/2019 8:59 am, David Holmes wrote:
> On 21/05/2019 8:49 am, dean.long at oracle.com wrote:
>> Isn't that going to break inline asm?
> 
> It doesn't appear to. I'll check what the docs say about such things.

Using c99 means we have to use __asm__ for inline-assembly rather than 
"asm" which is the GNU extension.

Looking at our sources we only use inline assembly in C code in two 
places. The main use is in 
./jdk.crypto.ec/share/native/libsunec/impl/ecl*.c which do use the C99 
__asm__ form.

There is one potential problematic usage in:

./jdk.crypto.ec/share/native/libsunec/impl/mpi.c

but that is ifdef'd on OSF1 which I'm assuming is not enabled in our 
builds anyway.

The other use is

./java.desktop/share/native/libfreetype/src/truetype/ttinterp.c

which is also using the C99 form.

So everything looks fine in that regard.

Thanks again for flagging it.

David
-----

> Thanks for flagging it.
> 
> David
> -----
> 
>> dl
>>
>> On 5/20/19 3:40 PM, Erik Joelsson wrote:
>>> That sounds good to me. I missed that distinction before, but pure 
>>> c99 does sound better.
>>>
>>> /Erik
>>>
>>> On 2019-05-20 15:31, David Holmes wrote:
>>>> Hi Volker,
>>>>
>>>> Thanks for the xlc update - I will incorporate that.
>>>>
>>>> It has been suggested that we actually set c99 rather than gnu99 to 
>>>> avoid any GNU extensions creeping in. Does anyone have any concerns 
>>>> with doing that?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 21/05/2019 12:05 am, Volker Simonis wrote:
>>>>> Hi David,
>>>>>
>>>>> thanks for considering AIX in your change.
>>>>>
>>>>> With OpenJDK 13 we've moved to XLC 16 which has a new Clang based
>>>>> frontend. The "ucs" feature-suboption [1] you're using in your change
>>>>> is only supported in the old, xlc compiler but not in the new xlclang
>>>>> any more [2]. However, the good news is that the new xlclang now
>>>>> supports the same "-std=gn99" option like gcc and clang, so you could
>>>>> easily handle the xlc case now together with gcc and clang as shown in
>>>>> this webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/
>>>>>
>>>>> Otherwise, your change looks good!
>>>>>
>>>>> Please let me know once you've pushed it. I opened "8224214: [AIX]
>>>>> Remove support for legacy xlc compiler" [3] for further cleannups
>>>>> because we still set some "-qlanglvl" options for C++ which aren't
>>>>> supported by the new compiler either.
>>>>>
>>>>> Best regards,
>>>>> Volker
>>>>>
>>>>> [1] 
>>>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html 
>>>>>
>>>>> [2] 
>>>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html 
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 20, 2019 at 9:40 AM David Holmes 
>>>>> <david.holmes at oracle.com> 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
>>