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).
