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

[David Holmes]

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
>> -----------
>>