--- Comment #22 from raf2 at msux dot cjb dot net 2007-05-16 08:50 ---
Mmm... maybe I haven't explained correctly.
If you contract someone to build stairs and later he says: As long as you
don't touch this step, everything's ok you tell him some nasty things.
The users of our g++
--- Comment #18 from pault at gcc dot gnu dot org 2007-05-16 09:10 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-16 09:11 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-16 09:13 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 09:14 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-16 09:15 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Since the following patch:
2007-04-22 Uros Bizjak [EMAIL PROTECTED]
PR tree-optimization/24659
GCC supports vectorization of float--double conversions. These can also be
modelled for the spu target by implementing the following patterns:
vec_pack_trunc_v2df
vec_unpacks_lo_v4sf
The vectorizer is too restricted in the way it decides by how many iterations
to peel a loop in order to align a certain memory reference in a loop. It
considers only the first (potentially) misaligned store it encounters in the
loop. For this reason the testcases vect-multitypes-1.c,
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 09:50 ---
Over to you, Daniel - I was smiling when I mentioned using the time for
something else; there was no need to apologise.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-05-16 10:18
---
*** Bug 31940 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-16 10:18 ---
Confirmed. A regression with -O2 -ftrapv.
Program received signal SIGSEGV, Segmentation fault.
0x00830f6e in compare_values (val1=0x0, val2=0x2ac511f0e9f0)
at
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-05-16 10:20
---
Reopen, because this happens on the 4.1 branch as well with -O2 -ftrapv
void f1(int);
void f2(int x)
{
if (x != -2147483647 - 1)
f1(-x);
}
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-16 10:23 ---
/home/tbm/src/digikam-0.9.1/./digikam/libs/widgets/metadata/iptcwidget.cpp:159:
error: request for member 'c_str' in '
?
so there seems to be an error. Of course we probably ICE during error
reporting
which may
--- Comment #70 from rguenth at gcc dot gnu dot org 2007-05-16 10:57
---
The last patch looks good sofar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #1 from aurelien at aurel32 dot net 2007-05-16 11:08 ---
The problem is also present in gcc HEAD (SVN from today) built as a
cross-compiler on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
I'm getting the following ICE with gcc 4.2.0 RC3. It compiles fine
with gcc 4.1 and 4.3 20070515.
(sid)23889:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
freehdl-vital_timing.cc
freehdl-vital_timing.cc: In function 'array_typelong int delay(const
array_typelong int)':
--- Comment #1 from tbm at cyrius dot com 2007-05-16 11:26 ---
Created an attachment (id=13564)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13564action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
--- Comment #2 from tbm at cyrius dot com 2007-05-16 11:29 ---
Note that the testcases from PR30509 work fine with 4.2, so this appears to
be a different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
Keywords|
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following C++ program.
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following C program.
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-16 12:57
---
Subject: Bug 26998
Author: rguenth
Date: Wed May 16 11:57:09 2007
New Revision: 124767
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124767
Log:
2007-05-16 Richard Guenther [EMAIL PROTECTED]
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-05-16 13:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #71 from rguenth at gcc dot gnu dot org 2007-05-16 13:05
---
But it doesn't fix the POOMA miscompilations if I change its Pool allocator to
use placement new instead of this
// Release a block to the pool.
inline void free(void *b)
{
// Record a free.
With mainline as of a couple of days ago:
| gcc version 4.3.0 20070514 (experimental)
g++ -O2 -Wstrict-aliasing=3 -c t.cc
gives me this error:
| t.cc: In function int main():
| t.cc:11: internal compiler error: tree check: expected tree that contains
decl common structure, have
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2007-05-16 13:35
---
Reduced test case. Both tests also fail with current mainline (revision
124767M).
struct B {
~B();
};
struct A {
B* b;
virtual ~A() { delete[] b; }
};
A Op(void);
int main()
{
A a(Op());
return 0;
2nd call to partial_sort gives 'no match...' error, but 1st is OK.
Doesn't seem right.
#include algorithm
#include vector
templatetypename vector_t
struct Sort_Func2 {
vector_t const mag;
Sort_Func2 (vector_t const _mag) : mag (_mag) {}
bool operator() (int a, int b) const { return mag
--- Comment #5 from ian dot rogers at manchester dot ac dot uk 2007-05-16
14:01 ---
For the following code given in [1] GCC produces identical multiplication by
constant code [2]. I think as 0x0 is one of the parameters in this bug
the fact we generate identical multiplication
--- Comment #23 from manu at gcc dot gnu dot org 2007-05-16 14:03 ---
Hi Naimu, I am not speaking in the name of the GCC community but I would like
to prevent your frustration. You exposed your point clearly. People that have a
deep knowledge of C++ and g++ don't agree with you.
According to the C++ standard, clause 3.3.2, paragraph 2, sentence 3, the
following program should be invalid:
int
foo (int bar)
try
{
return 0;
}
catch (...)
{
int bar = 0; // invalid
return 1;
}
Specifically, `bar' may not be redeclared in the outermost block of a handler
in a function
--- Comment #1 from patrick dot olinet at gmail dot com 2007-05-16 14:23
---
Notice that this bug prevents loading and running java bytecode from a native
code binary compiled with gcj. I guess it relies on libffi to call the methods
of the bytecode.
This java problem is what I've
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-16 14:36
---
Subject: Bug 31725
Author: fxcoudert
Date: Wed May 16 13:36:03 2007
New Revision: 124769
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124769
Log:
PR fortran/31725
* trans-expr.c
This worked with 4.3.0 20070422 but fails now with 20070515:
(sid)23934:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 mc-view.i
view.c: In function 'toggle_hexedit_mode':
view.c:2045: internal compiler error: in set_value_range, at tree-vrp.c:305
Please submit a full bug report,
with
--- Comment #72 from rguenth at gcc dot gnu dot org 2007-05-16 14:49
---
inline void* operator new(unsigned long, void* __p) throw() { return __p; }
extern void bar();
float foo(double *p)
{
long *l = (long *)p;
*l = 1;
float *f = new (p) float;
*f = 0.0;
bar ();
return
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:01
---
Fixed on mainline and 4.2.1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #73 from rguenth at gcc dot gnu dot org 2007-05-16 15:02
---
For the following testcase, loop store motion re-orders the writes to *l and *f
at -O2. (Note as is, the testcase is only valid for n == 1)
inline void* operator new(unsigned long, void* __p) throw() { return
--- Comment #1 from tbm at cyrius dot com 2007-05-16 15:04 ---
Reduced testcase:
struct WView
{
int hexedit_mode:1;
};
toggle_hexedit_mode (struct WView *view)
{
if (view-hexedit_mode)
{
}
else
{
view-hexedit_mode = !view-hexedit_mode;
}
}
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
The following code works on gcc-4.1.2, but is rejected with gcc-4.2.0:
class ABC0
{
public:
virtual ~ABC0() = 0;
virtual int something() = 0;
};
inline ABC0::~ABC0()
{ }
struct C0;
struct ABC1 : public ABC0
{
explicit ABC1()
: ABC0()
{ }
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-16 15:24 ---
You are accessing memory of type structC via a pointer of type structB * which
violates C aliasing rules.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:34
---
On mainline, we currently require GMP = 4.1, for which this transformation is
safe (the mpz_get_ui inline function in gmp.h was corrected to avoid this
warning). Thus, simply removing these lines should work
--- Comment #74 from rguenth at gcc dot gnu dot org 2007-05-16 15:36
---
Note that another solution to this whole problem is to record conflicts for
all stored-to types that we cannot disambiguate by points-to analysis. This
also solves the reading of the standard that allows
int i
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 15:41 ---
Confirmed.
Index: tree-ssa-alias-warnings.c
===
--- tree-ssa-alias-warnings.c (revision 124763)
+++ tree-ssa-alias-warnings.c (working copy)
@@
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 15:43 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I hesitate to report this because it seems so obvious I must be wrong:
gcc-4.2.0/INSTALL only contains the README file (which says to look in
index.html). In previous tarballs, INSTALL contained the config/build/etc.
instructions as HTML files.
I haven't seen anything that would suggest that it
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:46
---
All I have access to is hppa2.0w-hp-hpux11.23, do you think it would be
triggered there also?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31833
The C++ standard, clauses 3.3.2 paragraph 4, and 6.4 paragraph 3, states that
names declared in the condition of `while', `if', `for' and `switch'
statements, may not be redeclared in any of the outermost controlled blocks.
This does work for `while' statements, however it does not work with
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-16 16:03 ---
Magically fixed itself.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2007-05-16 16:07
---
Your patch seems to fix the failure for both reduced test cases
as well as the original code. Thanks for the prompt response!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
$ configure --enable-languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as
$ make
leads to:
In file included from
.../obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/cctype:50,
from
.../gcc-4.2.0/libstdc++-v3/include/precompiled/stdc++.h:38:
I hesitate to report this because it seems so obvious I must be wrong:
gcc-4.2.0/INSTALL only contains the README file (which says to look in
index.html). In previous tarballs, INSTALL contained the config/build/etc.
instructions as HTML files.
I haven't seen anything that would suggest that it
--- Comment #4 from tbm at cyrius dot com 2007-05-16 16:39 ---
CCing Richi in case he didn't see the comment saying that his patch works.
--
tbm at cyrius dot com changed:
What|Removed |Added
4.3 ICEs during error recovery. This doesn't happen with 4.2.
(sid)24008:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 -Werror
btree.c
cc1: warnings being treated as errors
btree.c: In function 'bt_deref':
btree.c:20: error: passing argument 1 of 'vbt_deref' discards qualifiers
--- Comment #1 from tbm at cyrius dot com 2007-05-16 16:58 ---
struct btree_priv *area;
typedef struct bt_node_t
{
int next;
int used;
}
bt_leaf_t;
typedef union bt_page_t
{
bt_leaf_t leaf;
}
bt_page_t;
static inline bt_page_t *
vbt_deref (struct btree_priv *bt)
{
}
static inline
--- Comment #75 from rguenth at gcc dot gnu dot org 2007-05-16 17:08
---
In the chance of endlessly repeating myself here (;)) - what comment #73 boils
down to is that we may not prune alias sets of stores based on TBAA results.
In fact, we need to realize that C++ object lifetime
--- Comment #76 from ian at airs dot com 2007-05-16 18:01 ---
I don't believe that the C++ standards writers really meant to eliminate TBAA.
And that is the inevitable consequence of the dynamic memory type approach if
you are allowed to change the dynamic type in a function.
If we
When I create an object using copy constructor syntax, giving it other object
of that type and (crucial) the same name as the object just being
constructed... the compiler treats that other object as the object being
constructed(!) Similar effects I get with the builtin data types.
Below is the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 18:23 ---
I don't think this is a bug. C0 is not dependent so it has to be complete when
the new is parsed in the template.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31954
When I create an object using copy constructor syntax, giving it other object
of that type and (crucial) the same name as the object just being
constructed... the compiler treats that other object as the object being
constructed(!) Similar effects I get with the builtin data types.
Below is the
I just tried to compile Suse Linux package icecream-0.7.14a-5 with the GNU C
compiler version 4.3 snapshot 20070511
The compiler said
minilzo.c: In function '_lzo_config_check':
minilzo.c:2162: internal compiler error: tree check: expected tree that
contains 'decl common' structure, have
--- Comment #1 from dcb314 at hotmail dot com 2007-05-16 19:34 ---
Created an attachment (id=13565)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13565action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31962
This bug report is listed for the HTB i686-pc-linux-gnu but actually affects
ALL platforms.
The reason I chose to put this under the Component choice driver is because
there is no choice for documentation and it does involve renaming one of the
compiler command line options.
---
When I compile
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:43 ---
When I compile with --enable-checking=? the checking is performed on
stages 2,3 and the libraries - it is NOT performed on stage 1.
I filed a bug about this while back and it was fixed, see PR 29544.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 ---
*** Bug 31961 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31960
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 ---
*** This bug has been marked as a duplicate of 31960 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pbrook at gcc dot gnu dot org 2007-05-16 20:05 ---
Fixed.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01010.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 20:07 ---
*** This bug has been marked as a duplicate of 31950 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-16 20:07 ---
*** Bug 31962 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dorit at il dot ibm dot com 2007-05-16 20:45 ---
(In reply to comment #2)
Here is what happens in the three loops that don't get vectorized:
(1) the loop in testvectdp2:
...
so the vectorizer is ok, except that in this case D.1437_32 doesn't seem to
be used
--- Comment #1 from fang at csl dot cornell dot edu 2007-05-16 20:46
---
Poor man's workaround: -Wshadow -Werror
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 20:55 ---
This fixes it and much more besides. It needs commenting and tidying up.
Paul
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-16 20:56
---
I concur. If you want to forcibly delay the dependence on the complete type
until instantiation time, you could use a nested typedef in the class template,
like:
class NonDependent;
template class X
struct foo
--- Comment #6 from daney at gcc dot gnu dot org 2007-05-16 21:10 ---
Marking as FIXED as it now works for me *if* I use a current native GCC to
build the cross compiler.
I am prepering a documentation patch that explains my interpretation of the
requirements.
--
daney at gcc dot
--- Comment #2 from waldemar dot rachwal at googlemail dot com 2007-05-16
21:13 ---
Subject: Re: Premature hiding of symbols makes a copy constructor shooting at
its own foot
Hey,
Maybe I don't catch your process, but #31961 and #31960 both refer
to the same (identical) text of mine.
--- Comment #15 from dannysmith at users dot sourceforge dot net
2007-05-16 21:34 ---
(In reply to comment #13)
Subject: Re: Compile errors with multiple inheritance where
the stdcall attribute is applied to virtual functions.
rridge at csclub dot uwaterloo dot ca wrote:
--- Comment #9 from dtemirbulatov at gmail dot com 2007-05-16 22:47 ---
This patch fixes both testcases
--- gcc/varasm.c.orig 2007-05-16 21:32:11.0 +0400
+++ gcc/varasm.c2007-05-16 21:36:14.0 +0400
@@ -5762,12 +5762,14 @@ categorize_decl_for_section (tree
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:16 ---
This is not a bug, local classes cannot be template arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31951
If the third argument of ishftc equals BIT_SIZE of the first argument, the
result shall be the same as if the last argument was omitted.
program main
implicit none
integer aint
aint=1
write(*,*) BIT_SIZE(aint)
write(*,*) ishftc(aint,1)
write(*,*) ishftc(aint,1,32)
write(*,*)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:45 ---
*** This bug has been marked as a duplicate of 31955 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:45 ---
*** Bug 31958 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:49 ---
sqrt is part of glibc so report it there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from patchapp at dberlin dot org 2007-05-17 00:05 ---
Subject: Bug number PR c++/31745
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01091.html
--
--- Comment #77 from mark at codesourcery dot com 2007-05-17 00:41 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
I don't believe that the C++ standards writers really meant to eliminate
TBAA.
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 00:51 ---
What output were you expecting?
write(*,*) ishftc(aint,1)
write(*,*) ishftc(aint,1,32)
write(*,*) ishftc(aint,1,BIT_SIZE(aint))
All three of these statements are shifting the 32-bit representation of
of 1 to
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-17
01:30 ---
Subject: Re: FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above
All I have access to is hppa2.0w-hp-hpux11.23, do you think it would be
triggered there also?
Probably, since HP has pretty
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-17 01:30
---
$ gfc shifter.f90
$ ./a.out
32
2
1
1
$ ifort shifter.f90
$ ./a.out
32
2
2
2
$
--
jvdelisle at gcc dot gnu dot org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-17 01:49
---
I think we have an off by one when setting mask. I want to do some testing and
double check on all this. Here is a patch:
Index: ishftc.c
===
***
The macro _INTEGRAL_MAX_BITS is a defined as a builtin macro with an incorrect
value on mingw32. This Microsoft C specific macro is supposed to report the
maximum size (in bits) for an integral type. In GCC's case this would be 64,
the size of a long long, not 32 as it currently defines the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 02:42 ---
It was added with:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00979.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31965
--- Comment #49 from manu at gcc dot gnu dot org 2007-05-17 02:52 ---
(In reply to comment #48)
Created an attachment (id=13561)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13561action=view) [edit]
patch for testsuite infrastructure
This patch overrides dg-error and
--- Comment #2 from price at ifa dot hawaii dot edu 2007-05-17 03:19
---
This is also a problem on my amd64 Gentoo laptop, using gcc version Gentoo
4.1.1-r3.
I searched the binutils Bugzilla, but could not find a bug filed for this
problem.
Because the problem disappears when
--- Comment #2 from danglin at gcc dot gnu dot org 2007-05-17 03:55 ---
Test case also fails to compile on hppa64-hp-hpux11.11. Compiler
hangs in cse1 pass, apparently doing garbage collection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-17 04:00
---
The patch in comment #3 is incorrect. I have the correct patch coming and will
post to list for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
--- Comment #3 from ian at airs dot com 2007-05-17 05:02 ---
Created an attachment (id=13566)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13566action=view)
Proposed patch
I'm testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31953
--- Comment #7 from s__nakayama at infoseek dot jp 2007-05-17 06:04 ---
Fixed already in 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
95 matches
Mail list logo
