--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-19 07:00 ---
I think the gimplifier is broken though.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 06:35 ---
This regression is caused by
r126647 | fxcoudert | 2007-07-15 01:59:00 +0200 (So, 15 Jul 2007) | 7 lines
PR 32036
* trans-array.c (gfc_conv_array_ref): Only evaluate index once.
Without bounds check,
--- Comment #4 from cnstar9988 at gmail dot com 2007-07-19 07:03 ---
When I build gcc-4.2.1(prelease) on HPUX11.11, there is some warning..
why the share library build by GCC4.X on HPUX11.11 can't work..
some symbol required by the shared library could not be found.
But these works on
--- Comment #6 from jakub at gcc dot gnu dot org 2007-07-19 07:03 ---
Created an attachment (id=13938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13938&action=view)
gcc43-pr32338-3.patch
Testing showed I was wrong with the .body and we need duplicate .body
even when there was n
--- Comment #5 from cnstar9988 at gmail dot com 2007-07-19 07:05 ---
(In reply to comment #3)
> > It's known that -O2 contain "-fstrict-aliasing" which has bugs since gcc
> > 3.X.
> Huh?
from 4.2.1 status report.
PR 32182 -fstrict-aliasing ...
PR 32327 Incorrect stack sharing...
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-19 07:08 ---
(In reply to comment #2)
> I think the gimplifier is broken though.
I take that back, the function is called from the front-end so it is not the
gimplifier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
--- Comment #19 from cnstar9988 at gmail dot com 2007-07-19 07:17 ---
I have Modify $(GCC)/Makefile.in
LDFLAGS=-lpthread
BOOT_LDFLAGS=-lpthread
So build ok.
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-19 07:23 ---
Actually it turns out this is a middle-end issue with fold.
I am fixing this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-19 07:28 ---
And here is the patch which fixes the issue:
Index: fold-const.c
===
--- fold-const.c(revision 126739)
+++ fold-const.c(working copy)
@@
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-19 07:30 ---
Note also save_expr can be made better so we don't need to use a SAVE_EXPR for
local variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 08:30 ---
For the accept-invalid part (c_loc of an assumed-shape array). The standard
says:
"X shall either
(1) have interoperable type and type parameters and be
(a) a variable that has the TARGET attribute and is interope
Test case:
-
program test
implicit none
integer :: n
n = 1
write(*,'(''n'')') n
end program test
-
gfortran gives no compile-time error/warning, only the run-time error:
Fortran runtime error: Insufficient data descriptors in format after reversion
Expecte
I don't know whether this is possible to achieve, but simple PURE functions
should sometimes be inlined. Please consider:
$> cat inline.f90
MODULE foomod
TYPE foo
PRIVATE ! change to PUBLIC to run the "inlined" loop
INTEGER :: value
END TYPE
INTERFACE OPERATOR(==)
MODULE PROCEDURE
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-19 09:00 ---
I think this is just the normal inline function problem with gfortran. Where
we have two decls for the same function which causes no inlining to happen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-19 09:17 ---
Andrew, you mentioned the two-decl per function elsewhere as well. Where can
one learn more about this? why do we have two decls at all? where do they come
from, where do they go? How are they dealt with? I'm sort of
Everything works with GCC 4.2.1 but this is the real pain:
Trying to build Glibc from CVS redhat repo got this message:
../sysdeps/i386/i486/bits/string.h: Â ôóíêöèè __mempcpy_by2
../sysdeps/i386/i486/bits/string.h:755: îøèáêà: can't find a register in class
GENERAL_REGS while reloading asm
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
http:
from libstdc++-v3/docs/html/ext/pb_ds/hash_based_containers.html
There might be 2 errors in the "Hash Table Design" document as follows:
==
1st Error:
Section : Hash Table Design - Implementation - Probing Tables
Original text :
gp_hash_table is parametrized by Has
The below C code is a stripped down version of some code generated
by the GHC Haskell compiler. When it is compiled with -O, incorrect
code is generated. The Hp variable should live in %r7 but the compiled
routine does not set %r7. It does set it when -O is omitted.
I checked a few versions of
--- Comment #4 from rask at sygehus dot dk 2007-07-19 13:31 ---
Created an attachment (id=13939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13939&action=view)
Test case for frv-unknown-elf with -O2 -g -mcpu=fr400
It breaks on frv-unknown-elf as well:
Program received signal SI
#0 first_stmt (bb=0xb7fa75a0) at ../../gcc/gcc/tree-iterator.h:43
#1 0x0838d46e in dump_generic_bb (file=0x9785710, bb=0xb7fa75a0, indent=0,
flags=16448) at ../../gcc/gcc/tree-pretty-print.c:2909
#2 0x0831b8a7 in tree_dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at
../../gcc/gcc/tree-cfg.c:
--- Comment #1 from tehila at il dot ibm dot com 2007-07-19 13:38 ---
(In reply to comment #0)
> #0 first_stmt (bb=0xb7fa75a0) at ../../gcc/gcc/tree-iterator.h:43
> #1 0x0838d46e in dump_generic_bb (file=0x9785710, bb=0xb7fa75a0, indent=0,
> flags=16448) at ../../gcc/gcc/tree-pretty-pr
--- Comment #2 from tehila at il dot ibm dot com 2007-07-19 13:51 ---
(In reply to comment #1)
I've just tried to comment out the code:
if (dump_flags & TDF_DETAILS)
{
dump_bb (bb, dump_file, 0);
fprintf (dump_file, "\n");
}
from tree-cfg.c (at the beg
--- Comment #3 from ubizjak at gmail dot com 2007-07-19 13:56 ---
(In reply to comment #1)
> It fails while trying to delete a basic-block that is unnecessary after
> tree-if-conversion (on the dump command before the deletion).
No, it ICEs when empty BB is to be pretty-printed. A tree
--- Comment #4 from tehila at il dot ibm dot com 2007-07-19 14:15 ---
> No, it ICEs when empty BB is to be pretty-printed. A tree pretty-printer
> should
> be fixed/updated for this situation, this is all this PR is about.
Thanks for the quick response.
You're right, since the if-conve
+++ This bug was initially created as a clone of Bug #32819 +++
from libstdc++-v3/docs/html/ext/pb_ds/hash_based_containers.html
In the Bug #32819, I report 2 errors. But I found one more bug.
Section : Hash Table Design - Hash Policies - Ranged-Hash Functions
Original text :
Now assume that s i
el: posix
gcc version 4.3.0 20070719 (experimental)
--
Summary: internal compiler error: in gfc_trans_assignment_1
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 16:30 ---
In gfc_match_allocate
m = gfc_match_variable (&tail->expr, 0);
matches successfully, but it fails at:
if (gfc_match (" )%t") != MATCH_YES)
goto syntax;
As "i" is scalar, it does not seem to match the "(4)
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-19 16:38 ---
Confirmed. Reduced testcase:
$> cat pr32823.f90
integer(8) :: res(3)
res = int((/ 1.0, 2.0, 3.0 /), 8)
end
$> gfortran-svn pr32823.f90
pr32823.f90: In function 'MAIN__':
pr32823.f90:1: internal compiler error: in g
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-19 16:50
---
The IL representation is not a thing to complain about. Do you have a testcase
that shows a missed optimization instead of a one that has IL that is different
from what you expect?
--
rguenth at gcc dot gnu do
Testcase:
int a[16*100];
int e;
float f(void)
{
int i;
for(i = 0;i<16*100;i++)
e += a[i];
}
rt.c:7: note: not vectorized: unsupported use in stmt.
If I manually LIM'd e, then this is vectorized.
--
Summary: Missed reduction vectorizer after store to global is
Testcase (Compile at -O2 -maltivec -ftree-vectorize):
int a[16*100];
int f(int e)
{
int i;
for(i = 0;i<16*100;i++)
e += a[i];
return e;
}
- Cut -
Currently we get:
ivtmp.42 = (long unsigned int) &a;
vect_var_.36 = { 0, 0, 0, 0 };
:
vect_var_.36 = MEM[index: ivtmp.42] +
Testcase (compile at -O2 -maltivec -ftree-vectorize):
int a[16*100];
int e;
float f(void)
{
int i;
int e1;
e1 = e;
for(i = 0;i<16*100;i++)
e1 += a[i];
e = e1;
}
--- cut --
Currently you get:
stvewx v1,0,r2
lis r2,ha16(_e)
lwz r0,-20(r1) < LHS
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-19 17:15 ---
Note I copied the wrong testcase, the correct testcase is:
int a[16*100];
int e;
float f(void)
{
int i;
int e1;
e1 = 0;
for(i = 0;i<16*100;i++)
e1 += a[i];
e = e1;
}
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from manuelle at ee dot ethz dot ch 2007-07-19 17:51 ---
Created an attachment (id=13940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13940&action=view)
test cases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32791
--- Comment #3 from manuelle at ee dot ethz dot ch 2007-07-19 17:52 ---
hmm, I'm not sure if that is the same problem.
your testcase from bug 32810 does the right thing on x86.
in the attached file containing all three functions func1 and func3 produce the
same code, only code produced
--- Comment #4 from pinskia at gmail dot com 2007-07-19 17:56 ---
Subject: Re: missed optimization after inline functions with multiple return
statements
On 19 Jul 2007 17:52:14 -, manuelle at ee dot ethz dot ch
<[EMAIL PROTECTED]> wrote:
> your testcase from bug 32810 does the rig
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-19 18:07 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-19 18:08 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-19 18:09 ---
I think this is similar to PR19347?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-07-19 18:10
---
Mine. Caused by my recent intrinsic handling changes.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-19 18:14 ---
(In reply to comment #1)
> I think this is similar to PR19347?
It is not because LIM does its work, IR right before the vectorizer:
:
# ivtmp.31_17 = PHI
# e_lsm.30_1 = PHI
# i_14 = PHI
D.2248_4 = a[i_14];
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-19 18:15 ---
...
> Though the last add is extra and does not need to be done, we can get rid of
> it
> by having vect_var_.36 being set initially to {e, 0, 0, 0} .
The problem is that often initializing a vector to {e, 0, 0, 0} i
--- Comment #13 from zippel at gcc dot gnu dot org 2007-07-19 18:27 ---
The initial test case is part of the missed optimization. For example current
stable Debian gcc (4.1.2 20061115) produces code like this:
movl4(%esp), %eax
movl8(%esp), %edx
leal(
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-19 18:28 ---
ah, I misunderstood you - when you wrote before that you manually LIM'd e I
assumed it was because LIM didn't work. I see that the problem is with the
"garbage" that LIM leaves behind:
pr32824.c:6: note: Analyze phi:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-19 18:32 ---
> The problem is that often initializing a vector to {e, 0, 0, 0} is (much?)
> more
On SPU, it is not:
cwd $2,0($sp)
shufb $5,$3,$5,$2
vs:
ori $7,$3,0
il $5,0
...
--- Comment #2 from jhettmer at doprad dot com 2007-07-19 19:04 ---
Subject: Re: backslash zero no longer writes null in string
Thanks. Will do.
jvdelisle at gcc dot gnu dot org wrote:
> --- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-19 02:10
> ---
> This bug
--- Comment #2 from patchapp at dberlin dot org 2007-07-19 19:15 ---
Subject: Bug number PR 32804
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-07/msg01577.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from hjl at lucon dot org 2007-07-19 19:19 ---
Jan, we verified that your patch
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00538.html
caused this regression. Can you take a look? Thanks.
--
hjl at lucon dot org changed:
What|Removed
--
pcarlini at suse dot de changed:
What|Removed |Added
URL|http://gcc.gnu.org/onlinedoc|
|s/libstdc++/ext/pb_ds/hash_b|
|ased_c
--
pcarlini at suse dot de changed:
What|Removed |Added
URL|http://gcc.gnu.org/onlinedoc|
|s/libstdc++/ext/pb_ds/hash_b|
|ased_c
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-19 21:11 ---
Subject: Bug 32738
Author: dfranke
Date: Thu Jul 19 21:11:38 2007
New Revision: 126790
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126790
Log:
2007-07-19 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-19 21:12 ---
Assuming fixed. Added the testcase to the testsuite (r126790).
Closing as WORKSFORME.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
I created a program to invoke POSIX's gettimeofday using BIND(C) and
encountered
a compile-time problem. In searching the bug database, I discovered 30922,
which exhibited a similar problem (now fixed). I managed to recreate my
problem in a variant of the test program for 30922, so I am submittin
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1objplus-checksum.o differs
Bootstrap comparison failure!
./fortran/trans-array.o differs
./build/genattrtab.o differs
./omega.o differs
./tree-cfg.o di
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-19
23:49 ---
Subject: Re: New: Bootstrap comparison error -- VUSES info changed
For reference, I attached the difference in omega.o between stage
2 and 3.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-07-20 00:37 ---
Um, correction: fixed for C. The C++ frontend also has this problem.
Working on a patch.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
---
A very old report from v2.97 seems very similar, but had no infomation about
the cause - see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2034
Bootstrapping gcc fails with the error:
/home/brian/public/gnu/arm-elf/install.unix/arm-elf/bin/as: unrecognised option
`-Qy`
Where ...arm-elf/bin/as is a
--- Comment #1 from brian dot sidebotham at gmail dot com 2007-07-20 01:20
---
Created an attachment (id=13942)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13942&action=view)
Pre-processed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
shared library create by hppa64-hp11.11 can't run.
work ok on gcc-3.4.6,buit failed on gcc4.1.2/4.2.1.
some symbol required by the shared library could not be found.
--
Summary: shared library create by hppa64-hp11.11 can't run.
Product: gcc
Version: 4.2.1
build/gengtype
warning: structure `eh_range' used but not defined
warning: structure `jdeplist_s' used but not defined
warning: structure `java_lexer' used but not defined
warning: structure `ZipDirectory' used but not defined
warning: structure `VEC_cp_token_position_heap' used but not defined
war
--- Comment #1 from cnstar9988 at gmail dot com 2007-07-20 02:27 ---
insn-conditions.md > tmp-recog.c
../../gcc-4_2-branch/gcc/config/i386/i386.md:18885: warning: operand 1 missing
mode?
../../gcc-4_2-branch/gcc/config/i386/i386.md:18928: warning: operand 1 missing
mode?
/bin/sh ../../
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-20 02:34 ---
probably related to the gc bug we are chasing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32828
The following code shows the error...
#include
#include
#include
#include
#include
using namespace std;
class foo {
public:
vector bar (vector s) {
//nothing returned but g++ never complains
}
};
int main()
{
string strs[] = {"a", "b"};
foo f;
f.bar(vector(st
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32108
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27707
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27367
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
1 - 100 of 132 matches
Mail list logo
