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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
The
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 -mlong-d
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 bu
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 #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. Is
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
#define
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)
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=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: /home/joel/t
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&action=edit
Preprocessed output of file
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #2
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 ---
Still fails on gcc head today.
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=35323&action=edit
Preprocessed source from zlib.c from RTEMS PowerPC bootloader
This file compiled without an undefined symb
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 2
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 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #4 from Joel Sherrill ---
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 but it could also be a more gener
: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 34367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34367&action=edit
Preprocessed RTEMS source which produces the error
Looks like an xscale specific issue at -O2. Doesn't crash at -O
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=34368&action=edit
Preprocessed RTEMS source which produces the error
Fails at -O1, -O2, and -Os. All RTEMS Coldfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #1 from Joel Sherrill ---
Doing a git bisect showed this to be the commit that broke things. Clearly not
m68k specific but triggered it.
commit 91ae0791cbebaac673e42e53c8b7f000241a0ca1
Author: dj
Date: Fri Aug 29 23:19:42 2014 +0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #2 from Joel Sherrill ---
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 of BSPs which trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53314
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46586
Joel Sherrill changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
||joel at gcc dot gnu.org
Resolution|--- |WONTFIX
Known to fail||
--- Comment #14 from Joel Sherrill ---
CPU long dead. Target removed from GCC long ago. Closing as won't fix.
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
--
||joel at gcc dot gnu.org
Resolution|--- |WORKSFORME
--- Comment #1 from Joel Sherrill ---
Ancient PR. Can't reproduce now. Closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #5 from Joel Sherrill ---
(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 in on doing the git
bisect. Hoped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51192
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54747
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36828
--- Comment #4 from Joel Sherrill ---
Based on the last comment, should this PR be closed. It has been five years.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #1 from Joel Sherrill ---
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 after this (roughly 5 step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55192
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: 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 ---
Created attachment 34405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34405&action=edit
Processed output from RTEMS cpu.c which produces the error
Looking at the error message, I am not sure if this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
Joel Sherrill changed:
What|Removed |Added
Target||arm-rtems
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #7 from Joel Sherrill ---
(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. Backporting r21068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #8 from Joel Sherrill ---
(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 to the 4.9 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #6 from Joel Sherrill ---
(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 to be addressed
> for GCC 5 releas
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 ---
Created attachment 34409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34409&action=edit
Preprocessed newlib source which produces the ICE
This code compiles with 4.8.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #4 from Joel Sherrill ---
(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 that
> attribute.
Awes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #8 from Joel Sherrill ---
(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-patches/2015-01/msg004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #6 from Joel Sherrill ---
(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" attribute value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
--- Comment #8 from Joel Sherrill ---
(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/msg00686.html
Can yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #8 from Joel Sherrill ---
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=34431&action=edit
Cut down example showing error
The attached example is based on code that has compiled fine fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64576
--- Comment #3 from Joel Sherrill ---
(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. u"str", U"str" and
> u8"str".
> S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
Joel Sherrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=34449&action=edit
Preprocessed RTEMS source which produces the error
$ arm-rtems4.11-gcc --version
arm-rtems4.11-g
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=64600
--- Comment #1 from Joel Sherrill ---
Created attachment 34450
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34450&action=edit
Preprocessed RTEMS source which produces the error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64599
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600
--- Comment #2 from Joel Sherrill ---
*** 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 ---
(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 or -O2.
-O2 without -mcpu
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64602
--- Comment #1 from Joel Sherrill ---
Created attachment 34451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34451&action=edit
Preprocessed source of libssp/ssp.c that trips error
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=64600
--- Comment #9 from Joel Sherrill ---
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 bisect, I
usually drop t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #7 from Joel Sherrill ---
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=63741
--- Comment #3 from Joel Sherrill ---
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 since this is a cross targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #9 from Joel Sherrill ---
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/ -nostdinc
-B/users/joel/test-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #6 from Joel Sherrill ---
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 #18 from Joel Sherrill ---
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=64377
--- Comment #19 from Joel Sherrill ---
Sorry.. wrong PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #7 from Joel Sherrill ---
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=64377
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
git 4.9 branch with last commit 1d2b7cdfcb9376a6ee98964b11cf73fe14154e13
newlib head
Configure command (lots of newlib options)
../${GCC}/configure \
--prefix
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
On the m32c, C++ and Java are not supported. Thus we build with C only and the
target doesn't have any need for SJLJ information. Unfortun
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
gcc 4.9 branch in git at 1d2b7cdfcb9376a6ee98964b11cf73fe14154e13
newlib head
m32c fails with ICE
Configured as follows:
../${GCC}/configure \
--prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682
--- Comment #2 from Joel Sherrill ---
Created attachment 33847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33847&action=edit
config.log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682
--- Comment #3 from Joel Sherrill ---
(In reply to DJ Delorie from comment #1)
> m32c-elf supports C++. What is the contents of the failing config.log?
Hmm... then this should work. We intentionally don't deviate much from *-elf
targets. I was
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33886
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33886&action=edit
Preprocessed RTEMS fastlz.c which produces the error.
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
Joel Sherrill changed:
What|Removed |Added
Known to fail||4.9.1
--- Comment #1 from Joel Sherrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #2 from Joel Sherrill ---
Broken on head as well.
lm32-rtems4.11-gcc (GCC) 5.0.0 20141104 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #7
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33895
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33895&action=edit
Preprocessed newlib/libc/stdlib/mprec.c which generates the ICE
xgcc (GCC) 5.0.0 20141104 (experimenta
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33898&action=edit
autoconf probe for ICE
configure:: /users/joel/test-gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63754
Joel Sherrill changed:
What|Removed |Added
Target||h8300-rtems
Known to work|
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33899&action=edit
autoconf libgcc probe generating ICE
xgcc (GCC) 5.0.0 20141104 (experimental)
configure::
: 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=33934&action=edit
Preprocessed newlib ecvtbuf.c which produces the ICE
gcc, binutils-gdb, newlib he
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=34312&action=edit
Preprocessed fopencookie.c from newlib
xgcc (GCC) 5.0.0 20141221 (experimental)
This appears to be com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #1 from Joel Sherrill ---
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 with the magic in these
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Host: x86_64-unknown-linux-gnu
Target: mips-rtems4.11
Created attachment 33358
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
I can provide more details but since this is just with compiling libgcc, I
doubt that much else is needed.
I last built this target on:
arm-rtems4.11-gcc (GCC) 5.0.0 20140818 (experimental)
/users/joel/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203
--- Comment #3 from Joel Sherrill ---
Could your change have impacted multiple targets? I see ICE on i386, nios2,
powerpc, and sh.
I would be happy to learn I just started a sweep at an unfortunate point. I
have updated my gcc tree and will star
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203
--- Comment #5 from Joel Sherrill ---
Appears to be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62177
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55928
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
configure: WARNING: decimal float is not supported for this target, ignored
checking whether fixed-point is supported... no
checking whether to use setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610
--- Comment #3 from Joel Sherrill ---
For the preprocessed newlib strtod source, -O2 will reproduce. Dropping -EL or
to -O1 results in it compiling.
/users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-mips-rtems4.11-gcc
201 - 300 of 336 matches
Mail list logo
