--- Comment #1 from bunk at stusta dot de 2008-03-04 07:45 ---
Created an attachment (id=15258)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15258&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455
$ h8300-linux-gcc -Wp,-MD,fs/.read_write.o.d -nostdinc -isystem
/usr/local/DIR/gcc-h8300-4.3.0-RC-20080301/lib/gcc/h8300-elf/4.3.0/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -I/home/bunk/linux/kernel-2.6/git/linux
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-04 07:38
---
That's not an error-recovery issue. Reload prints the error via
fatal_insn ("Failure trying to reload:", set);
which outputs some data and calls fancy_abort. So that's just a disguised ICE.
--
reichelt at gcc
--- Comment #1 from bunk at stusta dot de 2008-03-04 07:19 ---
Created an attachment (id=15257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15257&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35454
This bug might be related to bug 32424 (why do you have a testsuite when
reports of ICEs when running it get completely ignored?), but I can't judge
whether it's really the same:
$ m68k-linux-gcc -Wp,-MD,fs/udf/.truncate.o.d -nostdinc -isystem
/usr/local/DIR/gcc-m68k-4.3.0-RC-20080301/lib/gcc/m68
--- Comment #16 from hubicka at ucw dot cz 2008-03-04 07:03 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
> Note however, that the patch also didn't help Geoff's i686-linux tester, just
> have a look to gcc-testresults.
Sorry, I had two versions of patch and managed to commit the
--- Comment #8 from bergner at gcc dot gnu dot org 2008-03-04 05:25 ---
Created an attachment (id=15256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15256&action=view)
Disallow TFmode and TDmode from reg+reg addressing
This ICE is similar to the one Nathan fixed which is caused
--- Comment #1 from proy at clg dot qc dot ca 2008-03-04 04:28 ---
For those interested: it might help to know that, on all g++ compilers that I
know of and that have this bug (at least from my understanding of the
situation), one could replace
template
class not_compilable
{
nmmintrin.h header file contains macros like
#define SIDD_XXX
These need to be named with a leading underscore, as in
#define _SIDD_XXX
since user may define SIDD_XXX.
--
Summary: nmmintrin.h defines macros SIDD_XXX
Product: gcc
Version: 4.4.0
Sta
When compiling program like following:
int
fn(int s) {
int i;
i = 2;
if (s)
i = 1;
if (s)
printf("%d\n", i);
return 0;
}
#cc1 -O2 -fdump-tree-vrp-all hello.c
There will be:
Jumps threaded: 1
Removing basic block 3
;; basic block 3, loop depth 0, count 0
;; prev block 7, next b
--- Comment #3 from mrs at apple dot com 2008-03-04 01:19 ---
My bug is related to this, but mine is an ice on valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
When bootstrapping for a new system based off of HLFS using:
Binutils 2.18
Glibc 2.7
Gcc 4.3.0-20080228 (checked out from gcc-4_3-branch)
The host os system for build is:
Binutils 2.17
Glibc 2.5
Gcc 4.1.2
Build order was:
pass 1 4.3.0 bootstrap toolchain with configure of:
--prefix=/tools \
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-04 00:58 ---
*** Bug 35450 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 2008-03-04 00:58 ---
*** This bug has been marked as a duplicate of 35405 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-04 00:56 ---
This was just filed in a different bugzilla recently too. I had it in a file
called t.cc and I started to paste this testcase there and I was, wait a minute
this is the same testcase.
--
http://gcc.gnu.org/bugz
#include
struct test_a{ void load(){} };
struct test_b{ };
template class Concept, typename Model>
struct models
{
typedef char (&yes)[2];
typedef char no;
template class C, typename M, typename C::type
P = 0>
struct hint
{ };
--- Comment #4 from akr at m17n dot org 2008-03-04 00:17 ---
The result can be representable by ptrdiff_t
because the result is number of longs.
The array is bit larger than 2**31 bytes.
So the result is bit larger than 2**29.
It is representable in signed.
--
http://gcc.gnu.org/bu
--- Comment #15 from pcarlini at suse dot de 2008-03-04 00:09 ---
(In reply to comment #14)
> Hi,
> this is what I get from our thester:
>
> Differences:
> Tests that now work, but didn't before:
> abi_check
>
> so it ought to make differnece for i686-linux.
Note however, that the pat
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-03 23:57 ---
ptrdiff_t is defined as a signed type so is the subtraction of two pointer
types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35427
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2008-03-03 23:51
---
Tobias noted the following also need updating:
3999: /* Fortran 2008 draft allows BIND(C) for internal procedures. */
4000- if (gfc_current_state () == COMP_CONTAINS
4001- && sym->ns->proc_name->at
In doc/extend.texi we have:
int foo ()
@{
int x = 42;
int *y = &x;
int result;
asm ("magic stuff accessing an 'int' pointed to by '%1'"
"=&d" (r) : "a" (y), "m" (*y));
return result;
@}
two problems, r != result. Second problem, there should be a : before the
output constraint.
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2008-03-03 23:46
---
Subject: Bug 33197
Author: fxcoudert
Date: Mon Mar 3 23:46:20 2008
New Revision: 132846
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132846
Log:
PR fortran/33197
gcc/fortran/
* intrins
--- Comment #14 from hubicka at ucw dot cz 2008-03-03 23:46 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
> Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
> machines I'm not seeing any progress :(
Hi,
this is what I get from our thester:
Differences:
Te
--- Comment #2 from akr at m17n dot org 2008-03-03 23:45 ---
(In reply to comment #1)
> nelem*sizeof(long)
>
> Wraps so what do you expect? This is the correct behavior really.
Oops. It wrapped.
But changing the type of nelem to size_t doesn't change the situation.
nelem * sizeof(l
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-03-03 23:26
---
(In reply to comment #5)
> Was it decided this is a platform specific library issue, not gfortran?
I think it's likely, but to be sure we need some more input. Dominique, could
you try to print out the values of
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-03 23:18 ---
I see the test failing on i686-mingw32, but it's more complicated than just
failing for the given warning.
The warning is given, and pruned by core DejaGnu's prune_warnings. This means
that { dg-require-effective-tar
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-03-03 23:04
---
I think that -ftrapv should not be considered blocking for this purpose.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rwild at gcc dot gnu dot org 2008-03-03 22:35 ---
Subject: Bug 33131
Author: rwild
Date: Mon Mar 3 22:35:13 2008
New Revision: 132844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132844
Log:
2008-03-03 Peter O'Gorman <[EMAIL PROTECTED]>
PR libgo
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35448
The following invalid code snippet triggers an ICE on mainline and the
4.3 branch:
==
void foo()
{
0.2r == 0.2hr;
}
==
bug.c: In function 'foo':
bug.c:3: sorry, unimplemented: GCC cannot support operators with integer types
and fixed-point types that have
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35447
The following invalid code snippet triggers an ICE since GCC 4.1.0:
==
void foo()
{
({ int i().; });
}
==
bug.c: In function 'i':
bug.c:3: error: expected declaration specifiers before '.' token
bug.c:3: error: expected declaration specifiers before '}' t
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35446
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
int a[2][2] = { [0 ... 1] = { ; } };
===
bug.c:1: error: expected expression before ';' token
bug.c:1: internal compiler error: in finish_init, a
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35445
The following invalid code snippet triggers an ICE since GCC 4.0.1:
===
extern int i;
extern int i;
int i[] = {};
===
bugI6.c:3: error: conflicting types for 'i'
bugI6.c:2: error: previous declaration of 'i' was here
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35444
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
void foo(int n, int a[n], int 0);
void bar() {}
===
bug.c:1: error: expected ';', ',' or ')' before numeric constant
bug.c:2: internal compiler e
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35441
Target Milestone|--- |4.1.3
http:/
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.1.0:
==
void foo()
{
({ int i; })();
}
==
#'bind_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35441
Target Milestone|--- |4.1.3
http:/
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.0.2:
==
typedef char A __attribute__((vector_size(8)));
typedef int B __attribute__((vector_size(8)));
void foo(A a)
{
((B)a)();
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35441
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.0.0:
void foo(char **p, char **q)
{
(p - q)();
}
With GCC 4.0.x we got
bug.c: In function 'foo':
bug.c:3: error: called object '#'exact_div_expr'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35440
The following invalid code snippet triggers an ICE since GCC 4.1.0:
struct A {};
void foo()
{
(struct A){}();
}
The compiler crashes trying to emit an error message, which results in a
completely broken diagnostic (e.g. file nam
--- Comment #19 from bugzilla-gcc at thewrittenword dot com 2008-03-03
21:12 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00162.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with "-fopenmp":
void x[1];
#pragma omp threadprivate(x)
bug.c:1: error: declaration of 'x' as array of voids
bug.c:2: internal compiler error: tree c
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with "-fopenmp":
void foo();
#pragma omp threadprivate(foo)
bug.c:2: internal compiler error: tree check: expected var_decl, have
function_decl in c_p
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35437
The following invalid code snippet triggers an ICE since GCC 4.0.0:
===
struct A
{
int i;
struct A a;
};
void foo()
{
struct A b = { 0 };
}
===
bug.c:4: error: field 'a' has incomplete type
bug.c: In function 'foo':
bug.c:9: internal compiler
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35436
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35435
The following (valid?) code snippet triggers an ICE since GCC 3.3:
==
typedef int X __attribute__((tls_model("initial-exec")));
==
bug.c:1: internal compiler error: tree check:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35434
The following invalid code snippet triggers an ICE since GCC 4.2.0:
===
typedef int i __attribute__((alias("j")));
===
bug.c:1: internal compiler error: in make_decl_rtl, at varasm.c:1267
Please submit a full
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-03 20:29
---
> This is caused by the vectorizer.
Indeed. The ICE appears also with "-ftrapv -O -ftree-vectorize".
(This still compiles fine on the 4.2 branch.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35433
The following (IMHO valid) code snippet triggers an ICE since GCC 4.1.0:
typedef int* X;
typedef int* Y;
X (*p)[][0];
Y (*q)[][0];
typeof(*(0 ? p : q)) x = { 0 };
bug.c:7: internal compiler error: Segmentation fault
Please submit
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35432
The following valid code snippet triggers an ICE since GCC 4.1.0:
struct A
{
char c[0];
};
void foo(struct A a)
{
(a = a).c;
}
bug.c: In function 'foo':
bug.c:8: internal compiler error: Segmentation fault
Please submit a full
--- Comment #1 from pinskia at gmail dot com 2008-03-03 20:14 ---
Subject: Re: New: [4.3/4.4 regression] ICE with "-ftrapv"
This is caused by the vectorizer.
Sent from my iPhone
On Mar 3, 2008, at 11:50, "reichelt at gcc dot gnu dot org"
<[EMAIL PROTECTED]
> wrote:
> The followin
This is caused by the vectorizer.
Sent from my iPhone
On Mar 3, 2008, at 11:50, "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
The following valid code snippet triggers an ICE on mainline and 4.3
branch
when compiled with "-ftrapv -O3"
-- Pinski
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35431
The following valid code snippet triggers an ICE since GCC 4.1.0 when compiled
with "-O2":
void bar();
void foo(int i)
{
__complex__ int k = 0;
if (i)
k = 1;
for (i = 0; i < 1; ++i)
;
if (k)
bar();
}
bug.c:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
The following valid code snippet triggers an ICE since GCC 4.0.0 when compiled
with "-W":
void foo(__complex__ int i)
{
i == 0u;
}
bug.c: In function 'foo':
bug.c:3: internal compiler error: tree check: expected integer_type or
e
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35429
The following valid code snippet triggers an ICE since GCC 4.1.0 when compiled
with "-O":
int foo(__complex__ int z0, __complex__ int z1)
{
return z0 != 0 || z1 != 0;
}
bug.c: In function '
--- Comment #1 from ubizjak at gmail dot com 2008-03-03 19:52 ---
You can put all arguments that use atoi() to this PR:
-mregparm=aaa, -mbranch-cost=foo, -mpreferred-stack-boundary=10^5, ...
Do we really need to fix this?
--
ubizjak at gmail dot com changed:
What|Re
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with "-ftrapv -O3":
void foo(int x[])
{
int i, j;
for (i = 0; i < 2; i++)
for (j = 0; j < 2; j++)
{
x[i] = x[i*j];
x[i] = x[i*j];
}
}
--- Comment #11 from steven at gcc dot gnu dot org 2008-03-03 19:35 ---
Quoting your insn once more:
(insn 58 57 59 6 gnu/java/nio/natVMSelector.cc:82 (parallel [
(set (reg:DI 4 si [165])
(mult:DI (zero_extend:DI (reg:SI 0 ax))
(zero_exten
--- Comment #13 from pcarlini at suse dot de 2008-03-03 19:04 ---
Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
machines I'm not seeing any progress :(
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from debian-gcc at lists dot debian dot org 2008-03-03
17:57 ---
an ecj update to 20080303 from the R3_3_maintenance branch doesn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-03 17:49 ---
nelem*sizeof(long)
Wraps so what do you expect? This is the correct behavior really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I found that an result of pointer subtraction in a big array is negative when
it is expected to be positive.
% cat t.i
typedef int ptrdiff_t;
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__));
extern void exit (int __status) __attribute__ ((__noreturn__)
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-03 17:02 ---
(In reply to comment #2)
> Oh, and both versions were built with mpfr 2.2.1, which configure told me was
> "buggy but acceptable" (if I remember the wording correctly) - is this my
> problem?
I think so. Can you tr
--- Comment #2 from lloyd at randombit dot net 2008-03-03 16:57 ---
Oh, and both versions were built with mpfr 2.2.1, which configure told me was
"buggy but acceptable" (if I remember the wording correctly) - is this my
problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
--- Comment #1 from lloyd at randombit dot net 2008-03-03 16:55 ---
Created an attachment (id=15255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15255&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
A simple C source fails with an ICE with 4.3.0 (the 20070907 and 20080228
snapshots) with optimizations (-O1/-O2/-Os -- I haven't narrowed it down to
which exact optimization though). This machine is x86-64 but the same assertion
occurs targeting both x86-64 (-m64) and x86 (-m32). Fedora Core 5 mac
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-03 16:37 ---
basic_endpoint()
: data_()
{
asio::detail::sockaddr_in4_type& data
= reinterpret_cast(data_);
data.sin_family = 2;
data.sin_port = 0;
data.sin_addr.s_addr = ((in_addr_t) 0x);
}
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-03 16:34 ---
No, we only confirm bugs once they have a reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35057
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-03
16:33 ---
Subject: Re: [4.3/4.4 Regression] EH output contains procedure label without
P' selector
The same fail occurs on hpux11 if I disable the use of secondary
definition symbols for one-only support.
Have test
--- Comment #3 from olafvdspek at gmail dot com 2008-03-03 16:30 ---
Hmm, should I change the status back to NEW manually?
--
olafvdspek at gmail dot com changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-03 16:29 ---
(In reply to comment #6)
> gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were
> applied.
yes and 3.4.x is no longer maintained (4.0.x likewise).
--
pinskia at gcc dot gnu dot org change
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-03-03 16:21
---
Subject: Bug 35262
Author: hubicka
Date: Mon Mar 3 16:20:31 2008
New Revision: 132838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132838
Log:
PR c++/35262
* ipa-inline.c (cgraph_decide_
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
--- Comment #8 from tprince at computer dot org 2008-03-03 16:20 ---
pr31341 has a patch attached to allow the test case to run on targets where
there is checking for conflicts with stdint.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #6 from tprince at computer dot org 2008-03-03 16:26 ---
gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were
applied.
--
tprince at computer dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
1 - 100 of 115 matches
Mail list logo
