--- 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 #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://
--- 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
--- 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
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 #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
--- 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
--- 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*
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
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
--- 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
--- 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
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
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
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
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:
--- 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
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 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
--- 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
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 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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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
--
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
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
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 #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
--- 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 #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 #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
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-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
--- 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
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
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
--- 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
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
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
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
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
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
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
--- 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
--- 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-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-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
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
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-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-15
11:06 ---
I can reproduce the bug
--
What|Removed |Added
CC
--- 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 2004-12-16
05:39 ---
The avr and h8300 variants of this PR are tracked as
PR18563 (avr)
PR18564 (h8300)
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16
05:35 ---
I am reopening this PR to allow tracking this problem independent of PR18542.
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16
08:41 ---
> > I am going to reopen them and remove the avr/h8300 from PR18542.
>
> "You can easily check that by testing if reverting the patch from comment #2
> helps. "
Please read wh
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16
08:44 ---
WTH are you permantently closing this PR?
This PR is addressing the h8300 and one of the m68k-maintainers (Bernardo) had
explicitly requested me to split the h8300-case from the m68k.
Upset, Ralf
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-14
13:58 ---
PR18542 and this PR are not identical:
Proof:
* Compiling the example from comment #3
# m68k-rtems4.7-gcc -m68020 -O2 -o tmp.o -c pr18549.c
pr18549.c: In function `foo':
pr18549.c:31: internal com
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16
05:33 ---
(In reply to comment #11)
> Comment #7 in PR18542 said that separate PR's
> were going to be filed for avr and h8300.
They were (PR18563 and PR18564), but somebody else has closed them as du
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16
05:35 ---
I am reopening this PR to allow tracking this problem independent of PR18542.
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-10
15:45 ---
(In reply to comment #11)
> Are you sure it is even fixed? with gcc-4.0-20050109, the build fails with
> this
> message at what appears to be the same location in the compilation.
>
--
What|Removed |Added
CC||corsepiu at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla
--
What|Removed |Added
Known to work|4.0.0 |4.0.0 3.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
--- 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
riority: 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: arm-rtems4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19393
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12
10:38 ---
Sorry, this is gcc-3.4-branch, not gcc-4.0.x ...
--
What|Removed |Added
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12
14:19 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > What do you want the ABI for soft-float to be?
> > > As RTEMS is probably the only user
read_recursive_mutex's missing
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gn
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19399
--- 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
--- 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.
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-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.
--
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
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
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13
17:04 ---
Patches applied to trunk.
--
What|Removed |Added
Status|NEW
--
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-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
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-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
--- 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-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
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
1 - 100 of 134 matches
Mail list logo
