--- Comment #2 from dj at redhat dot com 2006-03-23 18:07 ---
Subject: Re: New: bad allocation while adding new elements to vector
When reporting DJGPP bugs, please run your app under gdb and use
where to get a traceback, or use djgpp's symify (or bfdsymify) to
replace these hex
--- Comment #12 from dj at redhat dot com 2006-06-15 15:19 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from
4 to 8 bytes in initializer
I don't understand the assertion, given that removing it seems to
generate correct output for this test case
--- Comment #11 from dj at redhat dot com 2006-07-31 18:07 ---
(1) I can manage my own bugzilla account, thankyouverymuch, and (2) I'm not the
only build maintainer.
--
dj at redhat dot com changed:
What|Removed |Added
--- Comment #14 from dj at redhat dot com 2006-08-01 17:35 ---
First off, I was mostly just explaining that assertion.
Second, I think that this code can be a valid initializer - the value
we initialize to is, in this case, an 8 byte value which contains the
least significant 4 bytes
--- Comment #16 from dj at redhat dot com 2006-08-01 18:37 ---
I think it's acceptable to temporarily disable that assertion for this release,
but (1) we should test that code on both big and little endian 64 bit machines
and see if it produces wrong code (perhaps with a larger offset
--- Comment #2 from dj at redhat dot com 2006-01-18 20:23 ---
Subject: Re: New: Error in building libiberty
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
--- Additional Comments From dj at redhat dot com 2004-11-22 21:36 ---
Subject: Re: segfault on a huge switch statement.
Confirmed, the problem is because of stack overflow. Either
splay_tree_delete_helper needs a little help or the C/C++ front-end
needs to stop using splay trees
--- Additional Comments From dj at redhat dot com 2004-12-07 20:02 ---
Subject: Re: segfault on a huge switch statement.
I have pushed that change out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18602
--- Additional Comments From dj at redhat dot com 2005-07-07 14:56 ---
Subject: Re: genmodes.c:964: internal compiler error: Bus error in
md5_process_block
I can build the latest CVS binutils on x86_64-linux. Please make sure
you have the include files that correspond
--- Additional Comments From dj at redhat dot com 2005-09-06 02:34 ---
Subject: Re: New: m32c.h has a typo
Note the misspelled ALIGMNENT.
Fixed.
2005-09-05 DJ Delorie [EMAIL PROTECTED]
* config/m32c/m32c.h (TRAMPOLINE_ALIGNMENT): Correct misspelling
of macro
--- Additional Comments From dj at redhat dot com 2005-09-06 02:35 ---
Obvious fix applied to HEAD.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From dj at redhat dot com 2005-09-19 19:57 ---
Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in
initializer
DJ, apparently you caused this one.
Yup, and I had reservations about that portion of the patch at the
time, too, which have
--- Additional Comments From dj at redhat dot com 2005-09-23 17:22 ---
Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in
initializer
I recall that the opposite case is problematic; initializing a large
int from a smaller one, because gcc always zero pads
--- Comment #4 from dj at redhat dot com 2005-10-10 19:31 ---
Subject: Re: ctypechar tables are offset by one on DJGPP
If the proposed patch is regression tested and approved by the DJGPP
maintainers can certainly go in, since touches only the
target-specific files.
I'm OK
--- Comment #2 from dj at redhat dot com 2005-10-17 17:27 ---
Subject: Re: New: Bootstrap failure: conflicting types for
'floatformat_to_double', others
Please make sure you're not building the latest gcc sources
(gcc/libiberty/floatformat.c) with older binutils sources
(src/include
--- Comment #33 from dj at redhat dot com 2005-10-26 23:13 ---
Subject: Re: [3.4/4.0/4.1 Regression] back-slash newline extension can't be
removed
It looks like DJ is saying the same in the new thread which shows
the real issues with the other compilers implemenation.
I would
--- Comment #1 from dj at redhat dot com 2007-02-09 03:10 ---
For starters, gcc is case sensitive. When you passed it PROG1.C instead of
prog1.c, you're telling it to compile a C++ program. Did you install the C++
compiler? Do you get the same error if you use prog1.c instead
--- Comment #3 from dj at redhat dot com 2007-02-09 19:14 ---
Did you follow the zip-picker instructions? You have to use a djgpp-aware
unzip program to install, or the filenames get all messed up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30741
--- Comment #8 from dj at redhat dot com 2007-02-20 15:20 ---
Looks OK to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
--- Comment #1 from dj at redhat dot com 2007-03-09 20:08 ---
Subject: Re: New: Problem while compiling gcc for m32c-elf
Fixed via revision 122759.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31113
--- Comment #3 from dj at redhat dot com 2007-03-26 21:36 ---
30972 is Windows, this is DJGPP - different operating systems.
Are you using the stock 2.03 files, or the 2.04 (beta) files? There are known
incompatibilities in XP and Vista that require the 2.04 builds of the GNU
tools
--- Comment #2 from dj at redhat dot com 2007-05-03 20:01 ---
Note that only 19 out of 33 target directories (trunk) even mention the word
blockage and there's no mention of blockage in the trunk documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31801
--- Comment #4 from dj at redhat dot com 2007-05-03 22:55 ---
Gak, the grep didn't show it earlier today, but does now. Sigh. Lesson: never
buy quantum computers!
We still have the problem that almost half the targets (on trunk) don't have
gen_blockage(). Will updating all
--- Comment #1 from dj at redhat dot com 2007-05-25 03:02 ---
Indeed the SI is suspicious, since the m32c family doesn't have those types of
pointers (it has HI or PSI pointers, but not SI). I've never tried to build
FORTRAN for the m32c family though, so if there's a FORTRAN developer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304
--- Comment #2 from DJ Delorie dj at redhat dot com ---
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217
--- Comment #1 from DJ Delorie dj at redhat dot com 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=54951
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54952
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
--- Comment #5 from DJ Delorie dj at redhat dot com 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 Hirata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238
--- Comment #2 from DJ Delorie dj at redhat dot com ---
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=58238
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot com
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
http://gcc.gnu.org
--- 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 sys/stat.h but doesn't
conditionally enable the other code. If sys/stat.h isn't found,
perhaps
--- 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 #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 #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 #3 from dj at redhat dot com 2007-05-31 21:09 ---
Subject: Re: sim-crt0.o/crt0.o isn't found during configure due to missing -L
or -B
Note that m32c puts *.ld files in the *build* directory, not the
*source* directory, unlike most targets. The m32c source directory
only
--- Comment #5 from dj at redhat dot com 2007-06-01 01:08 ---
m32c still needs -L$$r/$(TARGET_SUBDIR)/libgloss/m32c to find r8c.ld in the
build directory. Your patch would only search in the source directory. Be
careful with -B vs -L, and $$r vs $$s.
You've also removed the special
--- 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
--- 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 #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 #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.org
--- 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 #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 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 #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 installed the gcc 4.2.2 that's built
--- 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-09-25 01:46 ---
Patch applied.
--
dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- 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
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 #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
--- 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, which
--- 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 things gcc
--- 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 #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=14453action=view)
test patch
Could you give this a try on IRIX? It's just an officialized copy of Jakub's
suggestion. My only concern
--- 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=14457action=view)
test patch 2
Here's another try. We collect the libgcc.a objects in multiple variables (18
of them) so that we can invoke
--- 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 simple
pattern
--- 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=14472action=view)
test patch 3
This one just breaks up #15 into three chunks, with everything else in a single
chunk.
--
dj at redhat
--- 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=14473action=view)
sclsh - short command line shell
Here's a short perl script that acts as a short command line shell - it
complains about
--- 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 #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_bug.cgi?id
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
GCC build
--- 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=18129action=view)
test case for the above
Compile with:
./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers
--
http://gcc.gnu.org
--- 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=18130action=view)
resulting .s
--
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=18131action=view)
dump just before rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- 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=18132action=view)
dump just after rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- 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 #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
--- 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 #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
: 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.org/bugzilla
--- 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=15433action=view)
preprocessed cplus-dem.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
--- 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
--
dj at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dj at redhat dot com
|dot org
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-linux-gnu
GCC host
--- 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=15908action=view)
preprocessed file for description
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
--- 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 #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're
caused
--- 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.
--
http
--- 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* legitimate, it's
used
--- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #5 from DJ Delorie dj at redhat dot com 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=46878
--- Comment #5 from DJ Delorie dj at redhat dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
Attachment #23014|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
--- Comment #11 from DJ Delorie dj at redhat dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
--- Comment #12 from DJ Delorie dj at redhat dot com 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
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
Attachment #23074|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548
--- Comment #1 from DJ Delorie dj at redhat dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548
--- Comment #5 from DJ Delorie dj at redhat dot com 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
--- 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 #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=21866action=view)
possible fix
FYI I've been using this to silence the warning in my local tree...
--
http://gcc.gnu.org/bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45800
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
--- 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
--
http
1 - 100 of 126 matches
Mail list logo
