Re: jdk8u: -Wno-regsiter to support newer compilers

[Stewart X Addison]

Hi Elazar,

> How is adoptium building it? Does it use specific compiler?

Yes - Adoptium uses our own build of gcc 7.5.0 to build Temurin's jdk8u on
Linux. If you wish to use the same environment as us, the simplest way is
to pull the `adoptopenjdk/centos7_build_image` and use that which will be a
preconfigured environment (replace centos7 with centos6 if on x64 for
exactly the one we use, but 7 will likely work too) and you should be able
to use the temurin-build scripts in that container. The 7.5.0 compiler is
under `/usr/local/gcc` in that image. Other GCC versions are installed
under /usr/local that we use for different versions of the JDK. If you
specifically want to go down the route of creating those containers
yourself from scratch, they are set up using ansible in the dockerfiles
from https://github.com/adoptium/infrastructure/tree/master/ansible/docker.

> FTR using temurin-build repository and scripts, fails for other reasons,
and fails even with -D/--podman docker containers.

Thanks for the info. If you could raise an issue with the details of that
over at https://github.com/adoptium/temurin-build that would be
appreciated. While we don't use those options in the main temurin build
processes they are useful for other users of our scripts and someone has
been updating and testing those options recently (after a bit of
stagnation) to add the support for podman so I believe they should be in a
reasonable state at the moment. Hopefully we can get that fixed if they are
currently misbehaving in some environments.

Hope that helps.

Regards,

Stewart...
--
Working for Red Hat  on Adoptium Temurin
 and Node.js

https://fosstodon.org/@sxa
https://github.com/sxa




On Tue, 6 Aug 2024 at 17:37, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> Hi Elazar,
>
> I see that you never got any replies here. I suggest that you re-ask
> your question on the jdk8u mailing list instead (cc'd).
>
> /Magnus
>
> On 2024-07-19 16:20, Elazar Leibovich wrote:
> > When trying to compile the latest jdk8u on linux I get failures over
> > warnings with the register keywords.
> >
> > I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be
> > pretty up to date (I'm using master), and last commit is less than two
> > days ago.
> >
> > This is a workaround I had to use:
> > diff --git a/hotspot/make/linux/makefiles/gcc.make
> > b/hotspot/make/linux/makefiles/gcc.make
> > index 7dde7f0963..81f156574a 100644
> > --- a/hotspot/make/linux/makefiles/gcc.make
> > +++ b/hotspot/make/linux/makefiles/gcc.make
> > @@ -202,7 +202,7 @@ else
> >  endif
> >
> >  # Compiler warnings are treated as errors
> > -WARNINGS_ARE_ERRORS = -Werror
> > +WARNINGS_ARE_ERRORS = -Werror -Wno-register
> >
> > But I guess the best solution is to remove the register keywords from
> > the codebase.
> >
> > How is adoptium building it? Does it use specific compiler? Is the
> > supported compiler documented anywhere?
> >
> > FTR using temurin-build repository and scripts, fails for other
> > reasons, and fails even with -D/--podman docker containers.
> >
> > This patch builds it with centos stream 9 on amd64.
> >
> > Am I doing something wrong? What's the recommended way of building jdk8?
> >
> > Thanks,
> > Elazar Leibovich
>
>

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11]

[Stewart X Addison]

On Tue, 16 Jul 2024 08:21:04 GMT, Andrew Haley  wrote:

> This is starting to sound like we need a policy decision, because we don't 
> want to re-hash this discussion every time the question comes up, as it 
> surely will. 

+1 to this if we don't already have one

While I haven't read through every comment in this thread in this specific case 
I generally agree with what @theRealAph has said in some of his earlier 
comments. My primary concern is that the generated code in there is currently 
effectively unreviewable in terms of checking for potential vulnerabilities so 
I also feel it's best to check in the whole (reviewable) source if this PR is 
to be accepted. Much as I dislike repository bloat I think it's a fairly easy 
decision in this case IMHO with SLEEF being 7.5MB in size when the openjdk 
codebase is so large.

An alternative "absolute minimum" would be to reference the GitHub SHA of the 
SLEEF source and include the process for regenerating it reproducibly so that 
this information is available to anyone who wanted to verify it. With my 
distributor (Temurin) hat on either of those solutions would mean we have the 
original source referenced for inclusion in the product SBOM to track the 
supply chain. I'll also note that I'm also making an assumption here that the 
generated code from SLEEF is reproducible and not sensitive to the build 
environment like the CDS archives - I have not tried building them myself to 
verify but I feel that is important to understand before merging the generated 
code.

As a project should also consider whole issue of ensuring that we have 
sufficient trust from a supply-chain perspective on the SLEEF source ... I have 
no specific reason to distrust it but it might be good to understand how well 
reviewed it is before doing this as it's not a project I'm personally familiar 
with.

_On a slightly separate note (and I see @luhenry is in this comment thread too 
and has contributed to SLEEF) it will be good if this can be used to enhance 
the performance on RISC-V too in the future ;-)_

-

PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230569814

Re: RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc [v3]

[Stewart X Addison]

On Tue, 9 Apr 2024 17:01:59 GMT, Thomas Stuefe  wrote:

>> @suchismith1993
>> Hi Suchi, can you please tell me when you will raise your build environment 
>> from AIX 7.2 TL5 SP5 to SP7?
>> I' am asking you, because I want to get rid of this nasty workaround.
>
> Pinging @sxa - what build environment does temurin use for AIX?

Currently XLC16 but looking to upgrade to XLC17 on the minimum supported level 
for it (So it wouldn't be SP7 at present). Thanks for the ping - we have no 
current plans to increase to SP7.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1558053537