Re: [PATCH] s390x: Add single instruction math functions

[Rich Felker <dalias@libc.org>]

On Mon, Jun 12, 2017 at 09:28:52AM -0400, David Edelsohn wrote:
> >> The following IBM table of supported and tested systems
> >>
> >> https://www-03.ibm.com/systems/z/os/linux/resources/testedplatforms.html
> >>
> >> shows that RHEL 7 and SLES 12 require at least z196, and Ubuntu 16.04
> >> requires at least zEC12.
> >>
> >> I can't find any official hardware requirements description for Alpine
> >> Linux. I tend to doubt that user would run it on older hardware,
> >> especially hardware no longer supported by other, modern Linux
> >> distributions.
> >>
> >> Building musl libc on older hardware is a nice accomplishment, but
> >> investing effort and complexity to maintain support probably isn't
> >> useful to any musl libc user and probably isn't a productive use of
> >> developer resources.
> >>
> >> I will continue to inquire if there is a simple technique to accomplish this.
> 
> Apparently GCC 7.1 added architecture macros.
> 
> As Tuan referenced, Alpine Linux also requires z196 as the minimum
> architecture level.  I believe that it would be better for s390-musl
> to default to z196 ISA than musl to require GCC 7.1.

I agree we shouldn't "require GCC 7.1", but using the macros does not
imply such a requirement. For example:

	#if __ARCH__ >= 10

would only use the asm on z196+ (if I got the number right) with GCC
7.1+ (no asm on older compilers), whereas:

	#if __ARCH__ >= 10 || !defined(__ARCH__)

would use the asm on z196+ or on compilers too old to provide __ARCH__
(and building for a more minimal baseline ISA would not be supported
on such compilers unless you manually add -D__ARCH__=5 or whatever to
CFLAGS).

I'm fine with waiting to add those pp conditionals until if/when
someone actually wants to use the lower baseline ISA, if you don't
want to do it now. I am hesitant to add new ISA-forcing logic to
configure, though (see the other reply on that). Would it be bad to
have the build fail with low default -march? If so, maybe the
configure logic could check for !defined(__ARCH__) and then do a
compile test to define __ARCH__ on its own, and we could use the above
logic?

Rich