https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
Jackie Rosen jackie.rosen at hushmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #32 from Daniel Drake dsd at laptop dot org 2012-09-19 21:02:55
UTC ---
Using the preprocessed source that I attached, I can't reproduce this with
gcc-4.8 head (my previous test was with 4.7.x). Also, I have completed a glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #31 from Daniel Drake dsd at laptop dot org 2012-09-11 19:11:27
UTC ---
Created attachment 28173
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28173
preprocessed source that crashes
Another preprocessed source example that shows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
Daniel Drake dsd at laptop dot org changed:
What|Removed |Added
CC||dsd at laptop dot org
--- Comment #29 from ian dot bolton at arm dot com 2010-07-09 17:02 ---
(In reply to comment #7)
When I read the RTL dumps correctly, gcc tries to assign SP to wCGR0.
SP is actually the destination here, not the source.
This can be done by the
tmrc sp, wCGR0
assembly
--- Comment #26 from rearnsha at gcc dot gnu dot org 2009-11-28 14:38
---
(In reply to comment #25)
Further tests show that you're right about the non working kernel.
You should not use -march=iwmmxt (or -mcpu=something equivalent) when
building the linux kernel. The kernel does not
--- Comment #27 from rearnsha at gcc dot gnu dot org 2009-11-28 15:56
---
Created an attachment (id=19171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19171action=view)
Proposed patch
I think the attached should be a better patch than the one previously proposed.
I don't have
--- Comment #28 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-28 23:08 ---
Created an attachment (id=19173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19173action=view)
arm-linux-gnueabi-gcc -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt -std=gnu99 -c
-O2
--- Comment #23 from yipiha2008 at gmail dot com 2009-11-20 14:16 ---
Forget #22, as expected it does not work (kernel compiled with a patched GCC as
per #22 does not boot)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #24 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-20 15:07 ---
I do not think that the non working kernel is caused by the patch, but that
there are yet more regressions for the iwmmxt arch and that this arch has never
been tested with gcc 4.4.
--
--- Comment #25 from yipiha2008 at gmail dot com 2009-11-20 15:45 ---
Further tests show that you're right about the non working kernel.
Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would
make it clear that this arch is untested/not supported.
--
--- Comment #17 from yipiha2008 at gmail dot com 2009-11-19 13:18 ---
I tried removing the whole movsi section from the machine definition file
(iwmmxt.md) but if I do that GCC refuses to compile. Reading the GCC internals
documentation it appears that the movsi section is mandatory.
--- Comment #18 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 13:47 ---
(define_insn *iwmmxt_movsi_insn
- [(set (match_operand:SI 0 nonimmediate_operand =rk,r,r,rk,
m,z,r,?z,Uy,z)
+ [(set (match_operand:SI 0 nonimmediate_operand =rk,r,r,rk, m,z
,rk,?z,Uy,z)
-
--- Comment #19 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 13:57 ---
Created an attachment (id=19049)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19049action=view)
patch to fix reported ICE
[not official, I really do not know whether this is the
--- Comment #20 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:09 ---
This patch creates now
---
(insn 460 148 153 20 ../sysdeps/unix/sysv/linux/libc_fatal.c:106 (set (reg:SI
43 wcgr0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int
--- Comment #21 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:39 ---
forget comment #20.
WLDRW wcgr0, [fp, #-1324]
would be an invalid instruction. Offset is 10 bit only so that the RTL is
invalid for the iwmmxt processor.
--
--- Comment #22 from yipiha2008 at gmail dot com 2009-11-19 16:47 ---
I tried applying this patch:
(define_insn *iwmmxt_movsi_insn
- [(set (match_operand:SI 0 nonimmediate_operand =rk,r,r,rk,
m,z,r,?z,Uy,z)
+ [(set (match_operand:SI 0 nonimmediate_operand =rk,r,r,rk,
--
enrico dot scholz at informatik dot tu-chemnitz dot de changed:
What|Removed |Added
Severity|normal |blocker
--- Comment #15 from yipiha2008 at gmail dot com 2009-11-17 13:04 ---
Is it feasible to disable the affected instruction in the meantime, so that gcc
stops crashing? Or, if this comes from Thumb-2 support, maybe it's possible to
disable Thumb-2 support?
I'm basically looking for a
--- Comment #12 from yipiha2008 at gmail dot com 2009-11-16 16:17 ---
I would like to confirm that this bug affects gcc 4.4.2.
Compiling ffmpeg 0.5 triggers it in many places.
It may be a good idea to try to fix this in 4.5 if it's not fixed yet, before
Nov 30th which is the end of
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-11-16 17:23
---
CCing one the of ARM maintainers.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rearnsha at gcc dot gnu dot org 2009-11-16 17:35
---
This is probably a consequence of some changes made to support Thumb-2. Only
a very limited number of instructions are permitted to modify SP there, and
co-processor operations are not amongst them.
I think
--- Comment #10 from hjl at gcc dot gnu dot org 2009-10-30 14:32 ---
Subject: Bug 40836
Author: hjl
Date: Fri Oct 30 14:32:26 2009
New Revision: 153750
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153750
Log:
Optimize -mstackrealign.
gcc/
2009-10-30 H.J. Lu
--- Comment #11 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-30 17:49 ---
hjl: is the fix really for this PR? Reported errors still persists after
applying it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #5 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 10:19 ---
similar issue seen with gcc 4.4.2 (this time in glibc; can not check gcc/libobj
because glibc is required by gcc):
(insn 202 200 195 12 fxprintf.c:48 (set (reg/f:SI 13 sp)
(reg/f:SI
--- Comment #6 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 10:33 ---
message on file from comment #2 is now
$ ./cross/iwmmxt/bin/arm-linux-gnueabi-gcc -O2 -march=iwmmxt -mcpu=iwmmxt
-mtune=iwmmxt /tmp/foo.i
(insn 83 81 72 2
--- Comment #7 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 13:39 ---
When I read the RTL dumps correctly, gcc tries to assign SP to wCGR0.
This can be done by the
tmrc sp, wCGR0
assembly instruction which will be issued by alternative 6 in
---
--- Comment #8 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 14:31 ---
adding 'k' to the 'r' constraints seems to fix the ICE (although I did not
tested correctness of the generated code).
What is the reason that 'sp' resp. 'r13' is not catched by the 'r' 'l'
--- Comment #9 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 15:13 ---
Core problem seemss to be that 4.4 differs between CORE_REGS and GENERAL_REGS
(CORE_REGS without r13/sp) and the r, l + h constraints in the .md rules
apply to GENERAL_REGS only. This
--- Comment #4 from ramana at gcc dot gnu dot org 2009-09-03 11:03 ---
Confirmed with rev 151319
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
33 matches
Mail list logo
