--- Comment #9 from sebastian dot wenzler at hp dot com 2009-04-16 06:40
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.
Environment:
1) binutils/2.15 2) bison/1.875 3) automake/1.4-p5 4) gcc/4.2.4
The following program
CHARACTER(LEN=80) DATA
DATA=
OPEN(121245,FILE=/proc/self/statm,ACTION=READ,STATUS=OLD,ACCESS=STREAM)
DO I=1,80
READ(121245,END=999) DATA(I:I)
ENDDO
999 CLOSE(121245)
DATA(I:80)=
END
under valgrind leads to :
==29139==
--- Comment #1 from jv244 at cam dot ac dot uk 2009-04-16 07:31 ---
no valgrind errors with g95 or NAG.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:33
---
Created an attachment (id=17646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17646action=view)
Reduced testcase.
To be gnatchop-ed and compiled at -O.
--
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57
---
Richard,
the removal of
/* If the RHS of the MODIFY_EXPR may throw or make a nonlocal goto
and the LHS is a user variable, then we need to introduce a formal
temporary. This way the optimizers can
--- Comment #2 from bonzini at gnu dot org 2009-04-16 08:04 ---
Subject: Re: [cond-optab] CSE does not put subregs into
COMPAREs on many CC0 machines
Is this a cond-optab regression or just an observation?
Yes, it causes extra moves on code using unions. Where we have
--- Comment #30 from rguenther at suse dot de 2009-04-16 08:06 ---
Subject: Re: [4.5 regression] Revision 145338 breaks
ability to build Ada
On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57
--- Comment #1 from ubizjak at gmail dot com 2009-04-16 08:28 ---
Confirmed also on i686-pc-linux-gnu.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33
---
Do you happen to have a testcase?
Attached in the PR.
bb 22:
formal_24(ab) = p__proc_next (formal_6(ab));
goto bb 3;
# formal_7(ab) = PHI formal_9(ab)(2), formal_5(ab)(3), formal_5(ab)(4),
--- Comment #2 from ubizjak at gmail dot com 2009-04-16 08:35 ---
It doesn't fail for me on linux-mingw cross. Can you please provide the
backtrace?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #32 from rguenther at suse dot de 2009-04-16 08:45 ---
Subject: Re: [4.5 regression] Revision 145338 breaks
ability to build Ada
On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33
It is not possible to use -ftls-model to set the tls-model to global-dynamic
for code compiled without -fpic. Code compiled without -fpic uses initial-exec
or local-exec.
This makes it impossible to link code that uses tls and is compiled without
-fpic in shared libraries.
--
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2009-04-16 09:13
---
Ok, so we _do_ run lower_eh_constructs, but
formal = p__proc_next (formal);
returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow
the Ada testcase ... but I suppose the above
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 regression] Revision |[4.5 Regression] Revision
|145338 breaks ability
--- Comment #17 from nospamname at web dot de 2009-04-16 09:22 ---
I get same align problem on 68k amigaos Target.the rport and fix is old.
its a middle end bug and i see the fix is not in the source i download (4.3.3)
i can test this patch if you like, or have you something more new ?
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-04-16 10:45
---
Maybe fixed now (the reduced testcase is). Please re-open if not.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-04-16 08:59
---
And of course the testcase compiles fine with -fexceptions. Hmmm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-04-16 08:58
---
Ok, so we _do_ run lower_eh_constructs, but
formal = p__proc_next (formal);
returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow
the Ada testcase ... but I suppose the above function call
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-04-16 09:22
---
Created an attachment (id=17647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17647action=view)
patch
Ok, I think I see the issue. The attached patch should fix it (it does fix
the testcase). I am going
--- Comment #2 from irar at il dot ibm dot com 2009-04-16 10:26 ---
This patch fixes the type in pr34591.c (the vector type should be the type of
the reduction variable because we are looking for its initial value, and not
the type of the reduction statement, i.e., its RHS type):
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-16 11:29 ---
An example can be found in the following paper:
Norman S. Clerman: Note on creating an array of procedure pointers
ACM SIGPLAN Fortran Forum, Vol. 28, Issue 1 (2009)
http://doi.acm.org/10.1145/1520752.1520753
--
--- Comment #2 from ubizjak at gmail dot com 2009-04-16 11:37 ---
It looks that convert_modes has some issues. When expanding shift RTX,
convert_modes is called from
#0 convert_modes (mode=QImode, oldmode=QImode, x=0xb7d05fe8, unsignedp=0) at
../../gcc-svn/trunk/gcc/expr.c:769
#1
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-16 12:07 ---
I'm bootstrapping / testing the patch and will take care of committing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kuchen_ at gmx dot de 2009-04-16 12:00 ---
The backtrace from gcc? How do I get that? (It's not crashing, so it's hard to
find the point from which the backtrace should be generated...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #3 from ubizjak at gmail dot com 2009-04-16 12:26 ---
This testcase fails for all optimization levels:
--cut here--
/* { dg-do compile } */
/* { dg-options -w } */
int test (char v1)
{
v1 = 0xdebecced;
return v1;
}
--cut here--
Follwing patch fixes the failure, but
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-16 12:45 ---
Subject: Bug 39698
Author: rguenth
Date: Thu Apr 16 12:44:46 2009
New Revision: 146180
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146180
Log:
2009-04-16 Richard Guenther rguent...@suse.de
Ira
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-16 12:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-16 12:56 ---
seemingly works fine with 4.2.3
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Summary|[4.5/4.4/4.3 Regression] IO |[4.3/4.4/4.5 Regression] IO
|depends on uninitialised
--- Comment #4 from ubizjak at gmail dot com 2009-04-16 13:09 ---
(In reply to comment #3)
The backtrace from gcc? How do I get that? (It's not crashing, so it's hard to
find the point from which the backtrace should be generated...)
gdb /some/dir/cc1
(gdb) break fancy_abort
(gdb)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 13:52 ---
code in shared libraries have to be PIC code
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kuchen_ at gmx dot de 2009-04-16 14:01 ---
Thanks for help!
(gdb) run
Starting program: C:\osdev\kos/..\tools\gcc-4.3.3\i586-elf\bin\cc1.exe
-Iinclude
-Iinclude/arch/i386 -Ikernel/include -O3 -g -ffreestanding -Wall -o virt.o
ker
nel/mm/virt.c
[New thread
--- Comment #2 from tom dot aernoudt at coware dot com 2009-04-16 14:07
---
Aren't shared libraries that are compiled without -fPIC supposed to work on
x86?
On other platforms this may not work, but I thought that on x86 this is not
required.
--
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-16 14:16 ---
(In reply to comment #2)
Aren't shared libraries that are compiled without -fPIC supposed to work on
x86?
It is not supposed to work. It is happens to work. Now it happens not
to work for this combination.
--
--- Comment #5 from gcc at abeckmann dot de 2009-04-16 14:28 ---
It does compile successfully using 4.4.0 built with --enable-checking. Is there
anyting else to enable these tree checks?
$ x86_64-linux-gnu-g++-4.4.x -v -c PR39754.min.ii echo SUCCESS
Using built-in specs.
Target:
--- Comment #4 from tom dot aernoudt at coware dot com 2009-04-16 14:52
---
That may be true, but if it would be possible to tell gcc to use the
dynamic-global tls-model (or static-global) without specifying -fPIC it would
again 'happen' to work, even if tls is used.
I don't see a
--- Comment #2 from msieweke at broadcom dot com 2009-04-16 15:06 ---
As mentioned in the original report, the bug doesn't exist in GCC 4.x.x. It
has since been tested with GCC 3.4.4, where the bug is fixed.
GCC 3.2.x - broken
GCC 3.3.x - broken
GCC 3.4.x - fixed
GCC 4.x.x - fixed
For
--- Comment #2 from vmakarov at gcc dot gnu dot org 2009-04-16 15:16
---
Subject: Bug 39762
Author: vmakarov
Date: Thu Apr 16 15:15:48 2009
New Revision: 146198
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146198
Log:
2009-04-16 Vladimir Makarov vmaka...@redhat.com
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-04-16 15:42
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 15:43
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-16 15:43
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-04-16 15:44
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 15:44
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 15:44 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 15:44
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 15:45 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 15:48 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from sje at cup dot hp dot com 2009-04-16 15:48 ---
It looks like you already fixed it on the mainline, is there a reason the
patch can't be backported to the 4.3 branch and the defect closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-16 15:56 ---
Try bisecting the changes to cherry-pick the one fixing the bug.
Fixed in GCC 3.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 16:04 ---
Actually it is just better to check the tree code, testing the patch right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39365
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-16 16:07 ---
Fixed in 4.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-16 16:13 ---
This looks like better optimizations is causing a latent bug in the
selective-scheduling to show up.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aam at fastmail dot fm 2009-04-16 16:18 ---
export ABI=32
I used this to tell GMP and MPFR that I wanted 32-bit libraries, which GCC
4.3.3 seemed to need rather than the default of 64-bit libraries which causes
the GCC configure script to fail to detect the proper
--- Comment #36 from pinskia at gcc dot gnu dot org 2009-04-16 16:22
---
Fixed via Ira so marking as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 16:35
---
Fixed at least on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 16:50 ---
The testcase from comment #7 is correctly rejected but the testcase from
comment #0 is ICEing now which makes this a regression as 4.4.0 20090101
accepted it.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 16:53 ---
(In reply to comment #4)
But this is valid and is rejected by gcc but accpected by ICC:
This is now accepted on the trunk.
friend Sint::Sint(); is still rejected but I don't know if that is valid
or not.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-16 16:55 ---
Vlad, do you plan to commit to 4.4 branch as well?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-16 16:59 ---
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01249.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35423
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 17:02 ---
Fixed in at least 4.4.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from igodard at pacbell dot net 2009-04-16 17:02 ---
Wow! Six years and counting! This might be my oldest outstanding bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 17:03 ---
Mine to commit the testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-16 17:07 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 17:07 ---
Subject: Bug 28766
Author: pinskia
Date: Thu Apr 16 17:07:06 2009
New Revision: 146203
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146203
Log:
2009-04-16 Andrew Pinski pins...@gmail.com
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-16 17:08 ---
Fixed in at least 4.4.0.
Mine to commit the testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 17:16 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 17:16 ---
Subject: Bug 17570
Author: pinskia
Date: Thu Apr 16 17:15:59 2009
New Revision: 146206
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146206
Log:
2009-04-16 Andrew Pinski pins...@gmail.com
PR
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-16 17:31 ---
well, that was an inconvenient goose chase. (Note to self:
always check the Standard).
I'm tempted to close this with INVALID because the F95 Standard
explicitly states that SIZE() has a
Result Characteristics.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:22 ---
I think libstdc++ include pathes make the error message useless but if the
user code had the same walking back, I think the user would say this is more
useful message than what is recommended in comment #0 (at
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:24 ---
First there are a couple of issues here:
1) accepts invalid code:
using namespace std;
2)
foo.cc:3: error: ifstream does not name a type
Yes that should change if ifstream is not defined at all but we still
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-16 18:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:26 ---
foo.cc:6: error: std::ifstream was declared but not defined
This is even more confusing to me. As incomplete types are understood easier
than just being declared and not defined.
--
pinskia at gcc dot gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:28 ---
The problem is that GCC does not give an error
It can't give an error for that code as it is only runtime undefined and it
does not have to be invoked at runtime (i.e. the function is not called).
-- Pinski
--
--- Comment #2 from scottwood at freescale dot com 2009-04-16 18:30 ---
(In reply to comment #1)
The problem is that GCC does not give an error
It can't give an error for that code as it is only runtime undefined and it
does not have to be invoked at runtime (i.e. the function is
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 18:33 ---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 18:33
---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-04-16 18:33
---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-16 18:34
---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 18:34 ---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 18:37 ---
Confirmed:
==21080== Conditional jump or move depends on uninitialised value(s)
==21080==at 0x4BD8A78: finalize_transfer (transfer.c:3147)
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 18:45
---
stw %r3,RR'shrd.1301-$global$(%r1)
.CALL
bl GOMP_atomic_end,%r2
nop
.CALL
bl GOMP_barrier,%r2
nop
comib,= 4,%r3,L$0006
ldw -84(%r30),%r2
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-16
18:52 ---
Subject: Re: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
So r3 after the call to GOMP_barrier contains the old value of shrd which
seems
wrong.
Yes, I currently believe the
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 19:05
---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36892
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
It appears that qualified name lookup fails to find the correct candidate set
for overload resolution in the test case below.
For the following test case, the symptom is rejects-valid; however, it is
simple
to produce variants for wrong-code and accepts-invalid.
The Comeau online compiler
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
#include immintrin.h
#pragma GCC target (no-avx)
__m256d a, b, c;
__m128d d, e, f;
void __attribute__ ((__target__ (avx), __noinline__))
avx_routine (void)
{
a = _mm256_andnot_pd (b, c);
}
void __attribute__ ((__target__ (sse3), __noinline__))
sse3_routine (void)
{
d = _mm_andnot_pd (d,
--- Comment #9 from kargl at gcc dot gnu dot org 2009-04-16 19:27 ---
Sigh. Return this to an enhancement request with the
original Summary.
gfortran's behavior is correct.
(Note to self)**2: Never look at a bug report involving the
allocation of 16 GB of memory on a system limited
First, the problem. Sample program:
#include ctype.h
int main(void) { return 0; }
% g++ -c bug.cxx
In file included from
/opt/gcc--4.3.3--tru64/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.3.3/include-fixed/sys/localedef.h:76,
from /usr/include/ctype.h:108,
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 20:31 ---
Can you provide the preprocessed source? And the output of gcc -v?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39584
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-16 20:32 ---
You want to use the + constraint as output constraint.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39389
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 20:34 ---
*** This bug has been marked as a duplicate of 39182 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 20:34 ---
*** Bug 39389 has been marked as a duplicate of this bug. ***
--
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=39578
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 20:38 ---
*** Bug 39541 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 144 matches
Mail list logo