--- Comment #5 from linuxl4 at sohu dot com 2009-04-22 06:44 ---
of cource it is not difficult to reorder the source .
I don't know any compiler can do this, I wish there are a outsmart one.
--
linuxl4 at sohu dot com changed:
What|Removed |Added
--- Comment #4 from linuxl4 at sohu dot com 2009-04-22 06:37 ---
in my opiton of view ,
at the time a USE statement is processed, the public portions of the specified
module shall be available.
should not been think as about the order of units, since "This standard places
no ordering r
--- Comment #3 from kargl at gcc dot gnu dot org 2009-04-22 05:52 ---
(In reply to comment #2)
> no quite.
> but the std post on limitation on this , so I really hope gfortran support it.
>
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f4ab93c7cece56ee/d4518a39
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-22 05:27 ---
Since PR 39846 is closed, I copy its info here. This bug isn't
specific to a particular target. When trunk is configured with
--enable-checking=assert, I get
../../src/gcc/c-typeck.c: In function âbuild_function_c
--- Comment #1 from hp at gcc dot gnu dot org 2009-04-22 05:18 ---
*** Bug 39846 has been marked as a duplicate of this bug. ***
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from hp at gcc dot gnu dot org 2009-04-22 05:18 ---
*** This bug has been marked as a duplicate of 39845 ***
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
When trunk is configured with --enable-checking=assert, I get
../../src/gcc/c-typeck.c: In function âbuild_function_call_vecâ:
../../src/gcc/c-typeck.c:2433: internal compiler error: in make_decl_rtl, at
varasm.c:1304
Please submit a full bug report,
with preprocessed source if appropriate.
Se
--- Comment #2 from linuxl4 at sohu dot com 2009-04-22 04:32 ---
no quite.
but the std post on limitation on this , so I really hope gfortran support it.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f4ab93c7cece56ee/d4518a395a0fd4fe?hl=zh-CN#d4518a395a0fd4fe
to
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P3 |P5
http:/
--- Comment #1 from kargl at gcc dot gnu dot org 2009-04-22 03:35 ---
Are you sure? The module after must be available when
"use after" has been reached. Can you cite the relevant
part of the standard that supports your claim.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39844
With revision 146515 this test passed.
>From revision 146517 and on, this test has failed as follows:
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
FAIL: gcc.c-torture/compile/981006-1.c -O2 (internal compiler error)
FAIL: gcc.c-torture/compile/981006-1.c
program main
use after
end program main
module after
end module after
this is allowed by the standard, I hope gfortran support this.
--
Summary: module whole-file checking disabled
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity
--- Comment #23 from galtgendo at o2 dot pl 2009-04-22 01:15 ---
comment 22 was of course about '-fno-guess-branch-probability',
not the other one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
--- Comment #22 from galtgendo at o2 dot pl 2009-04-22 01:08 ---
Well, gcc 4.4.0 works without '-fno-inline-small-functions' for
freeciv too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
--- Comment #21 from galtgendo at o2 dot pl 2009-04-22 00:23 ---
Well, with 4.4.0 id.c compiles correctly in both cases.
Let's check the harder part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
--- Comment #20 from galtgendo at o2 dot pl 2009-04-22 00:04 ---
Created an attachment (id=17669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17669&action=view)
prepocessed source of id.c
People, I've got a result, that's either very funny or very not funny.
With the same compil
% gcc-snapshot --version
gcc-snapshot (Ubuntu 20081013-0ubuntu2) 4.3.3 20081014 (prerelease)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% gc
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-04-21 22:48
---
*** Bug 39842 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 22:48 ---
This code is invalid as you are using a non constant argument for an template
argument.
*** This bug has been marked as a duplicate of 37093 ***
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #1 from gccbug at isomer dot meta dot net dot nz 2009-04-21
22:43 ---
File is too large to attach directly (~1.2MB), test case instead added to the
URL field as suggested by Bugzilla.
--
gccbug at isomer dot meta dot net dot nz changed:
What|Removed
While compiling some heavily templated code using member variable pointers, g++
crashes. g++ is standard version installed with ubuntu hardy.
Changing line 49159 of js.ii from (self->*func)(a1, a2, a3); to
self->*func(a1, a2, a3); removes the ICE (however due to an (unresolved) bug in
my progra
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 22:28 ---
(In reply to comment #1)
> Probably all six excess precision tests should have explicit -mfpmath=387.
Yes and I will test this on Darwin and GNU/Linux.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-21 21:56 ---
Created an attachment (id=17668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17668&action=view)
An eample
Here is an example for gcc 4.4. If function level optimization works,
we don't need separate files fo
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 21:53 ---
The reasoning behind signed char not giving a warning is because in C/C++, char
can either be unsigned or signed depending on the target so the warning is only
for char and not for the specific marked signed characte
I appreciate the fact that gcc is able to warn about misuse of macros
when they are written as an array access, when the programmer mistakenly uses
'char' (under -fsigned-char) instead of the standard-mandated int containing an
unsigned char value (there is discussion right now on the newlib list
--- Comment #2 from jbglaw at lug-owl dot de 2009-04-21 21:32 ---
This is SVN trunk, fetched via GIT. With my last build, it was SVN rev 146349
which produces the warnings. At this point I also just realize that it might be
a nice thing to actually print out the array bounds as well as t
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-21
21:01 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
> At present glibc does not create an long double alias for the double __signbit
> function, but for the s
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-21 20:34 ---
Created an attachment (id=17667)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17667&action=view)
An example
I am enclosing a modified example which can be compiled with both
icc and gcc. I also included assem
--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-21 20:27
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #4 from paolo at gcc dot gnu dot org 2009-04-21 20:27 ---
Subject: Bug 39802
Author: paolo
Date: Tue Apr 21 20:26:46 2009
New Revision: 146538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146538
Log:
2009-04-21 Paolo Carlini
PR libstdc++/39802
*
--- Comment #11 from carlos at codesourcery dot com 2009-04-21 20:16
---
Yes, if gcc does not determine that "sizeof (x) == sizeof (double)" then it
would have to emit code for the if-then-else statement and this would create a
reference to an undefined __signbitl. Has this ever happene
--- Comment #14 from manu at gcc dot gnu dot org 2009-04-21 19:53 ---
I am going to mark this as FIXED for GCC 4.5.
A possible enhancement could be to mention which qualifiers are casted away.
However, this is not trivial and the warning already mentions the types, so
perhaps it is unne
--- Comment #4 from drepper at redhat dot com 2009-04-21 19:51 ---
(In reply to comment #3)
> Gcc 4.4 and above supports different target options on the function
> level but not on a basic block level. So you can create an interneral
> version for AVX.
This doesn't work either. Asi
--- Comment #13 from manu at gcc dot gnu dot org 2009-04-21 19:49 ---
Subject: Bug 35711
Author: manu
Date: Tue Apr 21 19:49:23 2009
New Revision: 146537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146537
Log:
2009-04-21 Manuel Lopez-Ibanez
PR c++/35711
cp/
--- Comment #10 from danglin at gcc dot gnu dot org 2009-04-21 19:49
---
Gcc always seems to optimize the signbit macro.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
--- Comment #3 from pinskia at gmail dot com 2009-04-21 19:41 ---
Subject: Re: Non-optimal (or wrong) implementation of SSE intrinsics
Gcc 4.4 and above supports different target options on the function
level but not on a basic block level. So you can create an interneral
version f
Gcc 4.4 and above supports different target options on the function
level but not on a basic block level. So you can create an interneral
version for AVX.
Sent from my iPhone
On Apr 21, 2009, at 12:37 PM, "drepper at redhat dot com" > wrote:
--- Comment #2 from drepper at redhat dot
--- Comment #2 from drepper at redhat dot com 2009-04-21 19:37 ---
[I couldn't attach the code as an attachment, bugzilla has a bug.]
The program below has to be compiled with -mavx to allow the AVX intrinsics
being used. But this also triggers using the use of the vmovss instruction t
--- Comment #4 from floris dot bruynooghe at gmail dot com 2009-04-21
19:22 ---
Sure, that's why you should always use it together with --enable-new-dtags when
using GNU ld so you get a RUNPATH (note that for Solaris ld this is not needed,
you get a RUNPATH automatically if you use -R t
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-21 19:07 ---
Please provide some sample code which can be compiled.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
The implementations of the SSE intrinsics for x86 and x86-64 in gcc is tied to
the use of an appropriate -m option, such as -mssse3 or -mavx. This is
different from what icc does and it prevents code from being written in the
most natural form. This is nothing new in gcc 4.4, it has been the beha
--- Comment #2 from alexvod at google dot com 2009-04-21 18:37 ---
(In reply to comment #1)
> This is IV-opts messing way up as far as I can tell. Pointer Plus just helped
> out PRE and code motion passes which confuses the hell out of IV-opts.
>
I tried to use -fno-ivopts flag, but it
The following code:
struct S
{
int count;
char *addr;
};
void func(const char*, const char*, int, const char*);
void test(struct S *p)
{
int off = p->count;
while (p->count >= 0)
{
const char *s = "xyz";
if (*p->addr) s = "pqr";
func("abcde", p->addr + off, off, s);
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-21 18:24 ---
Well RPATH cannot be overridden by ld.so which is the biggest reason why it is
bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
--- Comment #2 from floris dot bruynooghe at gmail dot com 2009-04-21
18:23 ---
Could you refer to documentation that explains what to use instead then? The
manpage for ld does not say anything about --rpath being a bad way (the default
behaviour of GNU ld of only adding RPATH and requ
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-21 18:14 ---
As mentioned this is just going to break more things than it can help.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 18:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 18:07 ---
Oh because constant folding of asin, we remove the reference to asin so no
debugging info for asin is going to be emitted because there is no call left
for asin. Maybe -fbuiltins should not be enabled at -O0.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 18:03 ---
unlikely should be a define to __builtin_expect .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39810
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 18:02 ---
This warning is correct but incorrect as this code can never be invoked unless
there is a huge bug inside GCC but GCC's warning system does not know that.
What version of GCC are you using to build the cross compile
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 18:00 ---
new_var_hash should be changed to use DECL_UID since we know that these are all
going to be decls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39806
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 17:59 ---
I think neither of these cases should be warned about since you are using it
with a statement expression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 17:56 ---
This is IV-opts messing way up as far as I can tell. Pointer Plus just helped
out PRE and code motion passes which confuses the hell out of IV-opts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838
The following code:
struct A
{
int count;
int *data;
};
void func(int, int);
void test (struct A* p, const void **ptrArray, int count)
{
int i, j;
for (i = 0; i < p->count; i++)
{
for (j = 0; j < count; j++)
{
func (p->data[i], p->data[i + 1]);
}
}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39778
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 17:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 17:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-debug
Summary|Bad Dwarf debug information |[4.3 Regr
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 17:42 ---
Here is one reduced testcase (an seg fault);
typedef double __m256d __attribute__ ((__vector_size__ (32) ));
static inline __m256d __attribute__((__always_inline__)) c(){}
#pragma GCC target ("no-avx")
__m256d a, b;
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-21
17:28 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
> > I believe the problem is the symbol was exported when it shouldn't have
> > been.
>
> How?
This is p
--- Comment #6 from jakub at gcc dot gnu dot org 2009-04-21 17:23 ---
Created an attachment (id=17666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17666&action=view)
gcc44-pr39794.patch
Updated patch that successfully bootstrapped/regtested on x86_64-linux on 4.4
branch.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 17:22 ---
It also ICEs at -O0 on the trunk:
Either:
t.c: In function avx_routine:
t.c:11: internal compiler error: in emit_move_insn, at expr.c:3386
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 17:20 ---
This is not a bug in GCC, this is a feature. LD_RUN_PATH/-rpath are broken
really. They cannot be used for relocating libraries.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 17:15 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-21 17:07 ---
So it is using stack space instead of r3 for something that is alive across the
function call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
--- Comment #19 from laurent at guerby dot net 2009-04-21 17:05 ---
I believe current binutils is very near to have this issue fixed, I'm pinging
on the binutils bugzilla.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
--- Comment #1 from sje at cup dot hp dot com 2009-04-21 16:58 ---
There is a patch for one of the failures (no-vfa-vect-43.c at
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01653.html
--
sje at cup dot hp dot com changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-21 16:49 ---
mov r5, r4
add r5, r5, #8
.L2:
ldr r2, [r4, #8]
mov r1, r5
Wait, r4+8 is the same as r5 here so loop invariant should have used it.
--
pinskia at gcc dot gnu dot org c
--- Comment #2 from alexvod at google dot com 2009-04-21 16:47 ---
Created an attachment (id=17665)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17665&action=view)
gcc-rev123919.regr.c.139r.loop2_invariant
A dump of loop2_invariant phase from gcc rev123919
--
http://gcc.gnu.
--- Comment #1 from alexvod at google dot com 2009-04-21 16:45 ---
Created an attachment (id=17664)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17664&action=view)
gcc-rev123918.regr.c.139r.loop2_invariant
A dump of loop2_invariant phase with gcc rev123918
--
http://gcc.gnu.
The following code
struct Glob
{
int f1, f2;
int x;
};
extern struct Glob g;
int func(int, int*, int);
void test()
{
int a = 0;
int* b = &g.x;
do
{
a = *b;
}
while (func(a, b, a) != 0);
}
// compilation options: -march=armv5te -fpic -mthumb-interwork -mthumb -Os
is compi
--- Comment #18 from rearnsha at gcc dot gnu dot org 2009-04-21 16:40
---
(In reply to comment #14)
> Something like that? (untested)
>
> Index: configure.ac
> ===
> --- configure.ac(revision 143046)
> +++ configur
--
bonzini at gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.1 |4.3.4
Version|4.4.0 |4.3.3
http://gcc.gnu.
--- Comment #1 from alexvod at google dot com 2009-04-21 16:08 ---
Compilation options: -march=armv5te -fpic -mthumb-interwork -Os -mthumb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38878
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38671
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38293
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38059
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38036
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37942
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
1 - 100 of 176 matches
Mail list logo
