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

[Magnus Ihse Bursie]

On 2016-02-04 21:33, Magnus Ihse Bursie wrote:
> Blir det skillnader mot vårt gamla bygge med devkit men utan din nya fix, eller mellan devkit med din fix och en icke-devkit där man inte använder sysroot? Dvs kan din fix göra så att devkit blir identiskt med utan devkit?

I apologize for this, it was intended to be a personal email to Erik but 
I accidentally hit "Reply all" instead.

/Magnus

>
> /Magnus
>
>> 4 feb. 2016 kl. 14:51 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>
>> 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