gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: powerpc-rtems*, powerpc-elf*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208
--- Comment #6 from corsepiu at gcc dot gnu dot org 2010-07-05 03:30
---
(In reply to comment #5)
rtems should be moved to the new style libgcc config and include
./config/rs6000/t-ppccomm .
Hmm. Doesn't RTEMS already do so?
From config.gcc:
...
powerpc-*-rtems*)
tm_file
--- Comment #7 from corsepiu at gcc dot gnu dot org 2010-07-05 04:17
---
(In reply to comment #6)
(In reply to comment #5)
rtems should be moved to the new style libgcc config and include
./config/rs6000/t-ppccomm .
Hmm. Doesn't RTEMS already do so?
Did you mean libgcc
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-05-27 15:15
---
FWIW: I added your patch to the RTEMS lm32-gcc-4.5.0 toolchains.
With this patch applied, the ICE during building RTEMS, I had experienced does
not occur anymore. Compiling RTEMS at -O2 also seems to work
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: {i?86,amd64}-*-netbsdelf5*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43952
--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-05-01 01:55
---
Created an attachment (id=20523)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20523action=view)
Define _MACHINE_ANSI_H if target defines _I386_ANSI_H_ ||
defined(_X86_64_ANSI_H_
This patch tries
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-04-15 03:31
---
For the record: Bug is also present in gcc-4.5.0 (final).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: lm32-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-04-12 11:52
---
Created an attachment (id=20363)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20363action=view)
*.i of the source file triggering the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-04-12 12:31
---
(In reply to comment #2)
Did you have patches to get past
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away?
Neither.
This breakdown is with the rtems-4.11-lm32-rtems4.11-gcc rpm,
i.e
--- Comment #27 from corsepiu at gcc dot gnu dot org 2010-04-07 13:38
---
(In reply to comment #26)
Fixed for 4.5.0 AFAICS.
Is the patch you are referring to in 4.5.0-RC-20100406?
IIRC, snapshot 4.5-20100401 has had this issue, but I can't find any it anymore
in my 4.5.0-RC
--- Comment #24 from corsepiu at gcc dot gnu dot org 2010-04-07 05:58
---
(In reply to comment #23)
(In reply to comment #21)
(In reply to comment #20)
Is this fixed now?
The hard-breakdown due is gone, but now I am observing another bug:
[...]
Note the
-I../../gcc
--- Comment #21 from corsepiu at gcc dot gnu dot org 2010-04-02 11:48
---
(In reply to comment #20)
Is this fixed now?
Partially, I'd say.
The hard-breakdown due is gone, but now I am observing another bug:
T=`${PWDCMD-pwd}`/ \
cd ../../.././gcc \
make
--- Comment #6 from corsepiu at gcc dot gnu dot org 2010-03-30 14:11
---
(In reply to comment #5)
Not primary or secondary target.
Well, then redefine your priorities - AFAICT, this bug affects cross building
gcc for all targets - This isn't a regression, this is a show stopper
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-03-30 16:09
---
(In reply to comment #7)
At least please say how you configured gcc.
We build one-tree-style build with newlib symlinked into gcc's sourcetree.
Configuration from a sparc-rtems4.11-gcc:
# /opt/rtems-4.11/bin
--- Comment #11 from corsepiu at gcc dot gnu dot org 2010-03-30 16:50
---
(In reply to comment #9)
Maybe I am misreading the command invoked in Ralf's original report but it is
using xgcc which is the cross gcc:
No, you haven't - It's likely a better analysis of the same issue
I
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-03-30 03:09
---
AFAICT, this bug affects all *-rtems* targets, if not _all_ targets, i.e.
building target files uses host includes during bootstrap.
But for some reasons I don't (yet) know, it only causes a breakdown
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-03-30 03:22
---
... and the m32l-rtems* ...
Typo, this should have been ... m32r-rtems*...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
--- Comment #5 from corsepiu at gcc dot gnu dot org 2008-08-30 05:13
---
With gcc-4.3.2, for me, the j1.c testcase doesn't segfault anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
--- Comment #5 from corsepiu at gcc dot gnu dot org 2008-02-19 06:34
---
(In reply to comment #4)
Can this issue now be closed?
IMO, yes. But I prefer to leave closing this PR to an m68k-specialist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
--- Comment #7 from corsepiu at gcc dot gnu dot org 2008-02-14 17:26
---
Created an attachment (id=15150)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15150action=view)
patch implementing drow's proposal
I have no idea what this patch actually does, but it at least lets
arm
--- Comment #2 from corsepiu at gcc dot gnu dot org 2008-02-15 06:03
---
The patch Joseph Myers proposed in
http://gcc.gnu.org/ml/gcc/2008-02/msg00264.html
seems to solve this issue.
--
corsepiu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from corsepiu at gcc dot gnu dot org 2008-02-11 17:17
---
The binutils patch mentioned in comment#2 seems to fix this issue.
Today's gcc-trunk using binutils-2.18 with the patch applied doesn't expose
this breakdown anymore.
= The cause for this breakdown was using
: corsepiu at gcc dot gnu dot org
GCC target triplet: i386-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-06 12:01
---
Created an attachment (id=15105)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15105action=view)
preprocessed source of file producing breakdown
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
--- Comment #10 from corsepiu at gcc dot gnu dot org 2008-02-06 12:03
---
Thanks Uros, i386-rtems*-gcc now bootstraps again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: m68k-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-05 14:32
---
Created an attachment (id=15100)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15100action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-06 04:15
---
Created an attachment (id=15102)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15102action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35072
for mcu avr3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: avr
: ICE: in extract_insn, at recog.c:1990
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-05 05:11
---
Created an attachment (id=15097)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15097action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: arm-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35072
--- Comment #4 from corsepiu at gcc dot gnu dot org 2007-07-30 08:11
---
Having investigated this breakdown further, I can reproduce it for many
coldfire variants.
Also: FWIW: Adding -fomit-frame-pointer lets the ICE disappear.
--
corsepiu at gcc dot gnu dot org changed
--- Comment #2 from corsepiu at gcc dot gnu dot org 2006-06-26 14:34
---
# m68k-rtems4.7-gcc --target-help
Target specific options:
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org
--- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 16:41
---
Traceback:
Program received signal SIGSEGV, Segmentation fault.
print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc/opts.c:1301
(gdb) where
#0 print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc
--- Comment #6 from corsepiu at gcc dot gnu dot org 2006-06-26 17:01
---
(In reply to comment #5)
PR 25636 was the 4.2.0 bug and the patch there should fix it if someone
backports it.
For the record, the compiler exposing this is FC5's gcc-4.1.1-1.fc5
--
http://gcc.gnu.org
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: sparc-*-elf*/sparc-*-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25780
--- Comment #1 from corsepiu at gcc dot gnu dot org 2006-01-13 03:57
---
Created an attachment (id=10636)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10636action=view)
--save-temps generated file from the ICE
GCC ices on this code with -O2, but doesn't ice with -O1 or -O0
--- Comment #17 from corsepiu at gcc dot gnu dot org 2005-11-23 10:30
---
Vanilla 4.0.2 with no further patches applied still fails for me:
# m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 -msoft-float
pr19421-1.c: In function 'paranoia':
pr19421-1.c:2084: internal compiler error
--- Comment #5 from corsepiu at gcc dot gnu dot org 2005-11-20 05:38
---
(In reply to comment #4)
Is this still reproducible?
A quick check with m68k-none-elf did not reproduce the ICE.
Confirmed, I can't reproduce it with my latest rtems-toolchain:
m68k-rtems4.7-gcc (GCC) 4.0.1
--
What|Removed |Added
Known to fail|4.0.0 |4.0.0 4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-16
14:05 ---
(In reply to comment #24)
Subject: Re: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
corsepiu at gcc dot gnu dot org wrote:
Joel, do you recall the target in RTEMS which
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15
11:06 ---
I can reproduce the bug
--
What|Removed |Added
CC
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14
06:30 ---
(In reply to comment #11)
Ralf, it looks like no working integer type is found when building the
compiler.
The h8300 is special wrt. integer types:
From a test script of mine:
...
checking for char
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14
07:00 ---
(In reply to comment #13)
I'll try again this weekend with the version of GMP on the laptop
and update GMP if it still fails. If you go to the GMP home page
there is a VERY big warning about problems
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14
08:14 ---
(In reply to comment #17)
Subject: Re: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote:
* f95
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14
08:33 ---
(In reply to comment #16)
Subject: Re: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote:
* f95
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15
03:55 ---
(In reply to comment #20)
I think, I have isolated the bug:
BUG #1:
During bootstrap, libgfortran/Makefile tries to generate selected_int_kind.inc:
selected_int_kind.inc: $(srcdir)/mk-sik-inc.sh
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-13
07:56 ---
Created an attachment (id=8884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8884action=view)
selected_int_kind.f90
As requested by Tobi, the selected_int_kind.f90 building h8300-rtems4.7
gcc-4.0.1
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-13
07:59 ---
Created an attachment (id=8885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8885action=view)
selected_int_kind.inc
Sorry, wrong file. This is the *.inc, Tobi requested.
--
http://gcc.gnu.org
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
: build
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
com,laurent
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: h8300-rtems4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25
14:33 ---
(In reply to comment #1)
Hmm.
The origin of this issue seems to be f951's check's for REAL 8 (kind=8).
The h8300 doesn't seem to provide this type and thereby seems to trigger a bug
in f951's error
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25
17:14 ---
(In reply to comment #3)
(In reply to comment #2)
The origin of this issue seems to be f951's check's for REAL 8 (kind=8).
The h8300 doesn't seem to provide this type and thereby seems to trigger
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25
03:18 ---
Fix commited as obvious to mainline, 4.0-branch and 3.4-branch.
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25
04:18 ---
Fix applied as obvious to mainline, 4.0-branch and 3.4-branch.
--
What|Removed |Added
gfortran installed as gfortran
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-21
16:20 ---
Created an attachment (id=8704)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8704action=view)
Patch against 4.0.0 to fix this PR
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-07
08:26 ---
I can reproduce it with gcc-4.0.0 (20050406)
Interestingly, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421#c7
does not ICE with -mO0, -mO2, -mO3!
--
What|Removed
many arguments to function `find_basic_blocks
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-16
15:15 ---
(In reply to comment #15)
From: corsepiu at gcc dot gnu dot org [EMAIL PROTECTED]
While building, I noticed warnings from math code in newlib, I haven't
noticed before. I am not sure whether
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-16
07:35 ---
(In reply to comment #12)
A call for testing patch is here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00858.html.
With this patch applied, GCC-4.0 (20050216) builds again for
avr-rtems* and h8300
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-14
11:12 ---
Regression confirmed for avr-*-rtems* (20050214).
--
What|Removed |Added
dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19949
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-14
12:01 ---
(In reply to comment #7)
*** Bug 19949 has been marked as a duplicate of this bug. ***
OK, then for completeness:
Regression confirmed for h8300-*-rtems* (GCC-4.0 20050214).
--
What
--
What|Removed |Added
CC||cjohns at cybertec dot com
||dot au
--
What|Removed |Added
CC||ralf dot corsepius at rtems
||dot org
GCC target
: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-23
12:26 ---
Created an attachment (id=8044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8044action=view)
Example 2 to reproduce the ICE
There seems to be some improvement on this PR. pr19421.c doesn't trigger
--
What|Removed |Added
Attachment #7948 is|0 |1
obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-21
10:04 ---
(In reply to comment #2)
commit was not there so I would assume this could clarify as obvious.
OK, thanks.
However, one thought:
In gcc 3.4 CPP_OS_RTEMS_SPEC had been part of svr4.h.
What do you think
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-22
03:13 ---
Patch shown in comment #3 commited to gcc-trunk and gcc-3_4-branch.
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-20
13:33 ---
(In reply to comment #12)
FYI Ralf tracked down one warning we got linking sparc apps to this:
I think the cause is sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC:
#define LINK_GCC_C_SEQUENCE_SPEC %G %L
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-20
16:11 ---
(In reply to comment #16)
FWIW: IMO, all targets implicitly relying on the sparc/sparc.h's
LINK_GCC_C_SEQUENCE_SPEC are broken.
I don't think so. I can tell you for sure that Solaris is not broken
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-21
01:08 ---
The required bits are on gcc-3_2-branch and gcc-3_3-branch, but are missing from
gcc-3_4-branch and gcc-CVS-trunk.
--
What|Removed |Added
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: sh-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-19
16:35 ---
(In reply to comment #5)
Steven, building cc1 to sh-unknown-elf with your patch succeeded.
Building sh-rtems4.7 with Steven's patch also succeeds.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-19
21:31 ---
Patch commited.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-17
16:09 ---
(In reply to comment #13)
As for (4), what do you think the problem *is* anyway?
To me the problem is:
i386-rtems-gcc-4.0 ices when building the '-msoft-float -mtune=i386' multilib
variant.
Now
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-18
03:02 ---
(In reply to comment #4)
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00834.html.
This patch lets building succeed for avr-rtems*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
--
What|Removed |Added
Summary|[4.0 regression] ICE with |[4.0 regression] ICE with
|solf-float on m68k |soft-float on m68k
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-14
15:15 ---
(In reply to comment #6)
I on Fedora Core 3 and am using FC3's toolchain.
What options are used to configure gcc, maybe it has something to do
with that (what I mean a different default CPU is done).
I
gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 386-redhat-linux-gnu
GCC host triplet: i386-redhat-linux-gnu
GCC target triplet: *-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19447
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-15
04:32 ---
(In reply to comment #1)
Invalid, the warnings were correct for compiling 3.4.x but are not correct
when compiling 4.0.0 but you
have to compile with 4.0.0 to get correct warnings for this case
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13
10:18 ---
Created an attachment (id=7948)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7948action=view)
Code to reproduce the ICE
Sorry for the size of the example (stripped down from RTEMS paranoia.c), but I
--
What|Removed |Added
Known to fail||4.0.0
Known to work||3.2.3
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13
13:31 ---
(In reply to comment #11)
(In reply to comment #10)
One thing that I notice about this is that -msoft-float and -mhard-float are
no longer inverses.
Good point. How about these alternatives:
1
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13
17:04 ---
Patches applied to trunk.
--
What|Removed |Added
Status|NEW
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12
10:30 ---
(In reply to comment #3)
What do you want the ABI for soft-float to be?
As RTEMS is probably the only user of -msoft-float, you get to choose.
-msoft-float basically is just a synomym for -no-80387
: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: arm-rtems4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19393
1 - 100 of 134 matches
Mail list logo
