[PATCH x86_64][BZ #20139] Don't allow configure with not supporting AVX512 assembler w/o --disable-avx512.

[Mike Frysinger]

On 27 Jun 2016 12:09, H.J. Lu wrote:
> On Mon, Jun 27, 2016 at 12:04 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On 27 Jun 2016 11:25, H.J. Lu wrote:
> >> On Mon, Jun 27, 2016 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> >> > On 27 Jun 2016 20:40, Andrew Senkevich wrote:
> >> >> +'--disable-avx512'
> >> >> +     By default for x86_64, the GNU C Library is built with
> >> >> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
> >> >> +     doesn't support AVX512.
> >> >
> >> > people shouldn't have to pass configure flags like this to get a
> >> > successful build.  we have all the info in order to figure out a
> >> > sane default.  specifying enable/disable flags is purely to not
> >> > use the default autodetection.
> >>
> >> We want to make sure that x86-64 glibc supports AVX512.  Any
> >> suggestions are welcome.
> >
> > i don't see how that's relevant to what i said.  if the assembler can
> > be probed to see if it supports AVX512, then do that.  why do you need
> > a configure flag at all in that case ?
> 
> We want to REQUIRE AVX512 support for x86-64 glibc build.

then why are you adding a configure flag ?  why is AVX512 special
compared to any other ISA feature ?  if the majority of people are
getting their builds from distros, is a flag really needed ?

let's assume that you really really want the flag.  my point still
stands: the default should *not* be fatal *regardless* of what the
assembler supports.  the only time you may throw an error is if the
user explicitly passed --enable-avx512.  the --disable flag is just
a convenience for the cache var, and the default is to use the test
of the assembler to determine whether to enable it in glibc.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160627/22c0f39d/attachment.sig>