[oi-dev] gcc/gmp assembler integration
Andreas Wacknitz
A.Wacknitz at gmx.de
Fri Feb 19 15:42:54 UTC 2021
Am 19.02.21 um 09:36 schrieb Klaus Ziegler - owner of sunfreeware.de:
> Hi,
>
> I'm currently compiling gcc-7.5.0-il-0 on SPARC in oi-userland,
> while this fact isn't SPARC only, I'm a little bit puzzled about it.
> If you do a "make build" and watch the configure process in
> the first gmp subdir you'll see the following:
>
> configure: creating cache ./config.cache
> checking build system type... i386-pc-solaris2.11
> checking host system type... none-pc-solaris2.11 <------- ?
>
> 4 lines later:
> configure: WARNING: using cross tools not prefixed with host triplet
>
> again 6 lines later there happens a real mess:
> configure: WARNING: the "none" host is obsolete, use --disable-assembly
> checking ABI=standard
>
> this "--disable-assembly" line shouldn't apear at all and it should say
> checking ABI=32, or if you are compiling gcc-10 ABI=64.
> To bring it to the point, all of this also happens on gcc-10!
> It looks like that the whole thing gmp is about - "doing assembly
> acceleration" isn't given trough to all of our oi-userland gcc builds!
> If you have a look in directory: build/i86/gmp/mpn after configure
> has finished it's work, you won't see any *.asm links into the gmp
> sources, this of course proves that non of the assembler code will
> be used in this gmp build.
> The problem is the top-level Makefile.in in the gcc source tree,
> I'm sure that the speed of modern x86 systems is the source
> of the problem that nobody has seen this before, if you do work
> on a 20 year old Ultra60 you have more of chance to see this :-)
> I think, the reason that the top-level Makefile.in is designed this way,
> is the fact that gcc can be cross-compiled, which we won't do at all
> in any of gcc oi-userland builds.
> I've written patches for gcc-7 and gcc-10 to remediate this, I'm
> fairly new to OI processes, so I just don't know how to integrate
> a change like this, while I did my best to get the brand10 bug fixed
> in ticket #13562, shall I just open a new ticket for this and don't
> assign it to myself? or what shall I do? - I just need someone to take
The best way to get things integrated is to create PR's (pull requests)
against oi-userland and wait for comments resp. requests for changes.
In the past people have fixed problems on SPARC by creating PR's that
have been merged by the oi-userland maintainers.
The only thing we request for SPARC related changes: either proof or
convince us that it doesn't harm the x64 builds.
If your changes also involve x64 we can check more easily (eg. albeit I
have old US-III SPARC machines, I only run x64 with OpenIndiana).
I can assure you that all kinds of PR's will be highly appreciated!
I assume that you already cloned our OpenIndiana/oi-userland github
repository into your own
and thus are familiar with the general PR process. If not, I can help
you with it (even in German if you prefer that).
For your concrete problem I would wait until alarcher finds some spare
cycles. He is our specialist in that area. He may have some comments.
Anyway, if you provide a PR it will be easier to discuss and understand
the issues you have detected.
> me by the hand and guide me. If someone want's to try out the
> patches I've done, please reply to me and I'm more than happy
> to provide them, I just didn't attach them to bother anybody in
> the community. BTW. the performace gain on such an old SPARC
> is really sensible :-)
Please try to use the PR process (accompanied with bug tickets). As I
wrote above: if you need any help to get there, feel free to ask.
With PR's it's a lot easier (read: less work) for the maintainers.
Best regards,
Andreas
More information about the oi-dev
mailing list