https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62269
--- Comment #2 from DJ Delorie ---
Sorry for not being as responsive as I should be, but I've tried occasionally
to fix the m32c-gcc issues and they just keep getting worse. I suspect m32c
should be deprecated at this point, it's not one of of t
||dj at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from DJ Delorie ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #24 from DJ Delorie ---
"olegendo at gcc dot gnu.org" writes:
> I don't know why it was decided to use this ABI. Maybe some legacy
> stuff.
Compatibility with Renesas's compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935
--- Comment #5 from DJ Delorie ---
DJGPP issues should be sent to the dj...@delorie.com mailing list, or
comp.os.msdos.djgpp newsgroup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584
DJ Delorie changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from DJ Delorie --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584
--- Comment #4 from DJ Delorie ---
kernel-4.8.6-201.fc24.x86_64
glibc-2.23.1-11.fc24.x86_64
but I'm also working on a libiberty patch to detect the case and avoid it.
||2016-11-29
CC||dj at redhat dot com
Ever confirmed|0 |1
--- Comment #2 from DJ Delorie ---
Confirmed on Fedora 24 with gcc 6.2.1, but agreed, the @file thing is for
reading arguments from a file, not compiling a
||dj at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from DJ Delorie ---
Patch applied. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71338
--- Comment #4 from DJ Delorie ---
Sure, the only dependencies might be on binutils/gdb releases, but they support
it and they're independent of gcc releases anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69073
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #3 from
||2015-10-27
CC||dj at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from DJ Delorie ---
Confirmed with git trunk as of today, even with -O0. Gimple shows:
test1 (unsigned int a)
{
unsigned int D.1764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67529
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #15 from DJ Delorie ---
The binutils team has been working a lot on patching vulnerabilities in the
binutils tools. The m32c, however, has a 3-byte reloc that might occur at the
end of a section, and was implemented as three bytes of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #12 from DJ Delorie ---
The reloc bug is caused when gcc puts a JMP.A at the very end of .text and also
adds debug info; this puts a 3-byte reloc right at the end of a section
(m32c-as pads the last section if it's a code section, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #11 from DJ Delorie ---
I see the "relocation out of range" error too.
I'm configuring for m32c-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #8 from DJ Delorie ---
There are a few regressions in the testsuite (pr26255.c with -mcpu=m32c for
example) and libstdc++ still doesn't build, but ieee/920810-1 now passes and
newlib builds. I suppose that's "better".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682
--- Comment #1 from DJ Delorie ---
m32c-elf supports C++. What is the contents of the failing config.log?
Also, there's nothing m32c-specific in the sjlj checks, it's the same for all
sjlj targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582
DJ Delorie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304
--- Comment #2 from DJ Delorie ---
The diagnostic changes that happen with #pragmas are stored in a linear array,
which corresponds (somehow) to the linear input source file representation.
So, given a location in the source, we can find the spot
||2013-08-26
CC||dj at redhat dot com
Assignee|unassigned at gcc dot gnu.org |dj at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from DJ Delorie ---
Created attachment 30702
--> h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238
--- Comment #2 from DJ Delorie ---
Please try the attached patch. I tested it with a simple "#include stdint.h"
but we made the type names exact matches (way back when) for a reason...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #2 from DJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
--- Comment #5 from DJ Delorie 2013-05-02 17:39:29 UTC
---
I'm OK with it being committed, but it's not up to me, ping Jeff or Kazu.
h8 portJeff Lawl...@redhat.com
h8 portKazu Hiratak...@codesource
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54952
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54951
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217
--- Comment #1 from DJ Delorie 2012-08-10 00:22:22 UTC
---
Created attachment 27978
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27978
test case for rl78-elf, from newlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217
Bug #: 54217
Summary: setup_save_areas() duplicates hard reg uses
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52100
Bug #: 52100
Summary: CRTSTUFF_CFLAGS needs -fno-asynchronous-unwind-tables
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #1 from DJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #5 from DJ Delorie 2011-06-02 20:33:43 UTC
---
Given that I forgot I had it, probably "no"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548
--- Comment #5 from DJ Delorie 2011-02-04 15:21:40 UTC
---
See if one of these other changes caused the problem. If so, yeah, I'll check
this one in and we'll work on the other one separately. The new error you're
seeing is one I've seen on and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #3 from DJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548
--- Comment #1 from DJ Delorie 2011-02-01 01:06:43 UTC
---
Created attachment 23192
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23192
Patch to avoid trying to validate interim patterns
Try this one. If there are multiple reloads needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
DJ Delorie changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
DJ Delorie changed:
What|Removed |Added
Attachment #23074|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
--- Comment #12 from DJ Delorie 2011-01-22 00:40:44 UTC
---
Of course, one could argue that perhaps the compare should *not* have been
removed? I don't know how clever the new redundant compare removal code is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
--- Comment #11 from DJ Delorie 2011-01-22 00:37:35 UTC
---
I set a breakpoint on the delete of that insn; at that time, the following insn
did not have the /S set on it. At the time when the /S is added, the previous
insn had already been delet
||
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |dj at redhat dot com
|gnu.org |
--- Comment #8 from DJ Delorie 2011-01-21 22:31:37 UTC
---
Created attachment 23074
--> http://gcc.gnu.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #7 from DJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
--- Comment #5 from DJ Delorie 2011-01-18 01:46:00 UTC
---
Created attachment 23014
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23014
alternate patch
Alternate patch. The v850.md patch tests frame_related, which is set for REGS
only to
||2010.09.28 21:18:10
date||
AssignedTo|unassigned at gcc dot |dj at redhat dot com
|gnu.org |
Ever Confirmed|0 |1
--- Comment #6 from dj at redhat dot com 2010-09-22 20:22 ---
Created an attachment (id=21866)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21866&action=view)
possible fix
FYI I've been using this to silence the warning in my local tree...
--
http://gcc.gnu.
--- Comment #5 from dj at redhat dot com 2010-09-22 20:13 ---
Still fails for both h8300-elf and rx-elf, both on 4.5 branch and 4.6 trunk.
--
dj at redhat dot com changed:
What|Removed |Added
--- Comment #28 from dj at redhat dot com 2010-08-12 18:08 ---
I built your test case with gcc and g++ without optimizations, and it worked
fine. I could only get it to fail with gcc/g++ by optimizing, but then, I
could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC
--- Comment #20 from dj at redhat dot com 2010-08-12 16:57 ---
Just for fun, I compiled this test case with various levels of optimization.
It works fine without optimization or with -O1, but segfaults at -O2 or -O3.
That indicates that the program only works by coincidence, not by
--- Comment #4 from dj at redhat dot com 2010-07-09 05:12 ---
Right, I haven't sent the patch in yet. The other bug needs to be fixed first;
the TST patch triggers an ICE otherwise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44884
--- Comment #2 from dj at redhat dot com 2010-07-09 05:03 ---
I've got a patch for it, just haven't sent it in yet. See
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg3.html too
--
dj at redhat dot com changed:
What|Removed
--- Comment #3 from dj at redhat dot com 2010-06-07 18:14 ---
Subject: Re: gengtype: don't test undefined value after vasprintf failure
> If the libiberty maintainers won't review the xvasprintf patch,
I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html
--- Comment #4 from dj at redhat dot com 2010-01-08 20:51 ---
Still present in 4.5 trunk, also fails for rx-elf-gcc with -m32bit-doubles but
not with -m64bit-doubles.
--
dj at redhat dot com changed:
What|Removed |Added
--- Comment #1 from dj at redhat dot com 2009-11-02 22:04 ---
Subject: Re: New: psignal() declaration needs const char*
Libiberty should not even try to compile psignal() on djgpp as djgpp
already has one. This is noted in libiberty/configure.ac.
--
http://gcc.gnu.org/bugzilla
--
dj at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dj at redhat dot com
|dot org
--- Comment #4 from dj at redhat dot com 2009-08-07 16:26 ---
m32c != m32r
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000
--- Comment #5 from dj at redhat dot com 2009-07-10 02:56 ---
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00546.html
Fixed in revision 149455.
--
dj at redhat dot com changed:
What|Removed |Added
--- Comment #4 from dj at redhat dot com 2009-07-02 21:43 ---
Created an attachment (id=18132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18132&action=view)
dump just after rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #3 from dj at redhat dot com 2009-07-02 21:42 ---
Created an attachment (id=18131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18131&action=view)
dump just before rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #2 from dj at redhat dot com 2009-07-02 21:42 ---
Created an attachment (id=18130)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18130&action=view)
resulting .s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #1 from dj at redhat dot com 2009-07-02 21:41 ---
Created an attachment (id=18129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18129&action=view)
test case for the above
Compile with:
./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers
--
-registers causes register corruption
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dj at redhat dot com
--- Comment #4 from dj at redhat dot com 2009-05-18 19:16 ---
Yes, those two changes are the fix you need. However, those fixes were over
three years ago, so I consider this bug "already fixed". If you agree, please
close this bug.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from dj at redhat dot com 2009-05-14 02:52 ---
Do you have a test case that shows an actual problem? Because the m32c port
has special code that tests for shift counts outside -16..16 and pre-shifts the
value to make the shift count fit (see gcc/config/m32c/m32c.c
--- Comment #3 from dj at redhat dot com 2009-02-13 20:28 ---
Fails with m32c-elf in 4.3.4 also.
Note: does NOT fail in 4.4/trunk
--
dj at redhat dot com changed:
What|Removed |Added
--- Comment #2 from dj at redhat dot com 2009-02-02 21:52 ---
You should put the new code in a #ifdef HAVE_STDINT and use the old code
otherwise. Else, any platforms without stdint.h would not compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
--- Comment #9 from dj at redhat dot com 2009-01-27 19:38 ---
Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.
--
http
--- Comment #3 from dj at redhat dot com 2009-01-26 19:46 ---
Subject: Re: New: libiberty make_relative_prefix_1 mistakes directories for
executables
Your code conditionally includes but doesn't
conditionally enable the other code. If sys/stat.h isn't found,
perhaps the
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-elf
--- Comment #8 from dj at redhat dot com 2008-11-14 23:09 ---
The test case segfaults on simulators that don't initialize argv[0] to the name
of the running program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
--- Comment #14 from dj at redhat dot com 2008-07-18 00:22 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
Seems to work for m32c too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
--- Comment #11 from dj at redhat dot com 2008-07-16 19:08 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
Last night's builds showed a flaw in the patch. The "++rii" address
created by m32c_legitimize_reload_address is *not* legiti
--- Comment #8 from dj at redhat dot com 2008-07-16 03:04 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
The regressions all show up in v850 and iq2000 too, except one that I
can't reproduce, so I'm not going to worry about them.
--- Comment #7 from dj at redhat dot com 2008-07-16 02:07 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
It fixes the newlib compile failure, but there are regressions since
it last built. I'll have to check each of them to see if they'
--- Comment #4 from dj at redhat dot com 2008-07-15 15:38 ---
Yes, 137639 and 137640 are the same patch, to trunk and 4.3, respectively.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
--- Comment #1 from dj at redhat dot com 2008-07-14 22:31 ---
Created an attachment (id=15908)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15908&action=view)
preprocessed file for description
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-
--- Comment #1 from dj at redhat dot com 2008-04-05 15:36 ---
Created an attachment (id=15433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15433&action=view)
preprocessed cplus-dem.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-elf
http://gcc.gnu.or
--- Comment #7 from dj at redhat dot com 2008-01-08 22:00 ---
Subject: Re: as crashed
DJGPP 2.04 is newer than djgpp 2.03. You need to try the gcc 4.2.2
that's built with djgpp 2.04 (it's in the "beta" subdir, instead of
"current"). You have instal
--- Comment #5 from dj at redhat dot com 2008-01-08 21:26 ---
Subject: Re: as crashed
Have you tried the 2.04 version?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34687
--- Comment #13 from dj at redhat dot com 2007-11-02 18:58 ---
Created an attachment (id=14473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14473&action=view)
sclsh - short command line shell
Here's a short perl script that acts as a "short command line shel
--- Comment #12 from dj at redhat dot com 2007-11-02 18:56 ---
Created an attachment (id=14472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14472&action=view)
test patch 3
This one just breaks up #15 into three chunks, with everything else in a single
chunk.
--
dj at
--- Comment #10 from dj at redhat dot com 2007-11-02 17:41 ---
Subject: Re: [4.3 Regression] "Arg list too long" building libgcc.a
You could try splitting that one in two with gmake's $(filter ) and
$(filter-out ) functions. The only trick would be finding a simp
--- Comment #5 from dj at redhat dot com 2007-11-01 20:02 ---
Created an attachment (id=14457)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14457&action=view)
test patch 2
Here's another try. We collect the libgcc.a objects in multiple variables (18
of them) so
--- Comment #3 from dj at redhat dot com 2007-11-01 16:03 ---
Created an attachment (id=14453)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14453&action=view)
test patch
Could you give this a try on IRIX? It's just an officialized copy of Jakub's
suggestion. M
--- Comment #8 from dj at redhat dot com 2007-10-31 22:27 ---
Subject: Re: iv folding fails with pointer iterations
Right, that's why I was trying to use 32 bit math instead, which led
to the original iv bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #6 from dj at redhat dot com 2007-10-31 18:36 ---
Subject: Re: iv folding fails with pointer iterations
Hmmm... pointers are PSImode (24 bits) with --mcpu=m32c. How do you
make sizetype that size? The chip doesn't have enough 24 bit math
opcodes to do all the thing
--- Comment #4 from dj at redhat dot com 2007-10-31 18:03 ---
Subject: Re: iv folding fails with pointer iterations
Oops, sorry, I have a local patch. Apparently I'm trying to support
pointer math the same size as pointers (pointers are 24 bits) as an
option for the future,
--- Comment #2 from dj at redhat dot com 2007-10-30 04:30 ---
Subject: Re: iv folding fails with pointer iterations
Yup. I did a source update, rebuilt the natives, and tried to build...
m32c-elf-gcc -B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/ -isystem
/greed/dj/m32c
ver at kam dot mff dot cuni dot cz
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #7 from dj at redhat dot com 2007-09-25 02:15 ---
Seems to work for me now; could you recheck it with the patches I just
committed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
--- Comment #3 from dj at redhat dot com 2007-09-25 01:46 ---
Patch applied.
--
dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from dj at redhat dot com 2007-09-25 01:46 ---
Patch applied.
--
dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from dj at redhat dot com 2007-07-23 17:29 ---
Subject: Re: New: [4.3 Regression] "make info" fails in libiberty
I've checked in a fix for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
--- Comment #5 from dj at redhat dot com 2007-07-17 17:52 ---
Subject: Re: gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ...
gettimeofday - tests twice
I removed the duplicate from the msdosdjgpp case.
svn rev 126704
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from dj at redhat dot com 2007-07-14 02:58 ---
Subject: Re: New: internal error - compiling DiskEditor (hed.c)
> gcc.exe: Internal error: (null) (program as)
djgpp 2.03 (current) or 2.04 (beta) ? You might need the XP bugfixes
in 2.04.
--
http://gcc.gnu.
--- Comment #1 from dj at redhat dot com 2007-06-28 02:09 ---
Ok to commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32532
--- Comment #21 from dj at redhat dot com 2007-06-27 21:28 ---
Subject: Re: [4.3 Regression] ICE in global_alloc, at global.c:514
The patch in comment #9 is OK with me, please commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
--- Comment #6 from dj at redhat dot com 2007-06-20 17:35 ---
Subject: Re: ICE in global_alloc, at global.c:514
It was a long time ago, I'm thinking that having too many hard regs
live during reload causes problems on m32c because it has so few
registers. You can try setting
1 - 100 of 126 matches
Mail list logo
