RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio

[Erik Joelsson]

A full hotspot run of all solaris targets succeeded with the change.

/Erik

On 2016-02-04 14:51, Erik Joelsson wrote:
> Differences are extensive in most C++ object files. The problem with 
> viewing dissassembly diffs is that any difference tend to change all 
> addresses later in the file.
>
> /Erik
>
> On 2016-02-04 13:43, Erik Joelsson wrote:
>> I will investigate and report back.
>>
>> /Erik
>>
>> On 2016-02-04 13:29, David Holmes wrote:
>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote:
>>>> On 2016-02-03 14:33, Erik Joelsson wrote:
>>>>>
>>>>>
>>>>> On 2016-02-03 13:59, David Holmes wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review this small fix for building on Solaris using a
>>>>>>> devkit/sysroot. The Solaris Studio compiler does special 
>>>>>>> inlining and
>>>>>>> intrinsics with system calls, like memcpy. The problem is that 
>>>>>>> it only
>>>>>>> seems to do this if it finds the definition of the system call in a
>>>>>>> header file in the /usr/include directory. See bug description and
>>>>>>> comments for details.
>>>>>>>
>>>>>>> I have found a way to work around this. Internally, the compiler 
>>>>>>> adds
>>>>>>> the option -I-xbuiltin to mark the start of the system header 
>>>>>>> includes
>>>>>>> when calling a sub process. By adding this to our 
>>>>>>> SYSROOT_CFLAGS, the
>>>>>>> special inlining is re-enabled.
>>>>>>
>>>>>> We have no way of knowing whether that will mess with the compilers
>>>>>> use of other header files. We seem to be on very thin ice here. We
>>>>>> know it fixes this one problem, but we don't know what else it 
>>>>>> may do!
>>>>>>
>>>>> That is true. But then, we don't really know what else this compiler
>>>>> is doing anyway, as is evident by your latest discovery. The way we
>>>>> live with this is testing. We use the setup we have until it proves
>>>>> not to work, we fix and we test. I'm just trying to do the best I can
>>>>> with what we have. I would much prefer to ditch SS for gcc/clang
>>>>> (where we seem to have way less problems) if it was my choice. I'm 
>>>>> not
>>>>> ready to give up the convenience of devkits/portable sysroots just
>>>>> because one of the compilers we (have to) use needs a bit of special
>>>>> handling to behave properly.
>>>>
>>>> I agree that this is a situation that's not really comfortable. :( 
>>>> But,
>>>> as with many other things with the solaris studio compiler, in the end
>>>> it's a result of the limited functionality of that compiler (in this
>>>> case, the lack of a properly functioning --sysroot alternative).
>>>>
>>>> So in light of that, and Erik's comment about testing as the only 
>>>> way to
>>>> be sure, I'd like to see Eriks fix get in.
>>>
>>> Do we have the means to do a binary comparison of the object files 
>>> before/after the change to ascertain what kind of affect this is 
>>> having?
>>>
>>> Thanks,
>>> David
>>>
>>>> /Magnus
>>>>
>>>>
>>>>>
>>>>> /Erik
>>>>
>>
>