--- Comment #4 from pault at gcc dot gnu dot org 2006-11-10 07:43 ---
Tobias,
This is fixed by the patch for PR fortran/29539 and PR fortran/29634. It will
be committed to 4.2 this weekend and to 4.1 as soon as I can.
I will close this PR when I do 4.2; I do not think that it necessar
--- Comment #1 from nmiell at comcast dot net 2006-11-10 06:59 ---
Created an attachment (id=12585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12585&action=view)
little C demonstration
This is a test function in C that demonstrate a case where gcc could be using
JrCXZ and isn't
The Test instruction applied to the rCX register followed by a Jump if Zero
with an 8-bit displacement can be replaced by a single JCXZ/JECXZ/JRCXZ
instruction with no loss of performance (1 cycle + 1 cycle verses 2 cycles on
K8 processors) and a one or two byte decrease in I-cache use per instance
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-10 04:47 ---
This is correct behavior according to the C++ standard. 23.1.1/13 only
references at() does bounds checking.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from acme at mandriva dot com 2006-11-10 03:20 ---
Created an attachment (id=12584)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12584&action=view)
Preprocessed sched.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
--- Comment #2 from acme at mandriva dot com 2006-11-10 03:19 ---
(In reply to comment #1)
> Can you supply a preprocessed source of sched.c and the options which you
> compiled it with?
>
Find the kernel/sched.i file attached, the options were these ones:
gcc -m32 -Wp,-MD,kernel/.sch
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-10 03:09 ---
Can you supply a preprocessed source of sched.c and the options which you
compiled it with?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
--- Comment #18 from fche at redhat dot com 2006-11-10 03:09 ---
For what it's worth, this problem does not appear to show up in current
mainline
gcc. If indeed it was caused by tree-ssa passes other than mudflap itself,
a backport of whatever is making it work now seems very unlikely.
I'm working on tools to use the DWARF information to do several things, such as
finding holes in structures, help in finding inline functions to uninline, etc,
the tools are available at this git repository:
http://www.kernel.org/git/?p=linux/kernel/git/acme/pahole.git;a=summary
One of the tools i
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2006-11-10
02:49 ---
A patch fixing this bug has been submitted to gcc-patches...
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00493.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-10 02:40 ---
Related to PR 26994.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepen
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-10 02:38 ---
Reduced testcase:
program gfcbug43
call try_fit (1)
call try_fit (1)
contains
subroutine try_fit (k)
call fit (1, debug=.true.)
end subroutine try_fit
subroutine fit (k, debug)
logical, intent(in),
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-10 02:09 ---
:;
if (&C.1125 != 0B) goto ; else goto ;
:;
D.1942_276 = C.1125;
if (D.1942_276) goto ; else goto ;
The address of a CONST_DECL can never be null.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-10 02:06 ---
(gdb) p t->common.ann->common.type
$4 = TREE_ANN_COMMON
(gdb) p debug_generic_expr (t)
C.1125
$5 = void
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-10 01:55 ---
> (it considers the shifts being of cost one)
depends on the target. On some targets (Cell), shifts with a constant shifter
is cheap (same as a normal add or subtract) while with a non constant one, it
is microcoded
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-10 01:09 ---
I am testing the fix right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28812
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-10 01:09 ---
I tried a C testcase but I could not get one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-10 01:06 ---
Confirmed, this is a bug in the complex lower pass.
Before:
D.1018_25 = D.1017_24 * __complex__ (0.0, 1.0e+0);
# PARM_NOALIAS.11_29 = V_MAY_DEF ;
(*sol.0_8)[D.1015_21] = D.1018_25;
After:
D.1018_25 = COMPL
--- 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
--- 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=gcc&view=rev&rev=118640
Log:
gcc/
* config/soft-fp/op-4.c, config/soft-fp/op-co
--- 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) = cmplx(0.0,1.0)*aimag(sol(1
--- 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 th
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-10 00:04 ---
#3 0x0054306e in internal_error (gmsgid=) at
/home/tob/projects/gcc/gcc/diagnostic.c:588
#4 0x007694bc in tree_check_failed (node=0x2ab6d3f46870, file=0xa424a0
"/home/tob/projects/gcc/gcc/tree-ssa.c"
--- 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
--- 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=gcc&view=rev&rev=118634
Log:
2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=118634
Log:
2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=118634
Log:
2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=118633
Log:
2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=118633
Log:
2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=118633
Log:
2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
--- 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 #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 #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
-
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 -O
--- 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.
--
echri
--- 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
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldot at gcc dot gnu dot org
Status|UNCONFIRMED
0061018 (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
--- 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 out-
--- 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 #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, h
--- 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=gcc&view=rev&rev=118631
Log:
2006-11-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29
--- 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 #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
--
http://gcc.gnu.org/bugzilla/sh
--- 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: gcc.
--- 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 suit
--- 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.
P
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; i> foo) & 1. Both require
two operations, but the latter can be done in one less insn
on mac
--- 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 cannot appear inside a , but the example I
mentioned is trying to show that it does. However, the formal syntax in the
ABI also say
--- 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? Re
--- 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
In mem-ssa, you have VDEF's of the
same symbol all over the place.
version of a symbol
--- 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 th
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 i
--- 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=12582&action=view)
Sample crashing gfortran at -O
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
--- 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=gcc&view=rev&rev=118629
Log:
2006-11-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29
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
--
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 n
--- 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=12581&action=view)
patch for reading and backspace
Here's the next installment of the patch, which seems to work
OK for backspace,
--- 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-m
--- 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=gcc&view=rev&rev=118627
Log:
2006-11-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29
--- 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
Status|UNCO
--- 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 th
--- 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
--
$ 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 #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
--- 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 approa
--- 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=gcc&view=rev&rev=118625
Log:
2006-11-09 Serge Belyshev <[EMAIL PROTECTED]>
PR middl
--- 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 parti
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
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))
matrix(1:n,1:n)
--- 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=gcc&view=rev&rev=118624
Log:
2006-11-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/2
--- 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=gcc&view=rev&rev=118624
Log:
2006-11-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29
--- 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 memo
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
use
--- 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 mem
--- 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 #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 #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 t
--- 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:
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
--- 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
--- 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=12580&action=view)
current software floating point patch
I am testing this patch now.
--
amylaar at gcc dot gnu dot org chan
--- 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 2006-11-0
Can you try the attached and let me know if it fixes it?
fordanglin.diff
Description: Binary data
--- 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
--- 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 part
--- 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 #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: g++.dg/opt/
--- 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=12578&action=view)
Call a function and disallow inlining it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
--- 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=12577&action=view)
Call a function and recommend to inline it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
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
static inline long long read_time(void) {
long long l;
asm
--- 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=12576&action=view)
Amended sched-deps.c patch
It occurend to me that the previous patch would not do the right thing when
the set
--- 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 #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).
>
>
6.c
> testsuite/gcc.dg/vect/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-
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic, ice-on-valid-
|
--- 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
--- 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
1 - 100 of 118 matches
Mail list logo
