--- Comment #4 from hp at gcc dot gnu dot org 2009-06-18 05:49 ---
(In reply to comment #3)
> ... so this is actually a duplicate of bug 18501.
>
> *** This bug has been marked as a duplicate of 18501 ***
The loopness distinction for duplicate-marker seems bogus: PR22456 has a
while-lo
On Linux/ia64, I got
FAIL: gcc.dg/plugin/one_time-test-1.c -fplugin=./one_time_plugin.so (internal
compiler error)
FAIL: gcc.dg/plugin/one_time-test-1.c -fplugin=./one_time_plugin.so (test for
excess errors)
--
Summary: gcc.dg/plugin/one_time-test-1.c doesn't work on ia64
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-06-18 00:34 ---
Add documentation keyword
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Keywo
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-06-18 00:33 ---
Jonathan, you are right. These assertions are all backwards. I see this hitting
the following members:
load
store
compare_exchange_strong
I should have done tests for this, obviously. Ouch. Now you've done this for
m
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-06-18 00:00 ---
Agreed. Thanks for the feedback on docs. Will put this on the docs todo list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.3
Priority|P3 |P2
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.3
Priority|P3 |P2
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[4.4 regression] regressions|[4.4 Regression] r
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Priority|P3 |P2
http:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40405
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40204
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.5 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-17 21:01 ---
Fixed with the backports for PR39455, PR40087.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
http:
--- Comment #25 from sje at cup dot hp dot com 2009-06-17 20:37 ---
Micheal, are you still working on this bug? It looks like you had a patch for
it that you were testing but I don't see anything after that and the test is
still failing.
--
sje at cup dot hp dot com changed:
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-17 20:34 ---
(In reply to comment #4)
> Another testcase:
>
> [...@gnu-6 gcc]$ cat /tmp/pr40470-3.c
> #include
> __m128i load (char *);
> char *
> foo (char *p1, char *p2,
> int bmsk, __m128i mask1, __m128i mask2)
> {
>
--- Comment #5 from hjl dot tools at gmail dot com 2009-06-17 20:14 ---
I don't think there are fixed xmm0 in those insns in the IRA pass.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from hjl dot tools at gmail dot com 2009-06-17 20:01 ---
Another testcase:
[...@gnu-6 gcc]$ cat /tmp/pr40470-3.c
#include
__m128i load (char *);
char *
foo (char *p1, char *p2,
int bmsk, __m128i mask1, __m128i mask2)
{
int len = 0;
__m128i frag1, frag2;
int c
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-06-17 19:49
---
Fi-xed!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 19:48 ---
Still broken. Please fix ASAP.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-17 19:46 ---
*** This bug has been marked as a duplicate of 40061 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-17 19:46 ---
*** Bug 40477 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-06-17 19:46
---
Subject: Bug 40087
Author: rguenth
Date: Wed Jun 17 19:45:52 2009
New Revision: 148625
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148625
Log:
2009-06-17 Richard Guenther
Backport from mainl
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-06-17 19:46
---
Subject: Bug 39455
Author: rguenth
Date: Wed Jun 17 19:45:52 2009
New Revision: 148625
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148625
Log:
2009-06-17 Richard Guenther
Backport from mainl
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-06-17 19:46
---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-17 19:45
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from mikpe at it dot uu dot se 2009-06-17 18:51 ---
Dupe of PR40268/PR40061.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40477
Gcc 4.5.0 revision 148602 generates:
[...@gnu-6 intrin-1]$ cat y.c
#include
unsigned long long
foo1 (int x)
{
return _rdpmc (x);
}
[...@gnu-6 intrin-1]$ /export/build/gnu/gcc-intrin/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-intrin/build-x86_64-linux/gcc/ -O2 -S y.c -m32
[...@gnu-6 i
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-17 18:00 ---
char temp[strlen(oomDumpName) + 20];
sprintf(temp, "%s%03d", temp, GC_dump_count++);
I think it should rather be:
sprintf(temp, "%s%03d", oomDumpName, GC_dump_count++);
--
pinskia at gcc dot
I just had a look at the source file libjava/gnu/gcj/util/natGCInfo.cc
Around line 410 is the source code
sprintf(temp, "%s%03d", temp, GC_dump_count++);
It cannot be correct to read and write from the same buffer
at the same time. Suggest replace one use of temp with another
variable.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-17 17:49 ---
This only effects OS/2 support and nothing else. Please report this upstream.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I just had a look at the source file boehm-gc/os_dep.c
Around line 1103 is the source code
myexefile = fopen(path, "rb");
It appears there is no matching call to fclose and so
a resource leak occurs. Suggest add call to fclose.
--
Summary: boehm-gc/os_dep.c: Resource leak
--- Comment #9 from JonathanDBrandmeyer at eaton dot com 2009-06-17 17:16
---
Similarly, I would like the following to work as an extension to the anonymous
union support:
Given a structure like:
struct foo {
int a;
union {
int b;
float c;
};
--- Comment #4 from heydowns at borg dot com 2009-06-17 16:39 ---
Also observed on gcc 4.3.3
--
heydowns at borg dot com changed:
What|Removed |Added
Version|3
seen on the 4.3 branch
Matthias
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-st
--- Comment #20 from sje at cup dot hp dot com 2009-06-17 15:41 ---
I forgot to put the defect number in the ChangeLog entry but this is fixed with
r148614, a patch to expr.c.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-17
15:38 ---
Subject: Re: linux-eabi.h:79:36: error: identifier "not" is a special operator
name in C++
> > Could you specify which version of the source tree this was ?
>
> This is trunk, version 147956 or later. U
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-17 15:38 ---
This fails with gcc 4.5:
[...@gnu-6 gcc]$ cat /tmp/pr40470-1.c
#include
__m128i load (char *);
char *
foo (char *p1, char *p2,
int bmsk, __m128i mask1, __m128i mask2)
{
int len = 0;
__m128i frag1, frag2;
--- Comment #3 from joseph at codesourcery dot com 2009-06-17 15:34 ---
Subject: Re: -std=c99 does not enable c99 mode in Solaris
C library
On Wed, 17 Jun 2009, rguenth at gcc dot gnu dot org wrote:
> GCC 3.4.x is no longer maintained, please check GCC 4.3.x or newer.
It is a matter
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-17 15:24 ---
GCC 3.4.x is no longer maintained, please check GCC 4.3.x or newer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from heydowns at borg dot com 2009-06-17 15:13 ---
This also applies to Solaris x86.
Additionally, this only applies to Solaris 10 and later. Earlier versions of
Solaris did not ship c99-compliant C library and thus do not have the
values-xpg6.o object file for enabling c
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-06-17 15:12
---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-17 15:12
---
Back to P2. Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40468
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40342
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40341
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40181
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
--- Comment #3 from amodra at bigpond dot net dot au 2009-06-17 14:36
---
Created an attachment (id=18016)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18016&action=view)
patch proposal
Actually, it doesn't look all that hard to fix. The attached patch is a little
horrible in t
--- Comment #6 from joseph at codesourcery dot com 2009-06-17 14:28 ---
Subject: Re: gcc 4.3 no longer warns about missing newlines at
end of files (regression from 4.2)
On Wed, 17 Jun 2009, rlerallut at free dot fr wrote:
> And what happened to configuration flags ?
Configuration
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-17 14:24 ---
Created an attachment (id=18015)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18015&action=view)
Vectorizer dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-17 14:24 ---
Created an attachment (id=18014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18014&action=view)
Vectorizer dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-17 14:16 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01355.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #5 from rlerallut at free dot fr 2009-06-17 14:15 ---
(In reply to comment #4)
> Behavior being undefined means no requirement for a diagnostic, and the
> phase 1 mapping can introduce this newline in any case.
Allright, so if I develop my code with gcc 4.3, I have no way o
--- Comment #2 from mikpe at it dot uu dot se 2009-06-17 14:08 ---
(In reply to comment #1)
> Works for 4.4.1 and 4.5.0
ICEs for me with today's 4.4 branch on i686-linux. The -O0 -fstack-protector
combination is key, with -O1 and above it works, ditto without
-fstack-protector.
--
--- Comment #4 from joseph at codesourcery dot com 2009-06-17 13:59 ---
Subject: Re: gcc 4.3 no longer warns about missing newlines at
end of files (regression from 4.2)
On Wed, 17 Jun 2009, rlerallut at free dot fr wrote:
> (In reply to comment #2)
> > This is deliberate; see bug 14
--- Comment #35 from rguenth at gcc dot gnu dot org 2009-06-17 13:56
---
> The solution of moving the passes around has been discarded long ago. There
> are
> other possible solutions.
so, what are these? Once we removed the uninitialized use (CCP) we cannot
recover the information.
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-06-17 13:55
---
Huh. Well then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #3 from rlerallut at free dot fr 2009-06-17 13:51 ---
(In reply to comment #2)
> This is deliberate; see bug 14331.
Err... What happened to following the standard ?
"
If a source file that is not empty
does not end in a new-line character, or ends in a new-line ch
--- Comment #2 from joseph at codesourcery dot com 2009-06-17 13:35 ---
Subject: Re: New: gcc 4.3 no longer warns about missing newlines
at end of files (regression from 4.2)
On Wed, 17 Jun 2009, rlerallut at free dot fr wrote:
> When compiling a C or C++ program with gcc 4.3 (and 4
--- Comment #33 from manu at gcc dot gnu dot org 2009-06-17 13:25 ---
(In reply to comment #32)
> We can only fix it with the chance of raising more spurious warnings. One
> reason why we run the "may be used uninitialized" pass very late.
The solution of moving the passes around has b
--- Comment #2 from pinskia at gmail dot com 2009-06-17 13:12 ---
Subject: Re: -mno-sched-prolog breaks function parameter debug location lists
This option should just be removed.
Sent from my iPhone
On Jun 17, 2009, at 2:21 AM, "amodra at bigpond dot net dot au"
wrote:
>
>
> -
This option should just be removed.
Sent from my iPhone
On Jun 17, 2009, at 2:21 AM, "amodra at bigpond dot net dot au" > wrote:
--- Comment #1 from amodra at bigpond dot net dot au 2009-06-17
09:21 ---
See http://sourceware.org/bugzilla/show_bug.cgi?id=10231
--
http://gcc.g
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 13:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-17 13:06 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 13:06:21 2009
New Revision: 148610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148610
Log:
2009-06-17 Richard Guenther
PR middle-end/40404
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-17 13:04 ---
Note that the latest release of g95 gives now:
E
S, S
E
S, S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-17 13:02 ---
Works for me.
gcc-4.2 --version
gcc-4.2 (GCC) 4.2.4 (Debian 4.2.4-6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even fo
--- Comment #7 from aldyh at gcc dot gnu dot org 2009-06-17 13:00 ---
Fix for func-ptr-conv-1.c failure.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01344.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #32 from rguenth at gcc dot gnu dot org 2009-06-17 12:59
---
We can only fix it with the chance of raising more spurious warnings. One
reason why we run the "may be used uninitialized" pass very late.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-17 12:57 ---
> Without checking, I'd think that it doesn't hang, but would complete after a
> significant amount of time. My guess: the time is spent to traverse the list
> to
> append new elements to the constructor ...
You're
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-17 12:51 ---
C frontend issue.
The gimplfier is fed (*fp)(0) with fp of type void (*) (const int) but then,
after gimplifying foo we do patch fps type to void (*) (int):
Hardware watchpoint 4: *$2
Old value = (tree) 0xb7d4e230
--- Comment #30 from dominiq at lps dot ens dot fr 2009-06-17 12:48 ---
> Oh, so the first dump you attached (in comment #11) was for -m32. Now it
> makes sense.
Since I started to have some doubts about it, I redid it for both cases to be
sure.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #1 from irar at il dot ibm dot com 2009-06-17 12:46 ---
Could you please attach a vectorizer dump for one of them? I need to know what
prevented vectorization.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
$ cat test.c
struct R
{
char c;
}
struct R
{
struct R r;
}
int main(void)
{
struct R r;
return 0;
}
$ gcc test.c
test.c:7: error: redefinition of struct R
test.c:11: error: two or more data types in declaration specifiers
test.c:11: error: two or more data type
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:40
---
I have no plans for fixing the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #29 from irar at il dot ibm dot com 2009-06-17 12:40 ---
Oh, so the first dump you attached (in comment #11) was for -m32. Now it makes
sense.
I think, we have to distinguish between vect_no_align and the other cases. I
will prepare a patch tomorrow.
Thanks,
Ira
--
htt
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:38
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 12:37 ---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-17 12:37
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-06-17 12:35
---
WONTFIX for 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-06-17 12:34
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
On Linux/ia64, revision 148518 gave:
FAIL: gcc.dg/vect/vect-nest-cycle-1.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
FAIL: gcc.dg/vect/vect-nest-cycle-2.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
Revision 148510 is OK.
--
Summary: [4.5 Regression] gcc.dg/vect/ve
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-17 12:31 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 12:30:54 2009
New Revision: 148606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148606
Log:
2009-06-17 Richard Guenther
PR middle-end/40404
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 12:28 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 12:28:43 2009
New Revision: 148605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148605
Log:
2009-06-17 Richard Guenther
PR middle-end/40404
--- Comment #31 from manu at gcc dot gnu dot org 2009-06-17 12:17 ---
(In reply to comment #30)
> (In reply to comment #28)
> > We are not going to fix this.
> >
>
> Why? There are many ways to alleviate this. Doing some warnings in the
> front-ends, such LLVM does is one. Or propagate
--- Comment #28 from dominiq at lps dot ens dot fr 2009-06-17 12:12 ---
Does the following patch makes more sense for you:
--- ../_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-05
18:02:02.0 +0200
+++ gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-17 14:08:50.0 +0
--- Comment #30 from manu at gcc dot gnu dot org 2009-06-17 12:09 ---
(In reply to comment #28)
> We are not going to fix this.
>
Why? There are many ways to alleviate this. Doing some warnings in the
front-ends, such LLVM does is one. Or propagate some "uninitialized" bit, that
can ch
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:06
---
*** Bug 30542 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 12:06 ---
*** This bug has been marked as a duplicate of 18501 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:06
---
We are not going to fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:04
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #27 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
*** Bug 40469 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #3 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
... so this is actually a duplicate of bug 18501.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #27 from dominiq at lps dot ens dot fr 2009-06-17 12:03 ---
Created an attachment (id=18013)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18013&action=view)
dump file with -fdump-tree-vect-details -m64 for revision 148502.
Summary:
[karma] f90/bug% grep peeling vect-
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 12:03:08 2009
New Revision: 148604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148604
Log:
2009-06-17 Richard Guenther
PR middle-end/40389
1 - 100 of 136 matches
Mail list logo
