mailing list of musl libc
 help / color / mirror / code / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [PATCH] s390x: Add single instruction math functions
Date: Thu, 15 Jun 2017 08:18:06 -0400	[thread overview]
Message-ID: <CAGWvnym1ooOutyoP3EjBesW-OY-ifGPqQvBTrzd_dmRceJAUKA@mail.gmail.com> (raw)
In-Reply-To: <20170614234426.GI1627@brightrain.aerifal.cx>

On Wed, Jun 14, 2017 at 7:44 PM, Rich Felker <dalias@libc.org> wrote:
> 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.

The above comment seems to state that it's okay not to add the
__ARCH__ logic for now, until someone actually shows a need.  Which is
great.

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?

And this second comment seems to state that you want the __ARCH__
logic and additional configure logic to set __ARCH__ to a default
value that supports z196 if the compiler does not define __ARCH__.

These two statements seem contradictory.

This is an awful lot of time and effort on the part of everyone in
this discussion for architecture support that never will be utilized.

Thanks, David


  reply	other threads:[~2017-06-15 12:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-09 14:51 David Edelsohn
2017-06-10 15:36 ` Szabolcs Nagy
2017-06-10 17:25   ` David Edelsohn
2017-06-10 18:29     ` Szabolcs Nagy
2017-06-10 18:53       ` David Edelsohn
2017-06-10 19:48         ` Rich Felker
2017-06-10 20:22           ` David Edelsohn
2017-06-10 21:28             ` Szabolcs Nagy
2017-06-10 21:44               ` David Edelsohn
2017-06-10 21:48                 ` David Edelsohn
2017-06-11  2:20                   ` Rich Felker
2017-06-11 10:19                     ` Szabolcs Nagy
2017-06-11 15:04                       ` Rich Felker
2017-06-11 16:45                         ` Szabolcs Nagy
2017-06-11 21:45                           ` Rich Felker
2017-06-12  2:46                       ` David Edelsohn
2017-06-12  4:36                         ` Tuan M. Hoang
2017-06-12  9:03                         ` Szabolcs Nagy
2017-06-12 13:28                           ` David Edelsohn
2017-06-12 13:54                             ` David Edelsohn
2017-06-12 20:28                               ` Szabolcs Nagy
2017-06-12 21:02                                 ` David Edelsohn
2017-06-13 15:55                                   ` Szabolcs Nagy
2017-06-14 23:34                                     ` Rich Felker
2017-06-14 23:40                                       ` A. Wilcox
2017-06-14 23:44                             ` Rich Felker
2017-06-15 12:18                               ` David Edelsohn [this message]
2017-06-18 17:12                               ` David Edelsohn
2017-06-21  0:49                                 ` Rich Felker
2017-06-21  1:07                                   ` David Edelsohn
2017-06-21  1:20                                     ` Rich Felker
2017-06-21  3:34                                       ` David Edelsohn
2017-06-23 19:31                                         ` Rich Felker
2017-06-10 21:37             ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGWvnym1ooOutyoP3EjBesW-OY-ifGPqQvBTrzd_dmRceJAUKA@mail.gmail.com \
    --to=dje.gcc@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).