[Bug bootstrap/54419] New: [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on x86_64-apple-darwin10

[Bug bootstrap/54419] New: [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

             Bug #: 54419
           Summary: [4.8 Regression] Compiling
                    libstdc++-v3/src/c++11/random.cc fails on
                    x86_64-apple-darwin10
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: drepper.fsp@gmail.com, iains@gcc.gnu.org
              Host: x86_64-apple-darwin10
            Target: x86_64-apple-darwin10
             Build: x86_64-apple-darwin10


Bootstrapping revision 190787 fails on x86_64-apple-darwin10 with:

libtool: compile:  /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/
-B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem
/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem
/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include
-I/opt/gcc/work/libstdc++-v3/../libgcc
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++ -std=gnu++11 -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=random.lo -g -O2 -c
../../../../../work/libstdc++-v3/src/c++11/random.cc  -fno-common -DPIC -o
random.o
/var/tmp//ccZpDauf.s:28:no such instruction: `rdrand %eax'

Note that on darwin10 as is fairly old: GNU assembler version 1.38.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-apple-darwin10       |x86_64-apple-darwin10
                   |                            |i686-pc-linux-gnu
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-08-30
               Host|x86_64-apple-darwin10       |x86_64-apple-darwin10
                   |                            |i686-pc-linux-gnu
            Summary|[4.8 Regression] Compiling  |[4.8 Regression] Compiling
                   |libstdc++-v3/src/c++11/rand |libstdc++-v3/src/c++11/rand
                   |om.cc fails on              |om.cc fails on platforms
                   |x86_64-apple-darwin10       |not knowing rdrand
     Ever Confirmed|0                           |1
              Build|x86_64-apple-darwin10       |x86_64-apple-darwin10
                   |                            |i686-pc-linux-gnu

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-08-30 19:41:12 UTC ---
It also fails on i686-pc-linux-gnu (see
http://gcc.gnu.org/ml/gcc-regression/2012-08/txt00009.txt).

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #2 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-08-30 20:19:35 UTC ---
The instruction is generated by the compiler.  If you try to compile a new
compiler you have to make sure the tools used are recent enough to understand
the output of the compiler.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-08-30 20:37:59 UTC ---
> The instruction is generated by the compiler.  If you try to compile a new
> compiler you have to make sure the tools used are recent enough to understand
> the output of the compiler.

Well, I think the compiler should check that the tools (or the CPU) support the
output it emits. Isn't it the purpose of the configure stages?

Concerning pre darwin12, there very little thing the user can do about which
instructions as support.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-08-31 12:55:40 UTC ---
Deleting the #if defined __i386__ || defined __x86_64__ blocks in
libstdc++-v3/src/c++11/random.cc allowed me to bootstrap revision 190830 on
x86_64-apple-darwin10 (regtesting scheduled for tonight).

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot
                   |                            |med.uc.edu

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-08-31 13:59:02 UTC ---
*** Bug 54438 has been marked as a duplicate of this bug. ***

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-08-31 14:48:47 UTC ---
This same issue was discussed in the following thread...

http://thread.gmane.org/gmane.linux.kernel/1145078

specifically....

Comments/Questions:

* Since RDRAND is relatively new, only the most recent version of
binutils supports assembling it.  To avoid breaking builds for people
who use older toolchains but want this feature, I hardcoded the opcodes.
If anyone has a better approach, please let me know.

It looks like that uncommitted patch hasn't been modified to address this issue
either.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-08-31 15:40:25 UTC ---
Would the approach used in the proposed linux kernel patch be feasible?

+    /* RDRAND sets carry bit on success, otherwise we should try
+     * again. */
+    movl    $0x10, %ecx
+2:
+    /* rdrand %eax */
+    .byte    0x0f, 0xc7, 0xf0
+    jc    4f
+    loop    2b
+
+    /* Fall through: if RDRAND is supported but fails, use RDTSC,
+     * which is guaranteed to be supported. */
+3:
+    rdtsc
+    shll    $0xc, %eax
+4:
+    /* Maximum offset at 64mb to be safe */

Since rdrand is only supported on Ivy Bridge processors, shouldn't
src/c++11/random.cc have a fall through using rdtsc in case the processor
doesn't support rdrand?

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-31 17:16:36 UTC ---
Is it clear which are the specific requirements for the various x86* targets?
I'm wondering if after all it's just matter of updating:
http://gcc.gnu.org/install/specific.html

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #9 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-08-31 17:46:41 UTC ---
(In reply to comment #8)
> Is it clear which are the specific requirements for the various x86* targets?
> I'm wondering if after all it's just matter of updating:
> http://gcc.gnu.org/install/specific.html

Indeed.  You cannot use old binutils if any of the code generated by the
compiler requires something newer.  If these dependencies are not wanted then
make the compiler to emit .byte sequences when the new builtins are used.


> Since rdrand is only supported on Ivy Bridge processors, shouldn't
> src/c++11/random.cc have a fall through using rdtsc in case the processor
> doesn't support rdrand?

Read the code.  There is of course a fall-through for older processors.  This
is about the code generated by the compiler, not what is used at runtime.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-09-01 19:20:26 UTC ---
Also fails with x86_64-unknown-linux-gnu, with

tkoenig@gcc14:~/trunk-bin$ as -v
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.18.0.20080103

This is on gcc14.fssfrance.org, so this breaks automated testing for me.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker

--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-09-01 19:30:22 UTC ---
Revision 190769 was fine.

It looks like this is the cause:

Author: drepper
Date: Wed Aug 29 22:05:41 2012
New Revision: 190787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190787
Log:

    * include/bits/random.h (random_device): Move implementation to...
    * src/c++11/random.cc: ...here.  New file.
    * config/abi/pre/gnu.ver: Add new version GLIBCXX_3.4.18.  Export
    std::random_device::* symbols.
    * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Generated.
    * src/c++11/Makefile.am (sources): Add random.cc.
    * src/c++11/Makefile.in: Regenerated.


Added:
    trunk/libstdc++-v3/src/c++11/random.cc
Modified:
    trunk/libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
    trunk/libstdc++-v3/config/abi/pre/gnu.ver
    trunk/libstdc++-v3/include/bits/random.h
    trunk/libstdc++-v3/src/c++11/Makefile.am
    trunk/libstdc++-v3/src/c++11/Makefile.in

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #12 from Paul Thomas <pault at gcc dot gnu.org> 2012-09-02 17:45:06 UTC ---
I can confirm that revision 190787 is the problem, as Dominique originally
reported.

This is on X86_64/FC9.

Please fix it soon, someone!

Paul

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[polacek at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Marek Polacek <polacek at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |polacek at redhat dot com

--- Comment #13 from Marek Polacek <polacek at redhat dot com> 2012-09-02 17:52:48 UTC ---
Fails also on gcc20.fsffrance.org.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> 2012-09-02 18:03:01 UTC ---
libstdc++ should check if rdrand is supported by assembler
before using __builtin_ia32_rdrand32_step.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #15 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-09-02 20:04:57 UTC ---
(In reply to comment #14)
> libstdc++ should check if rdrand is supported by assembler
> before using __builtin_ia32_rdrand32_step.

Every gcc feature should have a test.  When you added the built-in this should
have happened.  The unavailability of a recent-enough compiler should therefore
have been a problem for a long time.  It's just wrong to expect a compiler to
work with binutils versions which cannot handle all the output the compiler
produces.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-03 08:30:18 UTC ---
The usual way in GCC is that gcc/configure* checks are added for assembler
features that affects preexisting ISAs, when adding new ISA extensions that
aren't enabled by default or that would be enabled by default only by the user
forcing it on by default in configure options, assembly feature tests aren't
added.  The compiler is still usable when not requesting the ISA extensions
when using older assembler.  So say when AVX or some other ISA extension
(RDRAND in this case) is added, -mrdrand will only work if assembler supports
it, and it is up to the users to ensure he has recent enough assembler if they
want to use it.
E.g. gcc/testsuite/ has for that dejagnu checks for tests that enable those
extensions and want to be assembled (or even executed).

So, I think this is something that should be tested for in libstdc++-v3
configure and enabled in the headers only if _GLIBCXX_HAVE_* macro is defined.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #17 from Marc Glisse <glisse at gcc dot gnu.org> 2012-09-03 09:43:13 UTC ---
(In reply to comment #16)
> So, I think this is something that should be tested for in libstdc++-v3
> configure and enabled in the headers only if _GLIBCXX_HAVE_* macro is defined.

One issue here is that this affects the list of symbols exported from the
library. Maybe moving __x86_rdrand back to an inline function in the headers
would make using _GLIBCXX_HAVE_* more acceptable?

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-03 09:48:17 UTC ---
If it is exported from the library, then it surely can't depend on configure
checks and must have a fallback in that case (/dev/random reading?).
Inlines that aren't exported from the library could be configure option
dependent.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> 2012-09-03 10:11:58 UTC ---
Actually I misremembered, that function is not exported. And all the affected
functions are in the library, so it shouldn't be possible to get inconsistent
mixes. Sorry, forget my previous comment, *_HAVE_* seems fine.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #20 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-09-04 01:06:33 UTC ---
Created attachment 28127
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28127
Check for rdrand availability

How about this patch?  Not sure whether this handles cross-compiling.  It seems
to work for me.

I still think it's wrong to bother with obsolete assemblers...

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #21 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-04 10:27:58 UTC ---
> How about this patch?  Not sure whether this handles cross-compiling.  It seems
> to work for me.

Before I test the patch, I am surprised to see that only two out of three
blocks

#if defined __i386__ || defined __x86_64__

are "protected" by  && defined _GLIBCXX_X86_RDRAND. Is it normal?

> I still think it's wrong to bother with obsolete assemblers...

Well, users have to deal with the tool chain they can get (I'ld be delighted to
have a working modern gas on darwin, but so far no one is providing it).

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #22 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-04 14:17:52 UTC ---
It seems that when clang is used as the system compiler we will have to use a
run-time test as well to determine drand support. On a 2009 Mac Pro, using...

int
main ()
{
  asm("rdrand %eax");
  return 0;
}

with Xcode 4.4.1's clang I get...

# clang test.c
#
# ./a.out
Illegal instruction

only by disabling clang's built-in assembler does the test fail at compile
time...

# clang -no-integrated-as test.c
/tmp/test-s3jHNR.s:15:no such instruction: `rdrand %eax'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-04 15:53:20 UTC ---
Why do you talk about clang?  This has nothing to do with it.  And, there is
already runtime check for whether RDRAND can be used in random.cc (though,
apparently insufficient for i?86 - it should use either __get_cpuid, or
__get_cpuid_max before __cpuid).  Not sure if on x86_64 it is guaranteed that
max basic level is always >= 1, if not, it also needs to test __get_cpuid_max.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #24 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-04 15:56:17 UTC ---
As such, the patch in commen #20 does not work:

(1) on x86_64-apple-darwin10 it gives

[macbook] gcc/p_build% grep -r rdr x86_64-apple-darwin10.8.0/*/config.log
x86_64-apple-darwin10.8.0/libstdc++-v3/config.log:ac_cv_x86_rdrand=yes

AFAICT this is due to the fact that "void f(void){asm("rdrand %eax");}" is
optimized out, thus the test passes.

Before reading comment #22, I have tested

  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
void f(void){asm("rdrand %eax");}
_ACEOF

which gives

x86_64-apple-darwin10.8.0/libstdc++-v3/config.log:conftest.c:167:no such
instruction: `rdrand %eax'
x86_64-apple-darwin10.8.0/libstdc++-v3/config.log:| void f(void){asm("rdrand
%eax");}
x86_64-apple-darwin10.8.0/libstdc++-v3/config.log:ac_cv_x86_rdrand=no

(2) I have asked in comment #21

> Before I test the patch, I am surprised to see that only two out of three
> blocks
>
> #if defined __i386__ || defined __x86_64__
> 
> are "protected" by  && defined _GLIBCXX_X86_RDRAND. Is it normal?

Thanks to the quick answer, without 

-#if (defined __i386__ || defined __x86_64__)
+#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND

bootstrap fails with

../../../../../p_work/libstdc++-v3/src/c++11/random.cc: In member function
'std::random_device::result_type std::random_device::_M_getval()':
../../../../../p_work/libstdc++-v3/src/c++11/random.cc:124:27: error:
'__x86_rdrand' was not declared in this scope
       return __x86_rdrand();

With the two changes I have been able to bootstrap revision 190924 configured
with

../p_work/configure --prefix=/opt/gcc/gcc4.8p-190924p2
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
--with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
--enable-plugin --enable-build-with-cxx

I will now try to bootstrap with the following change in libstdc++-v3/configure

ac_cv_x86_rdrand=no
case "$target" in
  i?86-*-* | \
  x86_64-*-*)
  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
int
main ()
{
  asm("rdrand %eax");
  return 0;
}
_ACEOF
if ac_fn_c_try_run "$LINENO"; then :
  ac_cv_x86_rdrand=yes
else
  ac_cv_x86_rdrand=no
fi
rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
esac
if test $ac_cv_x86_rdrand = yes; then

$as_echo "#define _GLIBCXX_X86_RDRAND 1" >>confdefs.h

fi

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #25 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-04 16:14:01 UTC ---
I am now at stage 2 with

--- ../_clean/libstdc++-v3/configure    2012-08-29 10:19:44.000000000 +0200
+++ ../p_work/libstdc++-v3/configure    2012-09-04 17:51:54.000000000 +0200
@@ -3523,11 +3523,11 @@ MAKEINFO=${MAKEINFO-"${am_missing_run}ma

 # We need awk for the "check" target.  The system "awk" is bad on
 # some platforms.
-# Always define AMTAR for backward compatibility.
+# Always define AMTAR for backward compatibility.  Yes, it's still used
+# in the wild :-(  We should find a proper way to deprecate it ...
+AMTAR='$${TAR-tar}'

-AMTAR=${AMTAR-"${am_missing_run}tar"}
-
-am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'
+am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'



@@ -70621,6 +70621,31 @@ $as_echo "#define _GLIBCXX_LONG_DOUBLE_C
 esac


+ac_cv_x86_rdrand=no
+case "$target" in
+  i?86-*-* | \
+  x86_64-*-*)
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+int
+main ()
+{
+  asm("rdrand %eax");
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_run "$LINENO"; then :
+  ac_cv_x86_rdrand=yes
+else
+  ac_cv_x86_rdrand=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+esac
+if test $ac_cv_x86_rdrand = yes; then
+
+$as_echo "#define _GLIBCXX_X86_RDRAND 1" >>confdefs.h
+
+fi
+
 # This depends on GLIBCXX_ENABLE_SYMVERS and GLIBCXX_IS_NATIVE.

   if $GLIBCXX_IS_NATIVE ; then
--- ../_clean/libstdc++-v3/src/c++11/random.cc    2012-08-30 00:56:27.000000000
+0200
+++ ../p_work/libstdc++-v3/src/c++11/random.cc    2012-09-04 16:25:54.000000000
+0200
@@ -50,7 +50,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
       return __ret;
     }

-#if defined __i386__ || defined __x86_64__
+#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
     unsigned int
     __attribute__ ((target("rdrnd")))
     __x86_rdrand(void)
@@ -75,7 +75,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul

     if (token == "default")
       {
-#if defined __i386__ || defined __x86_64__
+#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
     unsigned int eax, ebx, ecx, edx;
     __cpuid(0, eax, ebx, ecx, edx);
     // Check for "GenuineIntel"
@@ -119,7 +119,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
   random_device::result_type
   random_device::_M_getval()
   {
-#if (defined __i386__ || defined __x86_64__)
+#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
     if (! _M_file)
       return __x86_rdrand();
 #endif

Jack can you try it on you mac(s)?

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #26 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-04 16:37:07 UTC ---
(In reply to comment #23)
> Why do you talk about clang?  This has nothing to do with it.  And, there is
> already runtime check for whether RDRAND can be used in random.cc (though,
> apparently insufficient for i?86 - it should use either __get_cpuid, or
> __get_cpuid_max before __cpuid).  Not sure if on x86_64 it is guaranteed that
> max basic level is always >= 1, if not, it also needs to test __get_cpuid_max.

I mention clang because it is the system compiler on both Lion and Mountain
Lion
as of Xcode 4.4. The Apple clang 4.0 compiler defaults to its integrated
assembler
such that the simple test case...


int
main ()
{
  asm("rdrand %eax");
  return 0;
}

is compiled without errors into the assembly....


        .section        __TEXT,__text,regular,pure_instructions
        .globl  _main
        .align  4, 0x90
_main:                                  ## @main
        .cfi_startproc
## BB#0:
        pushq   %rbp
Ltmp2:
        .cfi_def_cfa_offset 16
Ltmp3:
        .cfi_offset %rbp, -16
        movq    %rsp, %rbp
Ltmp4:
        .cfi_def_cfa_register %rbp
        movl    $0, %eax
        movl    $0, -4(%rbp)
        ## InlineAsm Start
        rdrand %eax
        ## InlineAsm End
        popq    %rbp
        ret
        .cfi_endproc


.subsections_via_symbols

This leaves config.log with ac_cv_x86_rdrand=yes which fails later in the
bootstrap when the newly built FSF gcc compiler is used and the legacy system
assembler is used.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #27 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-04 16:47:47 UTC ---
(In reply to comment #25)
Your proposed patch from comment 25 appears to be working under clang 4.0 of
Xcode 4.4. The configure test is properly run against the newly built compiler
and fails against the system assembler as expected on darwin12. Thanks.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #28 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-04 17:24:37 UTC ---
(In reply to comment #25)
This patch allows gcc trunk to completely bootstrap against clang 4.0 from
Xcode 4.4.1 on x86_64-apple-darwin12 using...

../gcc-4.8-20120904/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #29 from Marc Glisse <glisse at gcc dot gnu.org> 2012-09-04 18:24:05 UTC ---
(In reply to comment #26)

> The Apple clang 4.0 compiler defaults to its integrated
> assembler
> such that the simple test case...
> 
> 
> int
> main ()
> {
>   asm("rdrand %eax");
>   return 0;
> }
> 
> is compiled without errors into the assembly....

[...]

> This leaves config.log with ac_cv_x86_rdrand=yes which fails later in the
> bootstrap when the newly built FSF gcc compiler is used and the legacy system
> assembler is used.

Er, why should this test ever be run with the system compiler? libstdc++ should
only ever be built by a newly built g++.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #30 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-05 09:39:17 UTC ---
> Er, why should this test ever be run with the system compiler? libstdc++ should
> only ever be built by a newly built g++.

The problem is not with the compiler, but with the (target?) assembler and
possibly the target CPU.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #31 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-05 09:45:08 UTC ---
http://gcc.gnu.org/ml/gcc/2012-09/msg00025.html

clock ticking;-(

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #32 from Marc Glisse <glisse at gcc dot gnu.org> 2012-09-05 10:46:35 UTC ---
(In reply to comment #30)
> > Er, why should this test ever be run with the system compiler? libstdc++ should
> > only ever be built by a newly built g++.
> 
> The problem is not with the compiler, but with the (target?) assembler and
> possibly the target CPU.

Er, did you read comment #26? Jack says the configure test is being run with
clang, which if true looks like a bug.

(doesn't change the fact that this PR is about assembler support, but sometimes
studying one bug unearths other bugs)

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #33 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-05 12:31:06 UTC ---
> Er, did you read comment #26? 

Do comments #24 and #25 answer this question?

> Jack says the configure test is being run with
> clang, which if true looks like a bug.

It is not the way I read Jack's comments. Due to my own bias, I read it as "the
as provided by Xcode 4.4 support `rdrand %eax' even if it is not supported by
the CPU which will run the code", hence my second patch in comment #25 which
uses ac_fn_c_try_run. Indeed I am assuming that everything occurs for the
target when doing a cross compilation.

> (doesn't change the fact that this PR is about assembler support, but sometimes
> studying one bug unearths other bugs)

If you can show that the compiler used for the tests in libstdc++-v3/configure
is not the right one, please open a new PR.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-05 12:40:49 UTC ---
No, the #c24 and #c25 comments make no sense at all.
In void f(void) { asm ("rdrand %eax"); } rdrand shouldn't be optimized out, at
least not by gcc, asm in this case is implicitly volatile.  AC_TRY_RUN is not
desirable for many reasons, as has been said and you can read in the code, the
runtime detection is done in libstdc++ code (ctor which uses cpuid), all
configury should test is whether assembler is able to assemble rdrand.
Furthermore, never patch configure, you need to patch configure.ac resp.
configure.in instead.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #35 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-05 12:59:09 UTC ---
> No, the #c24 and #c25 comments make no sense at all.

My only claim is that they allow to bootstrap again my platform of choice.

> In void f(void) { asm ("rdrand %eax"); } rdrand shouldn't be optimized out, at
> least not by gcc, asm in this case is implicitly volatile.  

As said in comment #24, the configure test yields ac_cv_x86_rdrand=yes. When
run manually, the test compiles without assembler error and looking at the
assembly, there is no rdrand in it. My naive explanation was that foo was never
generated, but if you have a better one, be my guest!-)

> AC_TRY_RUN is not
> desirable for many reasons, as has been said and you can read in the code, the
> runtime detection is done in libstdc++ code (ctor which uses cpuid), all
> configury should test is whether assembler is able to assemble rdrand.

What will happen if the assembly accept rdrand, but not the CPU?

> Furthermore, never patch configure, you need to patch configure.ac resp.
> configure.in instead.

I know that, but I don't know how to write *.ac or *.in stuff. Also my previous
attempts to use the auto* tools have left my tree in a total mess.

Now, I did not commit the patch responsible for this PR and I am quite upset
(to say the least) that the one who did it is doing very little to fix it
(remember that the problem occurs also on some machines in the gcc farm, so any
maintainer should be able to test a patch on a failing machine).

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #36 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-09-05 13:25:21 UTC ---
(In reply to comment #35)
> What will happen if the assembly accept rdrand, but not the CPU?

The code at runtime checks for the feature bit.  There will be no problem. 
This is *exclusively* a problem with obsolete assemblers.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #37 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-09-05 13:57:27 UTC ---
(In reply to comment #23)
> (though,
> apparently insufficient for i?86 - it should use either __get_cpuid, or
> __get_cpuid_max before __cpuid).

I fixed that.  The code now should work in theory also on those systems. 
Although the sheer size of all the code together will prevent these systems
from being used...

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #38 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-06 14:04:11 UTC ---
Created attachment 28140
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28140
revised patch tested against clang on darwin12

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #39 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-06 14:11:49 UTC ---
The attached revised patch is Ulrich's original with the change of the test in
configure.ac from...

  AC_TRY_COMPILE(, [void f(void){asm("rdrand %eax");}],
         [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])

to

  AC_TRY_COMPILE(,[asm("rdrand %eax");],
         [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])

and the additional missing conditional on the definition of _GLIBCXX_X86_RDRAND
...

@@ -118,7 +118,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
   random_device::result_type
   random_device::_M_getval()
   {
-#if (defined __i386__ || defined __x86_64__)
+#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
     if (! _M_file)
       return __x86_rdrand();
 #endif

in libstdc++-v3/src/c++11/random.cc.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #40 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-06 14:15:29 UTC ---
(In reply to comment #39)
> The attached revised patch is Ulrich's original with the change of the test in
> configure.ac from...
> 
>   AC_TRY_COMPILE(, [void f(void){asm("rdrand %eax");}],
>          [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
> 
> to
> 
>   AC_TRY_COMPILE(,[asm("rdrand %eax");],
>          [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
> 
> and the additional missing conditional on the definition of _GLIBCXX_X86_RDRAND
> ...
> 
> @@ -118,7 +118,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
>    random_device::result_type
>    random_device::_M_getval()
>    {
> -#if (defined __i386__ || defined __x86_64__)
> +#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
>      if (! _M_file)
>        return __x86_rdrand();
>  #endif
> 
> in libstdc++-v3/src/c++11/random.cc.

Looks ok to me, but patches should be mailed with ChangeLog entry to
gcc-patches and libstdc++ mailing lists.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #40 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-06 14:15:29 UTC ---
(In reply to comment #39)
> The attached revised patch is Ulrich's original with the change of the test in
> configure.ac from...
> 
>   AC_TRY_COMPILE(, [void f(void){asm("rdrand %eax");}],
>          [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
> 
> to
> 
>   AC_TRY_COMPILE(,[asm("rdrand %eax");],
>          [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
> 
> and the additional missing conditional on the definition of _GLIBCXX_X86_RDRAND
> ...
> 
> @@ -118,7 +118,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
>    random_device::result_type
>    random_device::_M_getval()
>    {
> -#if (defined __i386__ || defined __x86_64__)
> +#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
>      if (! _M_file)
>        return __x86_rdrand();
>  #endif
> 
> in libstdc++-v3/src/c++11/random.cc.

Looks ok to me, but patches should be mailed with ChangeLog entry to
gcc-patches and libstdc++ mailing lists.

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-06 14:17:18 UTC ---
Ah, actually not completely, the
#if defined __i386__ || defined __x86_64__ && defined _GLIBCXX_X86_RDRAND
line in your patch is wrong, there should be () like in the other two
preprocessor conditionals.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-06 14:17:18 UTC ---
Ah, actually not completely, the
#if defined __i386__ || defined __x86_64__ && defined _GLIBCXX_X86_RDRAND
line in your patch is wrong, there should be () like in the other two
preprocessor conditionals.

--- Comment #42 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-09-06 14:20:15 UTC ---
Sorry if I'm saying something naive - I didn't follow the whole discussion -
but I don't understand why - assuming indeed we want to do something at
configure time - are being attached patches directly touching
libstdc++-v3/configure* files, instead of acinclude.m4 (to be processed by
autoreconf), which is the normal way we write this kind of code in the
libraries.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #43 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-06 14:31:53 UTC ---
(In reply to comment #42)
> Sorry if I'm saying something naive - I didn't follow the whole discussion -
> but I don't understand why - assuming indeed we want to do something at
> configure time - are being attached patches directly touching
> libstdc++-v3/configure* files, instead of acinclude.m4 (to be processed by
> autoreconf), which is the normal way we write this kind of code in the
> libraries.

Probably because...

  AC_TRY_COMPILE(, [
#if !defined __LONG_DOUBLE_128__ || (defined(__sparc__) && defined(__arch64__))
#error no need for long double compatibility
#endif
  ], [ac_ldbl_compat=yes], [ac_ldbl_compat=no])
  if test "$ac_ldbl_compat" = yes; then
    AC_DEFINE([_GLIBCXX_LONG_DOUBLE_COMPAT],1,
              [Define if compatibility should be provided for
-mlong-double-64.])
   
port_specific_symbol_files="\$(top_srcdir)/config/os/gnu-linux/ldbl-extra.ver"
  fi

already existed immediately above the new test in configure.ac.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #44 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-09-06 14:47:57 UTC ---
Unless there are very special and compelling technical reasons, please use the
autotools.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-06 14:58:25 UTC ---
Well, it is using autotools, the decision whether to put the stuff into
autoinclude.m4 and reference in configure.ac, or put in full just into
configure.ac is pure esthetical thing.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #46 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-09-06 15:31:52 UTC ---
I would say not just esthetical, because normally the maintainers know that the
configury code is in acinclude.m4 and in case of issues look into it. If we
start randomly adding non-trivial code "by hand" to confifure.ac, then each
time there are two different places to check.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #47 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-06 16:01:09 UTC ---
The test in comment #20 is

/* end confdefs.h.  */

int
main ()
{
void f(void){asm("rdrand %eax");}
  ;
  return 0;
}

I have compiled it with clang 1.7 and gcc 4.4.6, 4.5.3, 4.6.3, 4.7.1, and 4.8.0
r191013 with
'-O0 -fdump-tree-all rdrand.c -save-temps'.

clang gives

In file included from rdrand.c:1:
rdrand.c:6:13: error: expected ';' at end of declaration
void f(void){asm("rdrand %eax");}
            ^
            ;
1 error generated.

gcc 4.4 and 4.5 gives

rdrand.c:6:no such instruction: `rdrand %eax'

and "grep rdrand rdrand.c.*"

rdrand.c.001t.tu:@2761   function_decl    name: @2768    type: @2769    srcp:
rdrand.c:4      
rdrand.c.001t.tu:                         srcp: rdrand.c:6              link:
static  
rdrand.c.001t.tu:@2800   result_decl      type: @3       scpe: @2761    srcp:
rdrand.c:4      
rdrand.c.003t.original:  __asm__ __volatile__("rdrand %eax"::);
rdrand.c.004t.gimple:  __asm__ __volatile__("rdrand %eax");
rdrand.c.005t.nested:  __asm__ __volatile__("rdrand %eax");
rdrand.c.008t.omplower:  __asm__ __volatile__("rdrand %eax");
rdrand.c.009t.lower:  __asm__ __volatile__("rdrand %eax");
rdrand.c.011t.eh:  __asm__ __volatile__("rdrand %eax");
rdrand.c.012t.cfg:  __asm__ __volatile__("rdrand %eax");
rdrand.c.013t.veclower:  __asm__ __volatile__("rdrand %eax");
rdrand.c.021t.cleanup_cfg:  __asm__ __volatile__("rdrand %eax");
rdrand.c.023t.ssa:  __asm__ __volatile__("rdrand %eax");
rdrand.c.024t.einline2:  __asm__ __volatile__("rdrand %eax");
rdrand.c.040t.release_ssa:  __asm__ __volatile__("rdrand %eax");
rdrand.c.135t.cplxlower0:  __asm__ __volatile__("rdrand %eax");
rdrand.c.140t.optimized:  __asm__ __volatile__("rdrand %eax");

(with a bunch of additional hit in rdrand.c.001t.tu for 4.4).

For gcc 4.6 and above the test compiles without error and "grep rdrand
rdrand.c.*" gives

rdrand.c.001t.tu:                         srcp: rdrand.c:4              link:
extern  
rdrand.c.001t.tu:                         srcp: rdrand.c:6              link:
static  
rdrand.c.001t.tu:@2807   result_decl      type: @3       scpe: @2768    srcp:
rdrand.c:4      
rdrand.c.003t.original:  __asm__ __volatile__("rdrand %eax"::);
rdrand.c.005t.nested:  __asm__ __volatile__("rdrand %eax");

i.e., "f(void){asm("rdrand %eax");}" is discarded after rdrand.c.005t.nested.
If someone thinks it is a [4.6/4.7/4.8 Regression] or a new undocumented
feature, please read the end of comment #33!

I have tried to bootstrap 191018 with the patch in comment #20 and gcc 4.4
(which fails the test for rdrand) and it failed with "no such instruction:
`rdrand %eax'". I think this answer the concern expressed by Marc in comment
#29: the bootstrapping compiler is not used for the tests in
libstdc++-v3/configure (am I wrong to assume that they use the new built one?).

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #28140|0                           |1
        is obsolete|                            |

--- Comment #48 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-06 16:14:37 UTC ---
Created attachment 28141
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28141
revised patch tested against clang on darwin12 with ChangeLog

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #49 from Marc Glisse <glisse at gcc dot gnu.org> 2012-09-06 16:24:19 UTC ---
(In reply to comment #47)
> I think this answer the concern expressed by Marc in comment
> #29: the bootstrapping compiler is not used for the tests in
> libstdc++-v3/configure

Thank you for this investigation :-)

--- Comment #50 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-06 16:46:56 UTC ---
> Created attachment 28140 [details]
> revised patch tested against clang on darwin12

I just finished a clean bootstrap with the patch in comment #38 on
x86_64-apple-darwin10 (it works with the missing parentheses;-) with gcc 4.8
r190619.

Thanks Jack!

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #51 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-07 13:50:08 UTC ---
Final patch, hopefully, posted at
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00465.html.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #52 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-09-08 00:25:38 UTC ---
Regression test results as
http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg00623.html.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #53 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-08 10:40:31 UTC ---
Please post the patch to the right list and I'll approve it, all libstdc++
patches need to go to the libstdc++ list.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #54 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-08 11:00:36 UTC ---
I've tested the patch myself now, it's ok, please commit it asap (but in future
remember to send patches to the libstdc++ list as well as gcc-patches, I could
have approved it sooner had I seen it)

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #55 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-09 15:21:45 UTC ---
(In reply to comments #53 and #54)
> Please post the patch to the right list and I'll approve it, all libstdc++
> patches need to go to the libstdc++ list.
>
> I've tested the patch myself now, it's ok, please commit it asap (but in future
> remember to send patches to the libstdc++ list as well as gcc-patches, I could
> have approved it sooner had I seen it)

I'ld to make a few comments:

(1) A new patch has been posted at
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html to fix a typo in my
email address.

(2) Jack Howarth does not seem to be around. So if someone with write access
care about ASAP, he(r)? may commit the last version.

(3) Jack has posted five revisions of the patch:

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00409.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00416.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00421.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00465.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html

following the request made at

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00411.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00417.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00418.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00432.html

followed by a last post

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00499.html

AFAICT nobody has been asking to cross post to libstdc++.

(4) Managing libstdc++ on a specific mailing list made sense when G++ was an
optional component of GCC. Now that C++, hence libstdc++, is mandatory, I think
this policy should be revised:
- the final patch should be posted and approved on gcc-patches@gcc.gnu.org;
- the libstdc++ maintainers should be more careful: four bootstrap failures
caused by a single commit is way to much;
- the libstdc++ maintainers should be more responsive: more than ten days to
fix a bootstrap failure on primary platforms is way too long.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #56 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-09-09 16:14:41 UTC ---
I suppose that the lack of responsiveness may be ultimately due to the fact
that the issue only shows up on some specific systems (that is, those using old
assemblers) which normally the maintainers (in general, not just the library
ones) working on mainline GCC don't develop on and don't assume are the
reference systems on which the next release series will be eventually primarily
installed. Indeed, if you look at gcc-patches it's pretty obvious that the
development of GCC mainline proceeded quite normally, and, at this stage at
least, this is what *really* counts.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #57 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-09 16:18:12 UTC ---
(In reply to comment #55)
> (1) A new patch has been posted at
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html to fix a typo in my
> email address.

But not to a list I actually read.

> (2) Jack Howarth does not seem to be around. So if someone with write access
> care about ASAP, he(r)? may commit the last version.

I'll do it today.

> AFAICT nobody has been asking to cross post to libstdc++.

See http://gcc.gnu.org/contribute.html#patches and
http://gcc.gnu.org/lists.html "Patches to libstdc++-v3 should be sent to both
this list and gcc-patches."

That is the standard policy, that's true whether or not anyone noticed the
policy wasn't followed or pointed it out. Anyway, I'm asking now. Please follow
the policy in future if you want me to review libstdc++ patches.

> (4) Managing libstdc++ on a specific mailing list made sense when G++ was an
> optional component of GCC. Now that C++, hence libstdc++, is mandatory, I think
> this policy should be revised:
> - the final patch should be posted and approved on gcc-patches@gcc.gnu.org;

No, it should go to both.  I don't want to subscribe to gcc-patches to review
just the libstdc++ patches, and I doubt everyone subscribed to gcc@gcc.gnu.org
wants to read discussion of e.g. the C++11 standard library components (which
aren't used by the rest of GCC.)

If patches are sent to both lists I can reply-to-all and the approval and
review will be sent to both lists. I see no reason to change that policy.  In
any case, changing policies should be discussed on the gcc list, not in
bugzilla.

> - the libstdc++ maintainers should be more careful: four bootstrap failures
> caused by a single commit is way to much;
> - the libstdc++ maintainers should be more responsive: more than ten days to
> fix a bootstrap failure on primary platforms is way too long.

Myself and Paolo were both travelling for the past week, so we were less
responsive than normal. If the patch had been posted to the right list I would
have reviewed the patch while on holiday, but I didn't even realise there was a
patch to fix it because it wasn't sent to the list I read (I was surprised when
I got back from holiday to find the change hadn't been reverted after the 48
hour countdown was started.)

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #58 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-09 16:21:25 UTC ---
(In reply to comment #56)
> I suppose that the lack of responsiveness may be ultimately due to the fact
> that the issue only shows up on some specific systems (that is, those using old
> assemblers) which normally the maintainers (in general, not just the library
> ones) working on mainline GCC don't develop on

The fact the build was broken on the compile farm machines would normally be an
issue for me, but as I was on holiday I wasn't building gcc.

As soon as I tried to build on the compile farm I found the PR and reviewed the
patch. Again, if it had been sent to the right list I could have done that
sooner, instead of waiting until the bug affected me directly.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #59 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-09 17:20:47 UTC ---
Author: redi
Date: Sun Sep  9 17:20:42 2012
New Revision: 191111

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191111
Log:
2012-09-09  Ulrich Drepper  <drepper@gmail.com>
        Dominique d'Humieres  <dominiq@lps.ens.fr>
        Jack Howarth  <howarth@bromo.med.uc.edu>

    PR bootstrap/54419
    * acinclude.m4: Define GLIBCXX_CHECK_X86_RDRAND.
    * configure.ac: Use GLIBCXX_CHECK_X86_RDRAND to test for rdrand
    support in assembler.
    * src/c++11/random.cc (__x86_rdrand): Depend on _GLIBCXX_X86_RDRAND.
    (random_device::_M_init): Likewise.
    (random_device::_M_getval): Likewise.
    * configure: Regenerated.
    * config.h.in: Regenerated.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/config.h.in
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/configure.ac
    trunk/libstdc++-v3/src/c++11/random.cc

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #60 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-09 17:30:30 UTC ---
patch committed

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #61 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-09 18:17:09 UTC ---
> patch committed

Thanks.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #62 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-09 19:46:45 UTC ---
Author: redi
Date: Sun Sep  9 19:46:41 2012
New Revision: 191119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191119
Log:
    PR bootstrap/54419
    * acinclude.m4 (GLIBCXX_CHECK_X86_RDRAND): Remove stray character.
    * configure: Regenerated.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #63 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-09-09 20:45:11 UTC ---
(In reply to comment #55)
> AFAICT nobody has been asking to cross post to libstdc++.

Also see comment 40, before the first patch.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paul.richard.thomas at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419

--- Comment #64 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> 2012-09-10 10:00:09 UTC ---
Seconded!  In return, I promise that, as soon as I have time, I'll
update to 21st century tools :-)

Thanks

Paul

On 9 September 2012 20:17, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
>
> --- Comment #61 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-09 18:17:09 UTC ---
>> patch committed
>
> Thanks.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.