We REALLY nead a NON-PCH build in JPRT NOW!

[Coleen Phillimore]

Can we just switch the default instead?  Is that a simple makefile change?
Coleen

On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote:
> That would be great!!
>
> Thanks David,
> Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Freitag, 17. April 2015 12:23
> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn
> Cc: HotSpot Open Source Developers
> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW!
>
> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> another occurance of this ...  please, please add a non-pch build to
>> jprt!
>> https://bugs.openjdk.java.net/browse/JDK-8078048
> I will. Unfortunately first I have some no-PCH issues to address. And
> unfortunately they are not top of my priority list right now. Hopefully
> next week sometime.
>
> David
>
>> Best regards,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis
>> Sent: Donnerstag, 9. April 2015 11:35
>> To: Andrew Dinn
>> Cc: HotSpot Open Source Developers
>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW!
>>
>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn <adinn at redhat.com> wrote:
>>> On 09/04/15 09:02, Erik Joelsson wrote:
>>>> I think that as long as we claim to support building both with and
>>>> without PCH, the automatic testing should test both with and without
>>>> PCH. By adding one or two build targets, or perhaps change an existing
>>>> target, we could increase our test matrix to cover this easily.
>>> I think this restates Volker's original remarks in redux.
>>>
>> No, not at all! I don't necessarily want to test more build
>> configurations (that's another topic).
>>
>> My point is that PCH changes the compilation semantics and can hide
>> real program errors. That's because with PCHs, every compilation unit
>> sees the full precompiled header database (i.e. all the headers which
>> are included in the "precompiled.hpp" PCH file). So if somebody
>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still
>> compile with PCH because it includes the precompiled header file
>> "precompiled.hpp" which in turn includes X.hpp. But the compilation of
>> A.cpp will fail on platforms/configurations where we do not use
>> precompiled headers. The two references I gave in my original mail are
>> bugs that resulted from this problem.
>>
>> Besides program errors, the use of PCH can also lead to behavioral
>> changes in the created binary when it comes to inlining. Because of
>> PCHs some compilation units may be able to inline methods even if they
>> do not explicitly include the files which contain the corresponding
>> implementations because the implementation files are included in the
>> PCH file. Without PCHs the compilers will simply emit calls to these
>> functions (and, depending on the toolchain, emit a warning).
>>
>> I'm not familiar with ccache so I can not say if it has similar effects.
>>
>>> So, given that we do need this (NOW! :-) is anyone able and willing to
>>> sponsor this?
>>>
>> Yes, this question remains to be answered :)
>>
>> Regards,
>> Volker
>>
>>> regards,
>>>
>>>
>>> Andrew Dinn
>>> -----------
>>>