AssignedTo: unassigned at gcc dot 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 #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 d
--- 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:
...
p
--- 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
--- 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=20523&action=view)
Define _MACHINE_ANSI_H if target defines _I386_ANSI_H_ ||
defined(_X86_64_ANSI_H_
This patch trie
mal
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 #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
--- 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-g
--- 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=20363&action=view)
*.i of the source file triggering the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
onent: target
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 #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
--- 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:
--- 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 \
--- 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
--- 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-
--- 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
--- 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
--- 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 breakdow
atus: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo: unassigned 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 #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 #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=15150&action=view)
patch implementing drow's proposal
I have no idea what this patch actually does, but it at le
--- 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 breakd
--- 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
--- 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=15105&action=view)
preprocessed source of file producing breakdown
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
dot gnu dot org
ReportedBy: 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 04:15
---
Created an attachment (id=15102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15102&action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35072
--- 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=15100&action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
a_1, at dwarf2out.c:804
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: 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 05:11
---
Created an attachment (id=15097)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15097&action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
See <http://gcc.gnu.org/bugs.html> for instructions.
make[8]: *** [lib_a-sf_erf.o] Error 1
--
Summary: ICE: in extract_insn, at recog.c:1990
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
pcode movw 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 tr
Component: target
AssignedTo: 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
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: arm-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
--- 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 #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://
--- 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 #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 http://gcc.gnu.org
--- 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=10636&action=view)
--save-temps generated file from the ICE
GCC ices on this code with -O2, but doesn't ice wit
erity: normal
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 #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 comp
--- 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
--
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 t
--- 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-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-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:
--- 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:
--- 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
--- 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:
...
che
--- 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=8885&action=view)
selected_int_kind.inc
Sorry, wrong file. This is the *.inc, Tobi requested.
--
http://gcc.
--- 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=8884&action=view)
selected_int_kind.f90
As requested by Tobi, the selected_int_kind.f90 building h8300-rtems
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
cted at a-stmaco.ads:65:4
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
Version: 4.0.0
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.g
ssigned 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
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 at gcc dot g
n: 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 at gcc dot gnu dot org,joel at oar
--- 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 s
--- 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 b
ssignedTo: 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
04:18 ---
Fix applied 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
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-21
16:20 ---
Created an attachment (id=8704)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8704&action=view)
Patch against 4.0.0 to fix this PR
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
t 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 g
--- 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
--- 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
Summary: error: too 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
--- 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*
--- 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).
--
W
dTo: 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: 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
11:12 ---
Regression confirmed for avr-*-rtems* (20050214).
--
What|Removed |Added
--
What|Removed |Added
CC||cjohns at cybertec dot com
||dot au
http://gcc.gnu.org/bugzilla
--
What|Removed |Added
CC||ralf dot corsepius at rtems
||dot org
GCC target triplet|m86k-rt
rality
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 gnu dot org
CC: gcc-bu
--
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-23
12:26 ---
Created an attachment (id=8044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8044&action=view)
Example 2 to reproduce the ICE
There seems to be some improvement on this PR. pr19421.c
--- 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-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
--- 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
--- 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
--- 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_SEQUENC
--- 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-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
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
ion] missing ra.h
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 gnu dot org
CC: gcc-bu
--- 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
--- 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
--- 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
omponent: c++
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 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-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
--
What|Removed |Added
Summary|[4.0 regression] ICE with |[4.0 regression] ICE with
|solf-float on m68k |soft-float on m68k
http://gcc.gnu.o
--- 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-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 alterna
--
What|Removed |Added
Known to fail||4.0.0
Known to work||3.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
--- 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=7948&action=view)
Code to reproduce the ICE
Sorry for the size of the example (stripped down from RTEMS paranoia.
Product: gcc
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
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12
23:57 ---
(In reply to comment #6)
> (In reply to comment #3)
> What do you think of them?
pr19399-try2.diff looks good to me. I've just launched local test-builds,
nevertheless, OK to commit, IMO.
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12
15:02 ---
(In reply to comment #7)
> (In reply to comment #6)
> > > If you are tuly using soft-float, then the results can't be returned in
> > > the
> > > non-existent FPU r
1 - 100 of 134 matches
Mail list logo
