http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #18 from H.J. Lu ---
(In reply to David Kredba from comment #17)
>
> I think that reproducing needs machine where CPU does not know what AVX is.
I have non-AVX machines and I have no problems with bootstrapping
GCC 4.9.0 on them. S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #17 from David Kredba ---
I can't bootstrap 4.9.0 snapshots without patch attached. My machine is Core2
Quad where are not any avx instructions available. All is compiled from sources
(Gentoo) but libitm x86_avx.lo crashes bootstrap. -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #16 from H.J. Lu ---
(In reply to David Kredba from comment #15)
> For me it looks like that GCC build process is taking from some internal
> definition that AVX should be present on Core2 and enables it for libitm.
> Patch attached in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #15 from David Kredba ---
For me it looks like that GCC build process is taking from some internal
definition that AVX should be present on Core2 and enables it for libitm. Patch
attached in this bug report works for gcc-4.9-20131222 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #13 from David Kredba ---
Binutils rebuilt with -mno-avx and co. not helps.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #12 from David Kredba ---
(In reply to Jakub Jelinek from comment #8)
> That is a user error, just don't do that. As the user provided
> CFLAGS/CXXFLAGS override the default flags, you really shouldn't be using
> -mno-this and -mno-th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
David Kredba changed:
What|Removed |Added
CC||nheghathivhistha at gmail dot
com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #10 from Martin 2013-02-26 14:18:13 UTC
---
(In reply to comment #8)
In fact I [suppose I] do as you suggest: I use "-march=core2" to prevent it
from using AVX. The problem is that this is inconsistently overruled by the
cap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #9 from Ryan Hill 2013-02-22 02:31:03
UTC ---
Well, the trouble is nowadays that many CPUs are exactly "this, except without
that". But anyways, the test is fragile. There is no reason something like
-march=core2 -mno-sse3 sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
Martin changed:
What|Removed |Added
Version|4.7.0 |4.7.2
--- Comment #7 from Martin 2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
szarpaj at grubelek dot pl changed:
What|Removed |Added
CC||szarpaj at grubelek do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
Ryan Hill changed:
What|Removed |Added
CC||dirtyepic at gentoo dot org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #4 from Martin 2012-06-21 09:25:21 UTC ---
( And the "different story" is bug 53731...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53731 )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #3 from Martin 2012-06-13 14:40:06 UTC ---
I can confirm that the attached patch solves the AVX problem for me as well
(means on Solaris and CentOS), wether it is a "proper" one or not...
Thanks!
(BTW, now the compilation on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
--- Comment #2 from safety0ff.bugz at gmail dot com 2012-06-08 17:20:28 UTC ---
Created attachment 27589
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27589
This patch works for me (I have no clue whether it is the "proper" fix.)
This patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
safety0ff.bugz at gmail dot com changed:
What|Removed |Added
CC||safety0ff.bugz at gmail d
18 matches
Mail list logo
