--- Comment #1 from janus at gcc dot gnu dot org 2010-02-25 08:38 ---
Confirmed. Here is a reduced test case:
pure subroutine swap(x)
implicit none
type :: myType
real :: a
end type myType
class(myType), intent(inout) :: x
select type(x)
class is
--- Comment #2 from janus at gcc dot gnu dot org 2010-02-25 09:08 ---
The problem lies in gfc_impure_variable (resolve.c), where it is checked if the
namespace of the variable equals the local namespace of the pure procedure.
This check fails if the procedure has sub-namespaces.
We
--- Comment #3 from janus at gcc dot gnu dot org 2010-02-25 09:13 ---
Regarding BLOCK, it seems there is an additional problem: Assignments inside a
BLOCK are not checked at all, as the following case shows ...
implicit none
real :: glob
contains
pure subroutine swap
--- Comment #4 from janus at gcc dot gnu dot org 2010-02-25 09:19 ---
Contained procedures are not affected by this bug, since a procedure contained
in a pure procedure must itself be pure. Therefore something like this is
invalid (as gfortran correctly detects):
module m
implicit
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-25 10:42 ---
Subject: Bug 43165
Author: jakub
Date: Thu Feb 25 10:41:52 2010
New Revision: 157062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157062
Log:
PR debug/43165
* cfgexpand.c (expand_debug_expr):
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-25 10:50 ---
Subject: Bug 43166
Author: jakub
Date: Thu Feb 25 10:50:24 2010
New Revision: 157063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157063
Log:
PR debug/43166
* cfgexpand.c (expand_debug_expr)
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-25 10:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-25 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
I am not 100% sure whether this is a duplicate of any of the other
missed-optimization PRs; it may well be. Currently, gfortran generates a
temporary for:
subroutine one()
REAL, ALLOCATABLE :: kpts(:,:)
REAL, POINTER :: syp(:,:)
kpts = syp
end subroutine one
However, kpts cannot
Related to some other missed-optimization PRs, but particularly simple.
REAL, allocatable :: ot(:)
integer :: time_steps
call foo (ot) ! OK, no temporary
call foo (ot(0:5:1)) ! Unnecessary temporary
call foo (ot(0:time_steps)) ! Unnecessary temporary
end
Note: ot is contiguous (as
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-25 11:56 ---
Joseph, would you approve a patch for this?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-02-25 12:16 ---
(In reply to comment #3)
Seems like statements inside a BLOCK are not being resolved at all?!?
Sorry, this is wrong. They are resolved alright. The problem is just that
'gfc_pure' does not work (checking if we're
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-25 12:23 ---
Seems this is related to DEBUG_EXPR_DECL temporaries. If I manually merge all
the 3 DEBUG_INSNs into one, the VLA bound artificial var is set to (nil) after
the di = di + 1 increment similarly to i (the enhancement
--- Comment #1 from pault at gcc dot gnu dot org 2010-02-25 12:42 ---
symbol.c:gfc_symbols_could_alias is the source of this extra temporary (called
by trans-array.c:gfc_could_be_alias and before that
gfc_conv_resolve_dependencies).
I am reading section 12.6 of Adams, Brainerd,
--- Comment #1 from pault at gcc dot gnu dot org 2010-02-25 12:48 ---
This does not occur on i386. I will try on a x86_64 tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43173
--- Comment #4 from paul dot richard dot thomas at gmail dot com
2010-02-25 12:50 ---
Subject: Re: Memory leaks in allocatable component
expressions
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-25 07:38
---
Paul, can you try with valgrind
--- Comment #6 from janus at gcc dot gnu dot org 2010-02-25 12:54 ---
(In reply to comment #2)
The problem lies in gfc_impure_variable (resolve.c), where it is checked if
the
namespace of the variable equals the local namespace of the pure procedure.
This check fails if the
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-25 12:56 ---
(In reply to comment #1)
This does not occur on i386. I will try on a x86_64 tonight.
The warning for -Warray-temporaries is shown here for both -m32 and -m64 -- and
I also see _gfortran_internal_pack in the
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-02-25 13:07 ---
Mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-25 13:21 ---
(In reply to comment #1)
In principle,
subroutine foo (ptr, tar)
real, target :: tar (:,:)
real, pointer :: ptr (:,:)
ptr = tar
end subroutine
could cause troubles in 'one' in the testcase. If I read
--- Comment #7 from janus at gcc dot gnu dot org 2010-02-25 13:40 ---
(In reply to comment #5)
(In reply to comment #3)
Seems like statements inside a BLOCK are not being resolved at all?!?
Sorry, this is wrong. They are resolved alright. The problem is just that
'gfc_pure' does
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-25 13:54 ---
type :: thytype
integer(4), allocatable :: h(:)
end type thytype
type :: mytype
type(thytype), allocatable :: q(:)
end type mytype
type (mytype) :: x
x = mytype ([thytype([555])])
end
Reduced
With patch from here: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00668.html
IVopts begin to create IVs for expressions like a0[i][j][0]. This may cause
regressions in stack usage and code size (also possibly speed). Test case:
/* ---8--- */
enum {N=123};
int a0[N][N][N], a1[N][N][N],
On Linux/Intel64,
---
typedef int S;
typedef int V __attribute__((vector_size(16)));
typedef int IV __attribute__((vector_size(16)));
typedef union { S s[4]; V v; } U;
static U i[2], b, c;
extern int memcmp (const void *, const void *, __SIZE_TYPE__);
extern void abort ();
int main()
{
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-25 14:53 ---
Starting program: /export/build/gnu/gcc-avx/build-x86_64-linux/prev-gcc/a.out
Breakpoint 1, 0x003b55c33da0 in abort () from /lib64/libc.so.6
(gdb) f 1
#1 0x00400552 in main () at /tmp/x.c:29
29
--- Comment #2 from hjl dot tools at gmail dot com 2010-02-25 14:55 ---
This code:
0x004004f8 +84:vpxor %xmm0,%xmm0,%xmm0
0x004004fc +88:vpblendw $0x3,%xmm0,%xmm0,%xmm0
^
--- Comment #3 from hjl dot tools at gmail dot com 2010-02-25 15:06 ---
We expand
D.3242_4 = __builtin_ia32_vec_perm_v4si (D.3241_3, D.3240_2, { 4, 1, 2, 3 });
into
(insn 27 24 28 3 x.i:22 (set (subreg:V8HI (reg:V4SI 75) 0)
(vec_merge:V8HI (subreg:V8HI (reg:V4SI 75) 0)
--- Comment #4 from ubizjak at gmail dot com 2010-02-25 15:10 ---
I think that this code:
i[0].s[0] = 0;
i[0].s[1] = 1;
i[0].s[2] = 2;
i[0].s[3] = 3;
i[0].s[4] = 4;
i[0].s[5] = 5;
i[0].s[6] = 6;
i[0].s[7] = 7;
is also wrong. You have i[1].s[4].
--
--- Comment #4 from dominiq at lps dot ens dot fr 2010-02-25 15:23 ---
At revision 156693 or higher, the miscompilation with -floop-interchange
reported in comment #3 is gone. As a consequence the corresponding execution
time is now the same as when compiled with -fgraphite-identity.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
|
--- Comment #5 from hjl dot tools at gmail dot com 2010-02-25 15:30 ---
(In reply to comment #4)
I think that this code:
i[0].s[0] = 0;
i[0].s[1] = 1;
i[0].s[2] = 2;
i[0].s[3] = 3;
i[0].s[4] = 4;
i[0].s[5] = 5;
i[0].s[6] = 6;
i[0].s[7] = 7;
is also wrong.
--- Comment #2 from lennox at cs dot columbia dot edu 2010-02-25 15:31
---
Note that (as with PR 34000) this appears to be a regression from GCC 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42951
--- Comment #6 from joseph at codesourcery dot com 2010-02-25 15:40 ---
Subject: Re: Support -std=c90 as alias for -std=c89
On Thu, 25 Feb 2010, manu at gcc dot gnu dot org wrote:
Joseph, would you approve a patch for this?
Yes.
--
--- Comment #5 from cltang at pllab dot cs dot nthu dot edu dot tw
2010-02-25 16:01 ---
The cause seems to be the subreg lowering pass, the returning of the DImode
value is split into:
(insn 46 32 47 7 c.c:23 (set (reg:SI 0 r0)
(subreg:SI (reg:DI 133 [ D.2015 ]) 0)) 167
void bar (char *);
void baz (int);
char a[10];
void __attribute__((noinline))
bar (char *p)
{
asm volatile ( : : r (p) : memory);
}
void __attribute__((noinline))
baz (int i)
{
asm volatile ( : : r (i) : memory);
}
int __attribute__((noinline))
foo (int i)
{
bar (a);
baz (a[i + 1]);
--- Comment #1 from jim at clkda dot com 2010-02-25 16:33 ---
Created an attachment (id=19956)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19956action=view)
Preprocessor output of code that produces a symbol that can't be demangled.
The symbol that can't be demangled is
--- Comment #2 from jim at clkda dot com 2010-02-25 16:35 ---
I ran into this as well. My un-demanglable symbol is
_ZNK3FooIPvEcvS_IT_EIiEEv. Here's my info and attached test case is
demangle.ii:
/usr/bin/g++4 -v -save-temps -c -o demangle.o demangle.ccUsing built-in specs.
Target:
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-25 16:42 ---
Created an attachment (id=19957)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19957action=view)
gcc45-pr43160.patch
Patch I'm testing that sures the wrong debug info. The optimized out issue
remains, will file
--- Comment #9 from hjl dot tools at gmail dot com 2010-02-25 19:34 ---
The testcase will also fail with -msse4.1:
/export/gnu/import/svn/gcc-test/bld/gcc//xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc// -O -msse4.1
-fno-asynchronous-unwind-tablesx.c -o x
./x
make: *** [all]
--- Comment #10 from ubizjak at gmail dot com 2010-02-25 19:44 ---
(In reply to comment #9)
The testcase will also fail with -msse4.1:
Add this patch (please note that input operands of blend MD patterns are
*reversed*):
@@ -29153,7 +29153,7 @@ expand_vec_perm_blend (struct
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-25 19:51 ---
Paul, looks like one of yours.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2010-02-25 19:55
---
(In reply to comment #10)
(In reply to comment #9)
The testcase will also fail with -msse4.1:
Add this patch (please note that input operands of blend MD patterns are
*reversed*):
@@ -29153,7 +29153,7 @@
--- Comment #1 from anlauf at gmx dot de 2010-02-25 19:18 ---
Created an attachment (id=19958)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19958action=view)
Testcase
Testcase (module) and output of -fdump-tree-original for gfortran
from fortran-dev and trunk (4.5).
--
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-02-25 19:56
---
The regression was introduced by the following commit (found by bisection):
r133011 | ebotcazou | 2008-03-07 18:12:28 +0100 (Fri, 07 Mar 2008) | 33 lines
* decl.c (MAX_FIXED_MODE_SIZE): Define if not
--- Comment #10 from law at redhat dot com 2010-02-25 18:49 ---
Fixed long ago. Code looks reasonably efficient with trunk.
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2010-02-25 19:01 ---
A blind guess:
Index: i386.c
===
--- i386.c (revision 157069)
+++ i386.c (working copy)
@@ -29144,8 +29144,8 @@ expand_vec_perm_blend (struct
--- Comment #3 from jim at clkda dot com 2010-02-25 20:01 ---
I think the T_ is not handling the forward reference to the not-yet-specified
first template parameter correctly. For the original example, replacing T_
with N4DestE gives something that *looks* right although is probably
--- Comment #8 from meissner at gcc dot gnu dot org 2010-02-25 20:03
---
Patches checked in on October 15th, 2009 to properly set pure/const.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2010-02-25 19:02 ---
(In reply to comment #6)
H.J., can you please try this patch?
The patch generates this sequence, that looks OK to me:
movl$4, i+16(%rip)
movl$5, i+20(%rip)
movl$6, i+24(%rip)
--- Comment #7 from law at redhat dot com 2010-02-25 18:55 ---
I'm not a PPC expert, but the code looks pretty good at this point.I'd have
to assume Vlad's patch for 37488 and possibly other follow-on work resulted in
the improvements. I'm closing this PR as resolved. If you feel
--- Comment #8 from hjl dot tools at gmail dot com 2010-02-25 19:25 ---
(In reply to comment #6)
A blind guess:
Index: i386.c
===
--- i386.c (revision 157069)
+++ i386.c (working copy)
@@ -29144,8 +29144,8
subroutine bar
type t
integer, allocatable :: a(:)
end type t
type(t) :: foo
if (allocated(foo(1)%a)) call abort()
end
--
Summary: ICE invalid if accessing array member of non-array
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
--- Comment #2 from meissner at gcc dot gnu dot org 2010-02-25 18:25
---
Subject: Bug 43154
Author: meissner
Date: Thu Feb 25 18:25:26 2010
New Revision: 157069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157069
Log:
Fix PR target/43154
Added:
Hi,
my large code suddenly fails with the current gfortran, while it still works
with gfortran from fortran-dev (version 20100127). I traced the problem
to the following part of a module where the invocation of a subroutine
as
call set_set_v (ru(i)% c, c) ! (notemp) Fails with current
--- Comment #12 from ubizjak at gmail dot com 2010-02-25 20:11 ---
(In reply to comment #11)
That works. Thanks.
Can you please regression test combined patch on your AVX simulator?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
Take:
unsigned f(unsigned low32, unsigned *tmpA, unsigned prevBestA)
{
unsigned t = *tmpA;
if ((low32 prevBestA ) (!t))
prevBestA = low32;
return prevBestA;
}
CUT ---
Currently we get:
sltu$2,$6,$4
beq $2,$0,$L2
lw $3,0($5)
move$2,$4
--- Comment #13 from hjl dot tools at gmail dot com 2010-02-25 20:33
---
Created an attachment (id=19959)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19959action=view)
A patch
I am testing this patch. OK for trunk if there are no regressions
on Intel Core i7?
--
--- Comment #14 from hjl dot tools at gmail dot com 2010-02-25 20:36
---
Created an attachment (id=19960)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19960action=view)
A patch
Include testcase.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #3 from jv244 at cam dot ac dot uk 2010-02-25 20:45 ---
(In reply to comment #1)
Created an attachment (id=19958)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19958action=view) [edit]
Testcase
I'm wondering if you have a testcase that is 'fully functional' i.e. that
--- Comment #15 from ubizjak at gmail dot com 2010-02-25 20:49 ---
(In reply to comment #13)
Created an attachment (id=19959)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19959action=view) [edit]
A patch
I am testing this patch. OK for trunk if there are no regressions
on
--- Comment #8 from rwild at gcc dot gnu dot org 2010-02-25 20:53 ---
(In reply to comment #2)
I think one way to start addressing this would be to transport an unexpanded
docdir='${datarootdir}/doc/${PACKAGE}'
through to the sub makes (it's fairly irrelevant whether datarootdir
--- Comment #4 from anlauf at gmx dot de 2010-02-25 20:59 ---
(In reply to comment #3)
(In reply to comment #1)
Created an attachment (id=19958)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19958action=view) [edit]
Testcase
I'm wondering if you have a testcase that is
--- Comment #2 from meissner at gcc dot gnu dot org 2010-02-25 21:29
---
Patch checked in on August 21, 2009.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2010-02-25 21:42 ---
I cannot persuade trunk to produce different output to 4.4.
I am not saying that you are wrong but I can only reiterate Joost's request for
a testcase in which the result changes for the lack of a temporary.
Paul
--- Comment #6 from anlauf at gmx dot de 2010-02-25 22:12 ---
(In reply to comment #5)
I cannot persuade trunk to produce different output to 4.4.
I am not saying that you are wrong but I can only reiterate Joost's request
for
a testcase in which the result changes for the lack
--- Comment #7 from dominiq at lps dot ens dot fr 2010-02-25 22:16 ---
Comparing the original dumps for revisions 156618 and 157068, I see:
parm.19.dim[0].ubound = 50;
parm.19.dim[0].stride = 1;
parm.19.data = (void *)
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-02-25 22:12
---
Miscompilations are always nasty I guess... Simply don't use thin pointers,
they are quite inefficient.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from anlauf at gmx dot de 2010-02-25 22:26 ---
Created an attachment (id=19961)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19961action=view)
Stand-alone test
I get:
get_rule: ru(i)% c(1) =
-10 -10 -10. -10.
--- Comment #3 from meissner at gcc dot gnu dot org 2010-02-25 22:27
---
Subject: Bug 43154
Author: meissner
Date: Thu Feb 25 22:26:55 2010
New Revision: 157074
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157074
Log:
Fix PR target/43154
Added:
gcc 4.5 can not vectorize this simple loop:
void foo(int a[], int n) {
int i;
for(i=1; i n; i++)
a[i] = a[0];
}
gcc -O3 -fdump-tree-vect-all -c foo.c shows:
foo.c:3: note: not vectorized: unhandled data-ref
foo.c:3: note: bad data references.
foo.c:1: note: vectorized 0 loops in function.
--- Comment #9 from burnus at gcc dot gnu dot org 2010-02-25 23:38 ---
Reduced test case below. The problem is the call. On the trunk the call looks
as follows:
set_set_v (ru, D.1578);
which is complete nonesense. It should be:
ru.data[0].c.use
or something like that. If one removes
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-25 23:45 ---
Actually a[0] should be load hoisted from the loop as it not changed from
inside the loop at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-25 23:50 ---
So currently inside LIM (which does load motion in general):
D.2724_7 = a_6(D) + D.2723_5;
D.2725_8 = *a_6(D);
*D.2724_7 = D.2725_8;
But LIM/alias oracle does not know that D.2723_5 has a range of [4, n_3*4]
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-25 23:51 ---
Created an attachment (id=19962)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19962action=view)
Draft patch - regtests, but needs some audit
The attached patch drastically reduces the generated code
Reference N3035 20.9.10.2.5 para 5.
Ensure all specializations are fixed.
This is what is there now:
void
reset(pointer __p = pointer())
{
if (__p != get())
{
get_deleter()(get());
std::get0(_M_t) = __p;
}
}
This is what
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-25 23:54 ---
Related to PR 29751 but that only does a simple method and does not handle this
case as we need range info.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43182
gcc 4.5 could not vectorize floating point reductions.
float sum(float a[], int n) {
int i;
float total=0.0;
for(i=0; i n; i++)
total += a[i];
return total;
}
gcc -O3 -fdump-tree-vect-all shows:
foo.c:4: note: Unsupported pattern.
foo.c:4: note: not vectorized: unsupported use in stmt.
A variable, common block, or procedure pointer declared in the scoping unit of
a main program, module, or submodule implicitly has the SAVE attribute, which
may be con firmed by explicit specification. (F2008, 5.3.16 SAVE attribute).
In terms of the code generated, this already happens: The
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-25 23:57 ---
gcc 4.5 could not vectorize floating point reductions.
Yes it can; add -ffast-math. floating point reductions need -ffast-math as it
can change the results in some cases (negative zero and I think clamping cases
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-26 00:03
---
To be clear: we are probably going to implement this, and more, in time for
4.5.0, but we can't play this game: having a PR for each unimplemented item in
the last WP would immediately overflow Bugzilla. In
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-26 00:13
---
This didn't change in N3035, N3000 had the same wording.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-26 00:15
---
Chris, can you please double check this?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from changpeng dot fang at amd dot com 2010-02-26 00:28
---
Subject: RE: gcc could not vectorize floating point
reduction statements
Thanks for pointing this out. Actually I am working on a fortran program and
found the
the reduction statement. The fortran code can
--- Comment #7 from dodji at gcc dot gnu dot org 2010-02-26 00:40 ---
Created an attachment (id=19963)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19963action=view)
Reduced test case
This is a somewhat reduced test case that is still way bigger than what I'd
like, but still
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-26 00:47 ---
t.f:15: note: not vectorized: unsupported use in stmt.
(In reply to comment #2)
Subject: RE: gcc could not vectorize floating point
reduction statements
Thanks for pointing this out. Actually I am working on
--- Comment #16 from hjl dot tools at gmail dot com 2010-02-26 00:53
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01088.html
Intel Core i7 result is OK:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02465.html
--
hjl dot tools at gmail dot com
--- Comment #1 from law at redhat dot com 2010-02-26 01:04 ---
Trunk produces:
mid_pred:
movem.l #14336,-(%sp)
move.l 16(%sp),%d1
move.l 20(%sp),%d0
move.l %d1,%d3
sub.l %d0,%d3
move.l %d3,%d2
add.l %d2,%d2
subx.l %d2,%d2
--- Comment #9 from law at redhat dot com 2010-02-26 01:23 ---
The trunk now generates:
ldr r3, .L4
ldr r2, .L4+4
ldr r1, .L4+8
b .L2
.L3:
ldr r0, [r3], #4
str r0, [r2], #4
.L2:
cmp r3, r1
bcc
--- Comment #22 from law at redhat dot com 2010-02-26 01:34 ---
Fixed on the trunk eons ago. Fix not really suitable for backporting to
release branches.
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2010-02-26
02:46 ---
Created an attachment (id=19964)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19964action=view)
Testcase
Yet another thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42453
--
Summary: A loop in tree_unroll_loops_completely never ends
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-26
04:29 ---
Created an attachment (id=19965)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19965action=view)
Testcase
gcc -S -O3 -DBUG pr43186.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-26 05:28 ---
The warning for -Warray-temporaries is shown here for both -m32 and -m64 --
and
I also see _gfortran_internal_pack in the -fdump-tree-original. Do you have
by chance local changes which fix this issue?
Compile the following code with options -march=armv7-a -mthumb -Os
struct A
{
int f0,f1,f2,f3,f4,f5;
};
void func(const struct A* p)
{
printf(%d %d %d %d %d %d %d,
p-f0, p-f1, p-f2, p-f3, p-f4,
(p-f2 == 0) ? 0 : p-f2 * 100 / (p-f1 + p-f2 + p-f3), p-f5);
}
GCC generates:
$ cat pr43188.c
int *__attribute__((__aligned__(16))) *p;
int main (void)
{
return **p;
}
$ gcc -O3 -march=pentium3 pr43188.c
pr43188.c: In function 'main':
pr43188.c:3:5: error: alignment of array elements is greater than element size
--
Summary: [4.5 Regression] error:
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P4
--- Comment #1 from pault at gcc dot gnu dot org 2010-02-26 07:35 ---
This fixes it and regtests.
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (revision 157061)
--- gcc/fortran/check.c (working copy)
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-26 07:36 ---
Note: One should check that the initialization properly works. It could be that
one needs to add a sym-ns-proc_name-attr.flavor == FL_MODULE in the check
in trans-decl.c's gfc_get_symbol_decl for
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-26 07:44 ---
Created an attachment (id=19966)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19966action=view)
Improved patch
This patch changes:
a) There was a bug, which causes that non-SAVEd variables in procedures where
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-26 07:54 ---
(In reply to comment #1)
This fixes it and regtests.
+ if (array-expr_type != EXPR_VARIABLE array-expr_type !=
EXPR_FUNCTION)
The patch looks OK, but actually I fail to see when an EXPR_FUNCTION is valid
in
100 matches
Mail list logo
