https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
Joel Sherrill changed:
What|Removed |Added
Last reconfirmed||2025-5-3
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
--- Comment #3 from Joel Sherrill ---
Sorry. Submitted accidentally while incomplete.
(In reply to Andrew Pinski from comment #1)
> >And our test compiles and links fine on that.
>
> That is because arm has defined __atomic_test_and_set in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
--- Comment #2 from Joel Sherrill ---
In reply to Andrew Pinski from comment #1)
> >And our test compiles and links fine on that.
>
> That is because arm has defined in the libgcc.
That symbol is not in the arm-rtems libgcc.a and I do not see
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Target m68k-rtems but likely repeatable on m68k-elf
GCC version:
m68k-rtems7-gcc (GCC) 14.2.0 20240801 (RTEMS 7, RSB
NCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Building with binutils-gdb, newlib-cygwin, and gcc
(25256ec1df10f2eb183e1c1ab0c890e9fdd94384)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment
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 HAVE_DECL_F
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 a/libgcc/config/rs6000/t-savresf
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 a
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&action=edit
Preprocessed output of file
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
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
#define
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 #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 bu
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
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=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
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 newli
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
-B/home/jo
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&action=edit
Merge moxie-rtems stanza with othe
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 i
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 #5 from Joel Sherrill ---
MIPS tools for RTEMS are unbuildable on *BSD due to this GNU sed dependency.
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=63683
--- Comment #1 from Joel Sherrill ---
Still fails on gcc head today.
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=64377
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- Comment #19 from Joel Sherrill ---
Sorry.. wrong PR.
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=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=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 #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 #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=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
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=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
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=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
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 #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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460
Joel Sherrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
: 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=64461
--- Comment #8 from Joel Sherrill ---
Thanks. I didn't build all our Coldfire BSPs but I checked one and it is OK
now.
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=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=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 #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=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.
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=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
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=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=64542
Joel Sherrill changed:
What|Removed |Added
Target||arm-rtems
CC|
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
: 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=37440
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=54747
Joel Sherrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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
||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=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|--- |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=46586
Joel Sherrill changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=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=47540
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
1 - 100 of 338 matches
Mail list logo
