https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115874
--- Comment #3 from Joel Sherrill ---
config.h includes auto-host.h which appears to be defining the macros:
/* Define to 1 if we found a declaration for 'fputc_unlocked', otherwise
define to 0. */
#ifndef USED_FOR_TARGET
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115874
Joel Sherrill changed:
What|Removed |Added
Host||cygwin
Target|
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Target: sh-rtems6
Host: Cygwin
We have not seen this failure on Linux. stdio.h must be implicitly included.
This is the error on Cygwin. Is adding an include the right
: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
newlib has been updated to always provide an fenv.h with prototypes for the
required methods. Unfortunately, this has triggered code in math/x2y2m1q.c
which incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91303
--- Comment #3 from Joel Sherrill ---
Pursuing the assumption that the e500 files shouldn't be build, I decided to
remove them from the t-savresfgpr files. With this patch, powerpc-rtems5 builds
again:
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91303
--- Comment #2 from Joel Sherrill ---
I admit to being completely confused by the multitude of PwerPC variants but if
the e500 was deleted, why does libgcc/config.host still include
libgcc/config/rs6000/t-savresfgpr for multiple powerpc targets
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Building off the git master, powerpc gave this compile error:
(GCC) 10.0.0 20190730 (experimental)
I forgot to update yesterday and it was also broken with "(GCC) 10.0.0 201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #20 from Joel Sherrill ---
I filed this in 2011 and we dropped RTEMS support for the m32c last year for
our next release. If you all think it is fixed, please feel free to close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81804
--- Comment #1 from Joel Sherrill ---
Version: (GCC) 8.0.0 20171120
target: m32c-rtems, likely for m32c-elf
Still happens. line number has moved in the source file but ICE is still the
same.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Created attachment 42670
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42670=edit
Preprocessed output of file causing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #16 from Joel Sherrill ---
I assume this ICE during a build of bfin-rtems on the master is indicative of
the same underlying problem. I have reported this before on the sh2e but didn't
know of this PR.
libtool: compile:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #9
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Version: (GCC) 8.0.0 20170809
target: m32c-rtems, likely for m32c-elf
checking for m32c-rtems4.12-gcc...
/home/joel/test-gcc/b-m32c-rtems4.12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79391
--- Comment #2 from Joel Sherrill ---
It builds on the gcc head and the 7 branch now.
Should we just go ahead and close this or does it matter when it was fixed?
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
xgcc (GCC) 7.0.1 20170205 (experimental)
using newlib and binutils master
/home/joel/test-gcc/b-sh-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78480
--- Comment #1 from Joel Sherrill ---
Still occurs on:
gcc (GCC) 7.0.1 20170205 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #24 from Joel Sherrill ---
Would you mind applying this to the 6.x branch? That was where the issue was
initially spotted.
I don't know what to do about this extra line in rtemself.h though. It was not
present in the master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #20 from Joel Sherrill ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Joel Sherrill from comment #18)
> > I changed that line to
> >
> > #ifdef _SOFT_FLOAT
> > #include "config/fpu-generic.h"
> >
> > and it built.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #18 from Joel Sherrill ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Joel Sherrill from comment #16)
> > Thanks for all the feedback. With this patch, it now builds. Is the style of
> > change to configure.host OK?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #16 from Joel Sherrill ---
Thanks for all the feedback. With this patch, it now builds. Is the style of
change to configure.host OK?
I need to check how far back this impacts. A user reported it with a released
gcc. Since we don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #14 from Joel Sherrill ---
(In reply to H.J. Lu from comment #13)
> The problem is config/i386/rtemself.h has
>
> #define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
>
> XFmode isn't available with -msoft-float even when
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Target: lm32-rtems
GCC git master: acb9fddd8093a3f623837ac25f6d50f52d9a80eb
Newlib git master: e02866a1b43fae39d6842bd182de79e54d8e74cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #8 from Joel Sherrill ---
We are using gcc 4.9.3 for RTEMS 4.11 and gcc 6.3.0 on RTEMS 4.12. This doesn't
happen on either GCC. So closing.
is target for at
least rtems is an acceptable solution. Soft float seems to be the thing that
breaks on x86 and I don't know that there is really a CPU that needs it
anymore.(In reply to Uroš Bizjak from comment #8)
> (In reply to jos...@codesourcery.com from comment #7)
> > On Tue, 17 Jan 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #6 from Joel Sherrill ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> >
> > --- Comment #2 from Uroš Bizjak
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
7.0.0 20170111
Nothing particularly special about the build. Just fails early with ICE.
/home/joel/test-gcc/b-sh-elf-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-sh-elf-gcc/./gcc/ -nostdinc
-B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #4 from Joel Sherrill ---
FWIW I haven't been able to build this far using i386-elf. It fails in
libbacktrace doing a configure probe because there isn't a crt0.o. I can't
figure out why it isn't building libgloss. I have it and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #3 from Joel Sherrill ---
That patch gets the build further but there is more wrong. __float128 isn't
defined.
/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
$ ./gcc/xgcc --version
xgcc (GCC) 7.0.0 20161121 (experimental)
I think the key is -mcpu=5206 has double and long double to be the same but
_LDBL_EQ_DBL. Craig Howland suggested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
Joel Sherrill changed:
What|Removed |Added
Target||i386-rtems4.12
Known to work|
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
This is on the git master (13d9a9837159ecd162d08fbbe2ef655aebb7a4c9) as of
yesterday.
This appears to be an issue with soft-float.
/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720
--- Comment #2 from Joel Sherrill ---
Sebastian, should this be applied to other branches?
Should the PR be closed?
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Created attachment 38305
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38305=edit
Merge moxie-rtems stanza with other moxie stan
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
In code which indents cpp directives to match the code, the checker is
confused. The following example is sufficient to generate the warning.
===
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097
--- Comment #8 from Joel Sherrill ---
(In reply to rsand...@gcc.gnu.org from comment #7)
> AIUI usual practice is not to assign stuff to people
> without asking them first, otherwise it gives the
> impression that someone is actively working on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097
--- Comment #5 from Joel Sherrill ---
MIPS tools for RTEMS are unbuildable on *BSD due to this GNU sed dependency.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097
--- Comment #6 from Joel Sherrill ---
git blame pins us down a bit on the change:
4b366ca9 (rsandifo 2014-02-07 07:46:34 + 74) hardfp_defines_for = \
4b366ca9 (rsandifo 2014-02-07 07:46:34 + 75) $(shell echo $1 | \
4b366ca9 (rsandifo
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 35323
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35323action=edit
Preprocessed source from zlib.c from RTEMS PowerPC bootloader
This file compiled without an undefined symbol with many
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
This occurs during the exception model probe for libstdc++-v3. This should be
reproducible on v850-elf. I think this is the conftest.c based on the
aclocal.m4 file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63683
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Still fails on gcc head today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #6 from Joel Sherrill joel at gcc dot gnu.org ---
I am not an expert on the machine descriptions or the lm32. If someone wants to
propose a patch, I am happy to test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #19 from Joel Sherrill joel at gcc dot gnu.org ---
Sorry.. wrong PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #9 from Joel Sherrill joel at gcc dot gnu.org ---
I updated binutils, newlib and gcc. The build fails very early for me:
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #18 from Joel Sherrill joel at gcc dot gnu.org ---
I added Jon Beniston who did the initial port and Sebastien Bourdeauducq who is
listed as the lm32 maintainer but hasn't committed since 2011. I hope one of
them can help out here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #7 from Joel Sherrill joel at gcc dot gnu.org ---
I added Jon Beniston who did the initial port and Sebastien Bourdeauducq who is
listed as the lm32 maintainer but hasn't committed since 2011. I hope one of
them can help out here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #3 from Joel Sherrill joel at gcc dot gnu.org ---
Added the dwarf maintainers hoping to get an answer. From an RTEMS perspective,
the lm32 is not usable. Both 4.9 and the head are broken. Hoping you two have
an idea. Happy to help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #7 from Joel Sherrill joel at gcc dot gnu.org ---
DJ.. do you think the patch from Bernd can be applied to the 4.9 branch? and
maybe the head?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600
--- Comment #9 from Joel Sherrill joel at gcc dot gnu.org ---
I don't build with checking enabled.
The normal recommended configuration for an RTEMS toolchain is long since we
build newlib at the same time and have iconv options. When I do git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64602
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Created attachment 34451
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34451action=edit
Preprocessed source of libssp/ssp.c that trips error
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 34449
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34449action=edit
Preprocessed RTEMS source which produces the error
$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20150114 (experimental)
Last hash per git: commit d4cbe45aae70e38c12f3cd7430427c98289d7882
The fix for 64460 is in place.
Attached test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64599
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600
--- Comment #2 from Joel Sherrill joel at gcc dot gnu.org ---
*** Bug 64599 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600
--- Comment #3 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Joel Sherrill from comment #1)
Created attachment 34450 [details]
Preprocessed RTEMS source which produces the error
Attached test case compiles at -Os but not -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Created attachment 34450
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34450action=edit
Preprocessed RTEMS source which produces the error
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
git head d4cbe45aae70e38c12f3cd7430427c98289d7882
/users/joel/test-gcc/b-h8300-elf-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-h8300-elf-gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
/users/joel/test-gcc/b-arm-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-arm-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-arm-rtems4.11-gcc/arm-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64576
--- Comment #3 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
GCC 4.9 behaves the same way with -std=c11, GCC 5 behaves the old way with
-std=c99. -std=c11 turns on unicode literals, i.e. ustr, Ustr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #6 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to ktkachov from comment #5)
(In reply to Joel Sherrill from comment #4)
(In reply to ktkachov from comment #3)
I have a fix in the works. The bug is down to the shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #8 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to ktkachov from comment #7)
I guess the testcase is flaky.
I've posted the patch to fix the ICE and the reasoning behind it at
https://gcc.gnu.org/ml/gcc-patches/2015-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #8 from Joel Sherrill joel at gcc dot gnu.org ---
Thanks. I didn't build all our Coldfire BSPs but I checked one and it is OK
now.
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 34431
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34431action=edit
Cut down example showing error
The attached example is based on code that has compiled fine for about 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #8 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Martin Liška from comment #7)
Hello.
There's suggested patch [1], may I ask someone from nios2 community for
testing the patch?
[1] https://gcc.gnu.org/ml/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #4 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
I have a fix in the works. The bug is down to the shift attribute value in
one of the patterns, although only xscale_sched_adjust_cost uses
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
xgcc (GCC) 5.0.0 20150107 (experimental)
This fails at -O[012S]. The flag -mcpu=m32cm appears to be the trigger.
/home2/joel/build/b-m32c-gcc/./gcc/xgcc -B/home2/joel/build/b-m32c-gcc/./gcc/
-c -g -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64546
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Created attachment 34409
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34409action=edit
Preprocessed newlib source which produces the ICE
This code compiles with 4.8.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #6 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Sandra Loosemore from comment #5)
I think complete failure to build GCC for nios2 target due to
target-inspecific changes is a serious regression that needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #7 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Yaakov Selkowitz from comment #6)
(In reply to Mikael Pettersson from comment #5)
The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with
r210683
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 4.9.3 20150104 (prerelease)
arm-rtems4.11-gcc --pipe -mthumb -march=armv6-m --pipe -DHAVE_CONFIG_H
-I../../.. -I../../../../../../lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Created attachment 34405
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34405action=edit
Processed output from RTEMS cpu.c which produces the error
Looking at the error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Target||arm-rtems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #8 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
Did it work with 4.9.1?
No. Based on git checkout gcc-4_9_1-release
Ditto for 4.9.0.
Hopefully the recommended patch can be applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55192
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
I ran a git bisect and it didn't narrow it down much but I hope this helps.
After the list of candidates, I am posting the full git bisect log.
Bisecting: 27 revisions left to test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #5 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #4)
The easiest fix is to disable the three trunc patterns for the coldfire.
This isn't my area of expertise. That's why I focused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51192
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54747
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14554
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36828
--- Comment #4 from Joel Sherrill joel at gcc dot gnu.org ---
Based on the last comment, should this PR be closed. It has been five years.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14538
Bug 14538 depends on bug 14436, which changed state.
Bug 14436 Summary: ICE building libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Doing a git bisect showed this to be the commit that broke things. Clearly not
m68k specific but triggered it.
commit 91ae0791cbebaac673e42e53c8b7f000241a0ca1
Author: dj dj@138bc75d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #2 from Joel Sherrill joel at gcc dot gnu.org ---
Multiple BSPs trigger this on various files which is not a surprise seeing as
it is generating an illegal memory to memory move. But in case it helps, this
is the list of CPU CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46586
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53314
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436
Joel Sherrill joel at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 34367
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34367action=edit
Preprocessed RTEMS source which produces the error
Looks like an xscale specific issue at -O2. Doesn't crash at -O1. Worked
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 34368
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34368action=edit
Preprocessed RTEMS source which produces the error
Fails at -O1, -O2, and -Os. All RTEMS Coldfire BSPs appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #4 from Joel Sherrill joel at gcc dot gnu.org ---
Since this happens on two target architectures, could someone look at it enough
to put it in the right component. It could be the same type of defect on two
different targets
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 34312
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34312action=edit
Preprocessed fopencookie.c from newlib
xgcc (GCC) 5.0.0 20141221 (experimental)
This appears to be completely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Looking at the generated options-save.c, the first line of this method is
clearly incorrect in the cast on the RHS. It looks like a full declaration and
not a type. If anyone familiar
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
g++ -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33934
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33934action=edit
Preprocessed newlib ecvtbuf.c which produces the ICE
gcc, binutils-gdb, newlib head. gcc git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #2 from Joel Sherrill joel at gcc dot gnu.org ---
Broken on head as well.
lm32-rtems4.11-gcc (GCC) 5.0.0 20141104 (experimental)
1 - 100 of 331 matches
Mail list logo
