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
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++
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
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.
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
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: 19
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=19
Log:
2012-09-09 Ulrich Drepper
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
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.
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=gccview=revrev=191119
Log:
PR bootstrap/54419
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.
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.
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
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.
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.
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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;-(
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++.
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
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
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) {
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
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
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
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,
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,
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
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/configure2012-08-29 10:19:44.0 +0200
+++ ../p_work/libstdc++-v3/configure
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
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
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...
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 ()
{
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
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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
Marek Polacek polacek at redhat dot com changed:
What|Removed |Added
CC||polacek at
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
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
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
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
---
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
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
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:
*
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.
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/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
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
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
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
63 matches
Mail list logo
