--- 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 thi
--- 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
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 #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
--- 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 #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_
-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 #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
--
--- 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 #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 #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 #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-08-07 16:26 ---
m32c != m32r
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000
--- 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
--- 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 |
--- 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 o
--- 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 inste
--- 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 #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 #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
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 #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
--- 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
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=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=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=54951
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54952
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment
--
dj at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dj at redhat dot com
|dot org
--- 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
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
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
||
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
--- 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
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
DJ Delorie changed:
What|Removed |Added
Attachment #23074|0 |1
is obsolete|
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=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=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 #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=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=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...
||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=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=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
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
--- 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 updati
--- 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 FO
--- 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
--- 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 sp
--- 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.
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.
--- 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 misspell
--- 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 h
--- 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 at the
--- Comment #4 from dj at redhat dot com 2005-10-10 19:31 ---
Subject: Re: ctype 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
--- 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 sourc
--- 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.
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.
||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
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.
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=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=79935
--- Comment #5 from DJ Delorie ---
DJGPP issues should be sent to the dj...@delorie.com mailing list, or
comp.os.msdos.djgpp newsgroup.
||dj at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from DJ Delorie ---
Patch applied. Thanks!
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
||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=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=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 #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 #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=63582
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
Assignee
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=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=62180
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #4 from
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
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
--- 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 to the
--- 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 #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 #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 #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=21866&action=view)
possible fix
FYI I've been using this to silence the warning in my local tree...
--
http://gcc.gnu.
||2010.09.28 21:18:10
date||
AssignedTo|unassigned at gcc dot |dj at redhat dot com
|gnu.org |
Ever Confirmed|0 |1
--- 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
1 - 100 of 126 matches
Mail list logo
