--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-21 08:37 ---
This patch should work but I cannot test it.
Index: config.host
===
--- config.host (revision 120891)
+++ config.host (working copy)
@@ -192,6 +192,7
Perfectly valid C++ syntax causes a compiler error when used inside a template
function. Both the Sun compiler and Microsoft compiler have no trouble with the
sample code shown below. Notice that the same code inside the non-template
function succeeds in compiling just fine. The GCC compiler
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-21 08:43 ---
You missed the typename keyword which is required to figure out if S sizeof(
func( var ) ) ::type is really a type or a variable.
Read also http://gcc.gnu.org/gcc-3.4/changes.html .
--
pinskia at gcc dot gnu
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-21 08:49 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-21 08:54 ---
I think this has been fixed already, for PPC with 4.0.2, we get:
_f:
mr r2,r3
addi r3,r3,1
cmpw cr7,r3,r4
bnelr cr7
addi r3,r2,2
blr
.align 2
.p2align
--- Comment #30 from pinskia at gcc dot gnu dot org 2007-01-21 08:58
---
GCC is not going to change. There is no reason why you can't either use
-fwrapv or change the security checks to be before the overflow happens. There
are now good reasons why -fwrapv is not on by default, if
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Status|UNCONFIRMED |WAITING
--- Comment #1 from paolo at gcc dot gnu dot org 2007-01-21 09:57 ---
Subject: Bug 30449
Author: paolo
Date: Sun Jan 21 09:57:42 2007
New Revision: 121027
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121027
Log:
2007-01-21 Paolo Carlini [EMAIL PROTECTED]
PR
The results should be consistent. g77
gets this right.
$ cat char-comparison.f
program main
character*2 c2
character*1 c1, c3, c4
C
C Comparison between char(255) and space padding
C
c2 = 'a' // char(255)
c1 = 'a'
print *, c2 .gt. c1
C
C Comparison between
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-21 11:31 ---
A signed issue in compare_string.
I'll also have to check front end constant folding for this...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-01-21 11:38 ---
(In reply to comment #0)
gcc with -Os -fno-PIC generates:
movb$38, (%ebx,%edx)# 45*movqi_1/7 [length = 4]
leal(%ebx,%edx), %eax # 122 *lea_1 [length = 3]
movb
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-01-21 11:43
---
This is a real MacOS bug. Using the Apple compiler I can reproduce it using the
following (on 10.4). I don't know if it should be kept open in the GCC bugzilla
(for a possible fixinclude patch) or if getting it
--- Comment #31 from andreas at andreas dot org 2007-01-21 12:23 ---
And who will go over the existing millions lines of code, and verify the
overflow checks everywhere? Or add -fwrapv to all the Makefiles for unaidited
code? Obviously not you. It seems to be easier to pretend you're
--- Comment #2 from joseph at codesourcery dot com 2007-01-21 12:28 ---
Subject: Re: bit-field: wrong overload resolution
On Sun, 21 Jan 2007, bangerth at dealii dot org wrote:
I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
those variables are promoted to
--- Comment #32 from andreas at andreas dot org 2007-01-21 12:49 ---
Oh, and besides, proper range analysis could optimize the above code, even in
the presence of correct (and I mean LIA-1) overflow behaviour of signed ints.
It seems you still didn't even manage to come up with an
--- Comment #33 from felix-gcc at fefe dot de 2007-01-21 13:53 ---
so now you give us... a straw man?
The range analysis has nothing to do with just assuming integers can't wrap.
But more to the point: the Intel compiler does not assume signed integers can't
wrap, and IT STILL PRODUCES
/usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:290:
error: expected ';' before 'throw'
/usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:292:
error: expected `;' before 'static'
--- Comment #1 from Christoph_vW at reactos dot org 2007-01-21 14:07
---
link to the sourcecode:
http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/network/telnet/
--
Christoph_vW at reactos dot org changed:
What|Removed |Added
It seems that I can use %k0 (rather than just %0) in an asm template to
force the (register) operand to long size (i.e. a value in %al referenced as
%k0 comes out as %eax in the generated assembly).
This doesn't seem to be documented anywhere. I presume there may be other such
character prefixes
--- Comment #1 from davmac at davmac dot org 2007-01-21 14:15 ---
I should add that I'm prepared to send a patch for the documentation if someone
will tell me what the operands are and what they do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
--- Comment #2 from Christoph_vW at reactos dot org 2007-01-21 14:26
---
Created an attachment (id=12926)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12926action=view)
keytrans.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30526
--- Comment #3 from Christoph_vW at reactos dot org 2007-01-21 14:30
---
with -v
mingw32-g++ -c base/applications/network/telnet/src/keytrans.cpp -o
obj-i386/base/applications/network/telnet/src/tkeydef.o
-Ibase/applications/network/telnet -D__USE_W32API -D__REACTOS__ -I. -Iinclude
--- Comment #4 from pcarlini at suse dot de 2007-01-21 15:13 ---
Already fixed in mainline... let's fix it in 4_2-branch too, then.
*** This bug has been marked as a duplicate of 29989 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #7 from pcarlini at suse dot de 2007-01-21 15:13 ---
*** Bug 30526 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-21 15:19 ---
Can we have this fixed in 4.2.0 as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
--- Comment #9 from pcarlini at suse dot de 2007-01-21 15:23 ---
(In reply to comment #8)
Can we have this fixed in 4.2.0 as well?
Just wait 10 mins... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
--- Comment #10 from paolo at gcc dot gnu dot org 2007-01-21 15:34 ---
Subject: Bug 29989
Author: paolo
Date: Sun Jan 21 15:34:16 2007
New Revision: 121029
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121029
Log:
2007-01-21 Paolo Carlini [EMAIL PROTECTED]
PR
--
pcarlini at suse dot de changed:
What|Removed |Added
Known to fail|4.1.2 4.2.0 |4.1.2
Target Milestone|4.3.0 |4.2.0
--- Comment #11 from paolo at gcc dot gnu dot org 2007-01-21 15:36 ---
Subject: Bug 29989
Author: paolo
Date: Sun Jan 21 15:36:27 2007
New Revision: 121030
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121030
Log:
2007-01-21 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #7 from patchapp at dberlin dot org 2007-01-21 16:01 ---
Subject: Bug number PR 23572
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-01/msg01730.html
--
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-21 16:12 ---
Subject: Bug 30511
Author: mueller
Date: Sun Jan 21 16:12:10 2007
New Revision: 121032
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121032
Log:
2007-01-21 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-21 16:16 ---
Subject: Bug 30015
Author: burnus
Date: Sun Jan 21 16:16:10 2007
New Revision: 121033
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121033
Log:
2006-12-09 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #34 from pinskia at gcc dot gnu dot org 2007-01-21 16:31
---
The range analysis has nothing to do with just assuming integers can't wrap.
Partly wrong, range analysis is helped by the fact assuming integers can't
wrap. If range analysis dependent on pointer overflow
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-21 16:37 ---
Every target have slightly different operand modifiers. They are usually
documented in config/*/*.md or config/*/*.c, but I think it is incorrect to
documented them for real because people will then abuse them.
--- Comment #7 from pcarlini at suse dot de 2007-01-21 16:39 ---
Benjamin, I'm noticing that the hard-coded path on top of the new
cxx_runtime_only_linkage.cc test doesn't play well with multilib and fails at
link-time, see, e.g., for unix/-m32 on x86_64-linux:
--- Comment #8 from mueller at gcc dot gnu dot org 2007-01-21 16:52 ---
Fixed for 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-21 17:24 ---
There is some initial support for this:
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9049
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-21 17:18 ---
Interesting -- I would not have thought of trying -ansi.
I wonder if this approach would really work for us.
I wonder sometime in the future -ansi will turn off other
GNU extensions that we use.
Andreas T. had seen
--- Comment #35 from andreas at andreas dot org 2007-01-21 17:29 ---
(In reply to comment #34)
The range analysis has nothing to do with just assuming integers can't wrap.
Partly wrong, range analysis is helped by the fact assuming integers can't
wrap.
And in those cases then leads
--- Comment #36 from felix-gcc at fefe dot de 2007-01-21 17:47 ---
I think the actual root issue here is that the gcc argumentation is
fundamentally wrong. I am complaining that gcc removes my checks, not that
signed integer overflow is undefined.
Also, note that it is everything BUT
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-21 17:47 ---
I was thinking about adding this to Wconversion. But perhaps it is more
appropriate for Wundefined. After all, the value may change or not depending on
the particular implementation, since it is undefined.
Gabriel,
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-01-21 18:02 ---
Here's a patch:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01726.html
Constant folding by the front end is OK, BTW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30525
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-21 18:08 ---
I am not sure this is such a good idea. A casting typically means I want to
really do this. GCC normally suppress warnings when casting is added. A
warning when you assign when enum type to another and the first enum
--- Comment #37 from pluto at agmk dot net 2007-01-21 18:16 ---
(In reply to comment #36)
Now, to summarize.
you're leading to undefined behaviour - do you understand this simple fact?
in such cases compiler can do *anything* with your code.
current behavior is bad for a lot of
--- Comment #7 from mrs at apple dot com 2007-01-21 18:19 ---
Yes, this is a bug, a fixincludes should be able to fix it, yes, that should be
done. At Apple, we use the fixincludes mechanism to build the SDK bits, so
that is eactly the right fix for us as well.
--
--- Comment #8 from mrs at apple dot com 2007-01-21 18:21 ---
radr://4944229
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
These lines cannot be compiled with gfortran (GNU Fortran 95 (GCC) 4.2.0
20070117 (prerelease)) on a Mac OS X 10.4 (powerpc):
INTEGER*2 IWD1
IWD1 = 32768
END
It fails with
IWD1 = 32768
1
Error: Arithmetic overflow converting INTEGER(4) to INTEGER(2) at (1)
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-21 18:24 ---
So, do we want to fix those testcases or do we want to keep ignoring empty
enums?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from Christoph_vW at reactos dot org 2007-01-21 18:42
---
Created an attachment (id=12927)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12927action=view)
Updated patch against the gcc-4_2-branch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
bash-3.1$ grep __dec_byte_swap libdecnumber/*.c gcc/config/dfp-bit.c
libdecnumber/decLibrary.c:uint32_t __dec_byte_swap (uint32_t);
libdecnumber/decLibrary.c:__dec_byte_swap (uint32_t in)
gcc/config/dfp-bit.c:extern unsigned long __dec_byte_swap (unsigned long);
long can be uint32_t on 64bit
dfp.c uses the sig field to store encoded value and only uses access
routines in libdecnumber to manipulate it so that dfp.c can be encoding
neutral. But there are
659 decimal128 *d128;
660 *r = *op0;
661 d128 = (decimal128 *) r-sig;
662 /* Flip high bit. */
663
--- Comment #1 from hjl at lucon dot org 2007-01-21 19:14 ---
I(In reply to comment #0)
bash-3.1$ grep __dec_byte_swap libdecnumber/*.c gcc/config/dfp-bit.c
libdecnumber/decLibrary.c:uint32_t __dec_byte_swap (uint32_t);
libdecnumber/decLibrary.c:__dec_byte_swap (uint32_t in)
--- Comment #2 from astrange at ithinksw dot com 2007-01-21 19:25 ---
Created an attachment (id=12928)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12928action=view)
example source code
Had a bit of browser trouble; here's the code.
--
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-01-21 19:46
---
(in reply to comment #35)
It is true that in the face of -fwrapv gcc does not optimize as good as it does
for unsigned numbers (that wrap, too). I am in the progress of fixing that
for the value range
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-21 20:11
---
The largest positive integer that can be represented by that kind type is
32767, so gfortran is correctly reporting an error.
Use -fno-range-check to bypass this.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #39 from pinskia at gcc dot gnu dot org 2007-01-21 20:14
---
No reason to keep this open as you are violating the C standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-21 20:14
---
First, it should be noted that it's not legal code. Indeed, you might (or not)
be surprised by the behaviour of the code in question:
pito /tmp $ cat a.f
INTEGER*2 IWD1
IWD1 = 32768
PRINT *,
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-21 20:41
---
What is the status on this now? After reviewing the standard I think I am in
agreement with what this patch does. The standard is not exactly straight
forward interpret.
Do we have consensus yet on this? If
The attached file produces the error:
[EMAIL PROTECTED] bugtest]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-20070117/configure --prefix=/usr/local/gcc42
--with-mpfr=/home/travel/GCC/BUILDS/mpfr
--with-gmp-lib=/home/travel/GCC/BUILDS/gmp/lib/
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-21 20:52 ---
Subject: Bug 30525
Author: tkoenig
Date: Sun Jan 21 20:51:53 2007
New Revision: 121035
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121035
Log:
2007-01-21 Thomas Koenig [EMAIL PROTECTED]
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30530
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|Gcc failed to bootstrap |[4.3
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-21 21:10 ---
I was wrong about this being tail called on PPC, though it should.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30493
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15082
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26560
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29686
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Runtime regressions with|[4.3 Regression] Runtime
|mem-ssa merge in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29534
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30472
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16306
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17789
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20077
--- Comment #40 from tromey at gcc dot gnu dot org 2007-01-21 21:52 ---
I've read through the comments in this PR.
I thought it would be useful to point out that a decision on how
GCC will optimize in the absence of -fwrapv will not be decided
by this PR. This change has been
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-21 21:52 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20285
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-21 21:56
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from hjl at lucon dot org 2007-01-21 21:56 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01743.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30530
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-21 21:56 ---
Actually, there is no attachment :-)
Could you send it, please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-21 21:57
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21343
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21659
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
--- Comment #4 from patchapp at dberlin dot org 2007-01-21 22:00 ---
Subject: Bug number PR30407
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-01/msg01744.html
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30332
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30425
1 - 100 of 164 matches
Mail list logo
