We REALLY nead a NON-PCH build in JPRT NOW!
goetz.lindenmaier at sap.com
Fri Apr 17 10:35:43 UTC 2015
That would be great!!
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:
> another occurance of this ... please, please add a non-pch build to
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.
> Best regards,
> -----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 :)
>> Andrew Dinn
More information about the hotspot-dev