The patch that adds support for vectorization of multiple data-types
(http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00166.html) was missing a few
bits from the i386 port that rth contributed to autovect-branch a while back.
This is because a couple testcases were failing with these features:
The
--- Comment #19 from rsandifo at gcc dot gnu dot org 2006-11-09 09:34
---
Patch posted for review.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from brooks at gcc dot gnu dot org 2006-11-09 09:41 ---
-qkind= has been removed, and thus it no longer needs documentation.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from brooks at gcc dot gnu dot org 2006-11-09 09:48 ---
-fpreprocessed seems to be intended for internal use between gfortran and f951,
to indicate that the file has been preprocessed and the original filename
should be read from it. Thus, it should probably be set to
--- Comment #3 from schwab at suse dot de 2006-11-09 10:00 ---
And '\377' 0, so the warning is correct.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #17 from irar at il dot ibm dot com 2006-11-09 10:15 ---
I applied the patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html (a
fix for PR26197). The bootstrap with vectorization passes!
However, the failure in comment #3 still occurs in the later revisions. So, I
We need to port the ia64 support for vectorization of multiple-datatypes from
autovect-branch. This is the patch missing from mainline (wasn't included in
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00166.html cause I cauldn't test
this):
2005-12-02 Richard Henderson [EMAIL PROTECTED]
--- Comment #20 from rakdver at gcc dot gnu dot org 2006-11-09 11:16
---
I am playing with some ideas how to fix this, unless I come up with
something
soon, I will revert the patch (except for the testcase that I would like to
remain in the testsuite).
The best I was able to do is
Looks like sometime between Oct27
(http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01336.html)
and Oct30
(http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01538.html)
the fortran vectorizer testcases started ICEing on:
gfortran.dg/vect/vect-3.f90:0: warning: 'const' attribute directive
Hi,
When performing a cross-build (see the triplets I entered above), a file named
as gets created which gets used instead of the right assembler, thus breaking
the build.
Pls. note that I've entered the target triplets we're building (see
http://cegcc.sourceforge.net), this gcc build bug is
--- Comment #1 from valentin dot longchamp at gmail dot com 2006-11-09
12:15 ---
I'm the guy who asked him about the bug report.
The same happened to me with a armv6-angstrom-linux-gnueabi target (angstrom
is a openembedded based distribution).
I used the same fix (removing the as
--- Comment #44 from ebotcazou at gcc dot gnu dot org 2006-11-09 12:33
---
Things are still broken on hppa-linux.
I have a fix (in the linker) for the !HAVE_COMDAT_GROUP breakage on x86 but
it is probably not sufficient on hppa. Could you try it anyway? Just relink
the libstdc++.so
--- Comment #45 from ebotcazou at gcc dot gnu dot org 2006-11-09 12:34
---
Created an attachment (id=12575)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12575action=view)
Linker fix for !HAVE_COMDAT_GROUP breakage
Successfully tested on x86.
--
--- Comment #8 from sergstesh at yahoo dot com 2006-11-09 13:41 ---
I looked into source code of 'test_summary' script and it indeed calls
the 'Mail' program, the one with capital 'M'.
I have never heard of it, I am familiar with 'mail' with small 'm'.
On my system it's
lrwxrwxrwx 1
I've added the bug box and the code below. This code compiled fine with
previous versions of GNAT, and with -O2 or without -gnatVa.
gcc-4.1 -c -I./ -gnatVa -O3 iterate_moves.adb
+===GNAT BUG DETECTED==+
| 4.1.2 20061028 (prerelease) (Debian
--- Comment #6 from pmladek at suse dot cz 2006-11-09 14:16 ---
I still see the problem with gcj (GCC) 4.1.2 20061018 (prerelease) (SUSE
Linux).
It makes problems also with OpenOffice.org when the internally used hsqldb is
compiled and used with gcj/gij.
Note that it is really a bug.
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-09 14:29 ---
Subject: Bug 29713
Author: burnus
Date: Thu Nov 9 14:28:59 2006
New Revision: 118620
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118620
Log:
2006-11-09 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-09 14:38 ---
I checked this now into 4.2.
(I somehow thought it had already been checked in and was looking too long at
the wrong place to find this regression.)
Remains to be done for 4.1.
By the way as
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-11-09 15:06
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 11:16:12 -, rakdver at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #20 from rakdver at gcc dot gnu dot org
--- Comment #22 from dnovillo at redhat dot com 2006-11-09 15:08 ---
Subject: Re: [4.3 Regression] Misscompilation
of spec2006 gcc
Daniel Berlin wrote on 11/09/06 10:05:
One thing i'm going to try later is to try to partition all the
stores/load statements and figure out how many
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic, ice-on-valid-
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-09 15:17 ---
What version of GCC are you building?
This works for me with a non combined cross to powerpc64-linux-gnu for both
4.1 and 4.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
/vect-widen-mult-sum.c
But these files can be succesfully vectorized using current (gcc version 4.3.0
20061109) version on i686:
gcc -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all vect-widen-mult-sum.c
vect-widen-mult-sum.c:16: note: LOOP VECTORIZED.
vect-widen-mult-sum.c:12: note: vectorized 1
--- Comment #23 from hjl at lucon dot org 2006-11-09 15:47 ---
(In reply to comment #20)
I am playing with some ideas how to fix this, unless I come up with
something
soon, I will revert the patch (except for the testcase that I would like to
remain in the testsuite).
The
--- Comment #3 from danny dot backx at scarlet dot be 2006-11-09 16:02
---
dannypc: {9} arm-wince-cegcc-gcc -v
Using built-in specs.
Target: arm-wince-cegcc
Configured with:
/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc/configure
--prefix=/usr/ppc --enable-languages=c,c++
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-11-09 16:26 ---
Created an attachment (id=12576)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12576action=view)
Amended sched-deps.c patch
It occurend to me that the previous patch would not do the right thing when
the set
GCC sometimes does not inline code claiming the function has grown to large,
while inlining it would have _decreased_ the codesize.
For example, the following block of code, will result in read_time being
inlined:
#include stdio.h
static inline long long read_time(void) {
long long l;
--- Comment #1 from takis at issaris dot org 2006-11-09 16:31 ---
Created an attachment (id=12577)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12577action=view)
Call a function and recommend to inline it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
--- Comment #2 from takis at issaris dot org 2006-11-09 16:32 ---
Created an attachment (id=12578)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12578action=view)
Call a function and disallow inlining it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-11-09 16:33
---
(In reply to comment #8)
I don't see ICEs for the tls tests on my sh-elf build with
your patches in #6 and #7. Does the new patch in #7 fix them?
Yes, but I am still seeing these changes:
FAIL:
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-09 17:10 ---
It has a heuristic to tell the result in code-size difference. Of course no
heuristic is perfect - see tree-inline.c:estimate_num_insns().
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #24 from dberlin at gcc dot gnu dot org 2006-11-09 17:22
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 11/9/06, Diego Novillo [EMAIL PROTECTED] wrote:
Daniel Berlin wrote on 11/09/06 10:05:
One thing i'm going to try later is to try to partition
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-09 17:24 ---
Testing a fix for this one, though it only does the simple
*(int*)vector_int_var case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28436
Can you try the attached and let me know if it fixes it?
fordanglin.diff
Description: Binary data
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-11-09 17:24
---
Subject: Re: jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes
Can you try the attached and let me know if it fixes it?
--- Comment #12 from dberlin at gcc dot gnu dot org
--- Comment #11 from amylaar at gcc dot gnu dot org 2006-11-09 17:28
---
Created an attachment (id=12580)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12580action=view)
current software floating point patch
I am testing this patch now.
--
amylaar at gcc dot gnu dot org
--- Comment #4 from takis at issaris dot org 2006-11-09 17:28 ---
(In reply to comment #3)
It has a heuristic to tell the result in code-size difference. Of course no
heuristic is perfect - see tree-inline.c:estimate_num_insns().
Ofcourse! Thanks for your reply!
So, I guess that if
Currently, gfortran supports
integer = logical
and
logical = integer
with a default warning
Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1)
However, some compilers also support:
print '(i0)', logical
gfortran currently gives:
Fortran runtime error: Expected INTEGER for item 1
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-09 17:31 ---
Can you give your full testcase as right now the above testcases don't show
what your code looks like and why we are reaching the large-function-growth
limit.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #18 from janis187 at us dot ibm dot com 2006-11-09 17:34
---
Subject: Re: bootstrap comparision fails with -ftree-vectorize -maltivec on
ppc
On Thu, Nov 09, 2006 at 10:15:24AM -, irar at il dot ibm dot com wrote:
However, the failure in comment #3 still occurs in the
--- Comment #12 from amylaar at gcc dot gnu dot org 2006-11-09 17:37
---
(In reply to comment #8)
I don't see ICEs for the tls tests on my sh-elf build with
your patches in #6 and #7. Does the new patch in #7 fix them?
I've confirmed that the trunk bootstraps successfully with
--- Comment #25 from dnovillo at redhat dot com 2006-11-09 17:38 ---
Subject: Re: [4.3 Regression] Misscompilation
of spec2006 gcc
Daniel Berlin wrote on 11/09/06 12:22:
Right, but the difference is, In the scheme i propose, you'd never
have overlapping live ranges of vuse/vdefs,
--- Comment #26 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-09 18:03 ---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
Right, but the difference is, In the scheme i propose, you'd never
have overlapping live ranges of vuse/vdefs, and in
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
some VAR_DECL or structure that has a name (like our memory tags
do). A symbol is *not* a real variable that occurred in the user
program. When I say varaible i mean a variable that occurred in the
user
--- Comment #27 from dberlin at gcc dot gnu dot org 2006-11-09 18:21
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
some VAR_DECL or structure that has a name (like our
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-09 18:42 ---
Subject: Bug 29699
Author: pault
Date: Thu Nov 9 18:42:28 2006
New Revision: 118624
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118624
Log:
2006-11-09 Paul Thomas [EMAIL PROTECTED]
PR fortran/29699
--- Comment #16 from pault at gcc dot gnu dot org 2006-11-09 18:42 ---
Subject: Bug 21730
Author: pault
Date: Thu Nov 9 18:42:28 2006
New Revision: 118624
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118624
Log:
2006-11-09 Paul Thomas [EMAIL PROTECTED]
PR
POINTER Rank Remapping
(From http://www.fortran.bcs.org/forum2002/f2000dme.htm)
Motivation: ability to have pointers to diagonals of matrices.
REAL,ALLOCATABLE,TARGET :: base_array(:)
REAL,POINTER :: matrix(:,:)
REAL,POINTER :: diagonal(:)
...
ALLOCATE(base_array(n*n))
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #28 from dnovillo at gcc dot gnu dot org 2006-11-09 19:15
---
(In reply to comment #26)
I would very much like to see it compared with mem-ssa before mem-ssa
branch is merged.
Notice that the two approaches do not negate each other. Dan's proposal is a
smarter
--- Comment #4 from sayle at gcc dot gnu dot org 2006-11-09 19:24 ---
Subject: Bug 29726
Author: sayle
Date: Thu Nov 9 19:24:32 2006
New Revision: 118625
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118625
Log:
2006-11-09 Serge Belyshev [EMAIL PROTECTED]
PR
--- Comment #29 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-09 19:41 ---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
I would very much like to see it compared with mem-ssa before mem-ssa
branch is merged.
Notice that the two approaches
--- Comment #30 from dnovillo at gcc dot gnu dot org 2006-11-09 19:48
---
(In reply to comment #29)
nevertheless, it is not obvious to me whether using mem-ssa over Daniel's
proposal would bring any significant gains, which I would like to have
Of course. If you are interested in
$ cat equiv.hm.f
INTEGER i
PARAMETER (i = 55)
INTEGER o
INTEGER NUNITS(i)
equivalence (o,nunits(16))
data o/16/
data nunits(18)/18/
end
$ gfortran-4.3-HEAD -c -o /dev/null equiv.hm.f
equiv.hm.f:5:
equivalence
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2006-11-09
19:51 ---
fixed on trunk.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-09 20:04 ---
Dorit,
Nothing stands out in the gfortran patches in that interval, although I am not
sure what I am looking for. I base my remark on the fact that none of the
patches between 10/27 and 10/31 would appear to touch
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-09 20:14 ---
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-09 20:22 ---
Subject: Bug 29744
Author: pault
Date: Thu Nov 9 20:22:19 2006
New Revision: 118627
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118627
Log:
2006-11-09 Paul Thomas [EMAIL PROTECTED]
PR fortran/29744
--- Comment #2 from dorit at il dot ibm dot com 2006-11-09 20:26 ---
But these files can be succesfully vectorized using current (gcc version 4.3.0
20061109) version on i686:
gcc -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all vect-widen-mult-sum.c
vect-widen-mult-sum.c:16: note
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-11-09 20:43 ---
Created an attachment (id=12581)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12581action=view)
patch for reading and backspace
Here's the next installment of the patch, which seems to work
OK for backspace,
When you accessing vector element by negative index, nothing happens (but as i
think, the runtime error should happened). The glibc (double free()) happens
when destructor of the vector object called (at the end of the program). While
you haven't reached the vector object destructor, you can work
Hi,
the attached code compiles at -O0 but crashes gfortran
at -O or higher:
gfcbug43.f90: In function 'try_fit':
gfcbug43.f90:43: internal compiler error: in var_ann, at tree-flow-inline.h:130
(I tried to do my best, but I haven't been able to reduce
the example further.)
Cheers,
-ha
--
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-09 21:26 ---
Subject: Bug 29744
Author: pault
Date: Thu Nov 9 21:26:14 2006
New Revision: 118629
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118629
Log:
2006-11-09 Paul Thomas [EMAIL PROTECTED]
PR fortran/29744
--- Comment #1 from anlauf at gmx dot de 2006-11-09 21:27 ---
Created an attachment (id=12582)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12582action=view)
Sample crashing gfortran at -O
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
Memory SSA brings down the number of virtual operators to exactly one per
statement.
However, it does so in a way that makes the traditional things that
actually want to do cool memory optimizations, harder.
I'm still on the fence over whether it's a good idea or not.
verified before we
--- Comment #31 from dberlin at gcc dot gnu dot org 2006-11-09 21:28
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
Memory SSA brings down the number of virtual operators to exactly one per
statement.
However, it does so in a way that makes the traditional
In mem-ssa, you have VDEF's of the
same symbol all over the place.
version of a symbol
--- Comment #32 from dberlin at gcc dot gnu dot org 2006-11-09 21:29
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
In mem-ssa, you have VDEF's of the
same symbol all over the place.
version of a symbol
--
--- Comment #33 from dnovillo at redhat dot com 2006-11-09 21:48 ---
Subject: Re: [4.3 Regression] Misscompilation
of spec2006 gcc
dberlin at dberlin dot org wrote on 11/09/06 16:28:
Uh, LIM and store sinking are too. Roughly all of our memory
optimizations are.
They are?
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-11-09 21:49 ---
There is a contradiction here in the ABI. The formal syntax in the ABI says
that a local-name cannot appear inside a nested-name, but the example I
mentioned is trying to show that it does. However, the formal
In SPEC 2k6 libquantum we can find the following (simplified) hot loop
void
quantum_toffoli(int control1, int control2, int target, unsigned long *state,
int size)
{
int i;
for(i=0; isize; i++)
{
if (state[i] ((unsigned long) 1 control1))
if (state[i] ((unsigned long)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-09 22:07 ---
If the fold transformation is disabled we can force lim to move the shifts out
of the loop by specifying --param lim-expensive=1 (it considers the shifts
being of cost one). The default of the param is 20 though.
--- Comment #2 from sergstesh at yahoo dot com 2006-11-09 22:30 ---
After using 'make -k check' I see much more failures that reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
, i.e. in my environment gcc-4.1.1 test suite produces much more failures
than gcc-3.4.6 test
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-09 22:38 ---
FAIL: gcc.dg/cleanup-10.c execution test
FAIL: gcc.dg/cleanup-11.c execution test
FAIL: gcc.dg/cleanup-8.c execution test
FAIL: gcc.dg/cleanup-9.c execution test
These above are caused by a bug in glibc.
FAIL:
--- Comment #5 from patchapp at dberlin dot org 2006-11-09 22:40 ---
Subject: Bug number PR29315
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/2006-11/msg00582.html
--
--- Comment #13 from kkojima at gcc dot gnu dot org 2006-11-09 22:42
---
I've tested the patch in #9 with the trunk (rev. 118619) and
got the same ICE in #2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-09 22:49 ---
Subject: Bug 29431
Author: pault
Date: Thu Nov 9 22:49:12 2006
New Revision: 118631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118631
Log:
2006-11-09 Paul Thomas [EMAIL PROTECTED]
PR fortran/29431
--- Comment #4 from sergstesh at yahoo dot com 2006-11-09 23:01 ---
Thanks for your reply.
Regarding
FAIL: g++.old-deja/g++.law/weak.C (test for excess errors)
Unknown and you should look into g++.log.
- you probably meant gcc/testsuite/g++/g++.log.sent file.
If it's the case,
--- Comment #8 from brooks at gcc dot gnu dot org 2006-11-09 23:17 ---
Fixed on 4.2: svn 118628.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fang at csl dot cornell dot edu 2006-11-09 23:37
---
If you want bounds checking on std::vector, use the at() member function in
place of operator[].
Otherwise, the overloaded operator[] is unchecked and just does a plain
indexed-array reference.
(If it is
(experimental)
4.3.0 20061109 (experimental) gives
Breakpoint 1, var_ann (t=0xa7d911b8) at
../../../src/gcc-4.3/gcc/tree-flow-inline.h:130
130 gcc_assert (!t-common.ann || t-common.ann-common.type == VAR_ANN);
(gdb) p *t-common.ann
$9 = {common = {type = VAR_ANN, aux = 0x0, value_handle = 0x0
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldot at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-09 23:47 ---
This was a bug in cctools.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from echristo at apple dot com 2006-11-09 23:49 ---
I'm going to mark this down as wontfix since I just added a port for
ppc64-darwin and we don't need the file since the issue that caused
host-darwin.c in the rs6000 backend to be created was fixed with tiger.
--
This is on x86_64-unknown-linux-gnu-gcc with
GNU Fortran 95 (GCC) 4.3.0 20061109
r118621 2006-11-09 15:42:19 +0100
(since the anoynmous SVN does not work, I'm a bit hampered with testing. Using
gfortran 4.2 it does not crash.)
The error only occurs with -O2 but not with -O1:
gfortran -O2 -c
--- Comment #5 from echristo at apple dot com 2006-11-09 23:51 ---
This appears to work with the change to add powerpc64-darwin support.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #2 from echristo at apple dot com 2006-11-09 23:53 ---
This appears fixed with the changes to add powerpc64-darwin support.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #2 from echristo at apple dot com 2006-11-09 23:54 ---
I'd like you to retest this one with the new support I added for
powerpc64-darwin.
thanks.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #3 from echristo at gcc dot gnu dot org 2006-11-09 23:57
---
Subject: Bug 27814
Author: echristo
Date: Thu Nov 9 23:56:57 2006
New Revision: 118633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118633
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR
--- Comment #5 from echristo at gcc dot gnu dot org 2006-11-09 23:57
---
Subject: Bug 28994
Author: echristo
Date: Thu Nov 9 23:56:57 2006
New Revision: 118633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118633
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR
--- Comment #6 from echristo at gcc dot gnu dot org 2006-11-09 23:57
---
Subject: Bug 26892
Author: echristo
Date: Thu Nov 9 23:56:57 2006
New Revision: 118633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118633
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR
--- Comment #4 from echristo at gcc dot gnu dot org 2006-11-10 00:02
---
Subject: Bug 27814
Author: echristo
Date: Fri Nov 10 00:02:21 2006
New Revision: 118634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118634
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR
--- Comment #7 from echristo at gcc dot gnu dot org 2006-11-10 00:02
---
Subject: Bug 26892
Author: echristo
Date: Fri Nov 10 00:02:21 2006
New Revision: 118634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118634
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR
--- Comment #6 from echristo at gcc dot gnu dot org 2006-11-10 00:02
---
Subject: Bug 28994
Author: echristo
Date: Fri Nov 10 00:02:21 2006
New Revision: 118634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118634
Log:
2006-11-09 Eric Christopher [EMAIL PROTECTED]
PR
--- Comment #34 from dberlin at gcc dot gnu dot org 2006-11-10 00:03
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 21:48:25 -, dnovillo at redhat dot com
[EMAIL PROTECTED] wrote:
--- Comment #33 from dnovillo at redhat dot com 2006-11-09
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-10 00:04 ---
#3 0x0054306e in internal_error (gmsgid=value optimized out) at
/home/tob/projects/gcc/gcc/diagnostic.c:588
#4 0x007694bc in tree_check_failed (node=0x2ab6d3f46870, file=0xa424a0
--- Comment #35 from dberlin at gcc dot gnu dot org 2006-11-10 00:12
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
Take the above case.
If we simply use virtual variable versions to value number memory, we
will believe that *a and *b are possible stores to the
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-10 00:14 ---
Slightly more reduced test case:
subroutine zsk_driver_cgnr (opt, sol)
implicit none
interface
subroutine opt()
end subroutine opt
end interface
complex :: sol(:)
sol(1) =
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-11-10 00:18 ---
Subject: Bug 2749
Author: jsm28
Date: Fri Nov 10 00:17:54 2006
New Revision: 118640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118640
Log:
gcc/
* config/soft-fp/op-4.c,
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-10 00:19
---
Proposed patch: http://gcc.gnu.org/ml/fortran/2006-11/msg00285.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
1 - 100 of 118 matches
Mail list logo
