[PATCH] linux-sparc build fixes

John Paul Adrian Glaubitz glaubitz at physik.fu-berlin.de
Wed Jun 14 12:46:07 UTC 2017

On Wed, Jun 14, 2017 at 02:30:24PM +0200, Erik Helin wrote:
> >I'm not 100% whether I did that. I'm not very familar with mercurial
> >as I'm more used to git. If the patch format looks wrong to you, I can
> >resend a revised version of this patch.
> No worries, someone will have to commit your patches anyway (most likely
> me). I can have a look then and ensure that `hg mv` is used for renaming the
> file.

Great, thank you!

> >>For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For
> >>example, the following is a bit surprising to me (mostly because I'm not
> >>familiar with zero):
> >
> >The fourth patch may not be a 100% clean as it's more a result of
> >fixing compile errors until the build finished. I can definitely send
> >a revised, cleaner version of this patch after more extensive testing.
> Yeah, I guessed that was the case :) Without the fourth patch
> (fix-zero-build-on-sparc.diff), does the "regular" linux/sparc build compile
> and run? Is that something you can test?

I will have a look tonight. I'm currently at work.

> Also, have you run the tier 1 testing for hotspot (the tests that need to
> pass for every commit)? You can run those tests by running (from the
> top-level "root" repo):
> $ make test TEST=hotspot_tier1
> or, if you want to try the new run-test functionality
> $ make run-test-hotspot_tier1

Ok, I will give that a try.

> >>When this code was written, the intent was clearly to have a specialized
> >>version of this function for SPARC. When writing such code, do we always
> >>have to take into account the zero case with !defined(ZERO)? That doesn't
> >>seem like the right (or a scalable) approach to me.
> >
> >I agree. It's rather suboptimal.
> Yes, which is why I want to get a better understanding before I give a
> "thumbs up" for this last patch. I hope (suspect) that there is a better way
> to do this.


> >Can't wait for my first patches getting merged into OpenJDK ;-).
> Well, you do need one more reviewer for your patches. Hotspot requires at
> least two reviewers for every patch (and one of the reviewers has to have
> the Reviewer role).

Hey, it's a first step ;-).


 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

More information about the hotspot-dev mailing list