--- 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 vali
--- 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=19966&action=view)
Improved patch
This patch changes:
a) There was a bug, which causes that non-SAVEd variables in procedures wher
--- 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 gfc_conv_initia
--- 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)
*
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P4
Targe
$ 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: alignmen
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 g
--- 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?
--- 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=19965&action=view)
Testcase
gcc -S -O3 -DBUG pr43186.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
--
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 or
--- 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=19964&action=view)
Testcase
Yet another thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42453
--- 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 #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 #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 #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 changed:
--- 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
--- 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=19963&action=view)
Reduced test case
This is a somewhat reduced test case that is still way bigger than what I'd
like, but still bet
--- 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 no
--- 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 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 #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 gen
--- 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
t
"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 vari
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.
fo
--- 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
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::get<0>(_M_t) = __p;
}
}
This is what
--- 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=19962&action=view)
Draft patch - regtests, but needs some audit
The attached patch drastically reduces the generated code
(-fdump-t
--- 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]
w
--- 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 #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 remove
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 #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=gcc&view=rev&rev=157074
Log:
Fix PR target/43154
Added:
trunk/gcc/testsuite/gcc.ta
--- 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=19961&action=view)
Stand-alone test
I get:
get_rule: ru(i)% c(1) =
-10 -10 -10. -10.
--- 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 *) &r
--- 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 la
--- 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 #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 #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 #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=19958&action=view) [edit]
> > Testcase
>
> I'm wondering if you have a testcase that
--- 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 datarootd
--- 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=19959&action=view) [edit]
> A patch
>
> I am testing this patch. OK for trunk if there are no regressions
>
--- 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=19958&action=view) [edit]
> Testcase
I'm wondering if you have a testcase that is 'fully functional' i.e. t
--- 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=19960&action=view)
A patch
Include testcase.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- 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=19959&action=view)
A patch
I am testing this patch. OK for trunk if there are no regressions
on Intel Core i7?
--
http://gc
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 #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
--- 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 #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 not
--- 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 alre
--- 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 +291
--- 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 #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 expand_ve
--- 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] Abor
--- 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=19958&action=view)
Testcase
Testcase (module) and output of -fdump-tree-original for gfortran
from fortran-dev and trunk (4.5).
--
http
--- 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 +2
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 gfortr
--- 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)
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
Keywords
--- 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 expan
--- 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=gcc&view=rev&rev=157069
Log:
Fix PR target/43154
Added:
branches/ibm/power7-meissn
--- 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 #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 i
--- 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=19957&action=view)
gcc45-pr43160.patch
Patch I'm testing that sures the wrong debug info. The issue
remains, will file a different
--- 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: x8
--- 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=19956&action=view)
Preprocessor output of code that produces a symbol that can't be demangled.
The symbol that can't be demangled is _ZNK3Fo
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
--- 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 {*thumb
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- 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 #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 al
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
|
--- 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.
T
--- 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].
--
http://gcc.gnu.or
--- 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 #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
^
0x
--- 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
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()
{
i[0].s
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], a2[N][N
--- 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 test
--- 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'
--- 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
--- 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
AssignedTo|unassigned
--- 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 -fd
--- 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 proc
--- 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 --leak-
--- 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 #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, Hendrick
--- 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 re
--- 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 in
--- 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
---
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 it
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 ali
--- 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
--- 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 #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=gcc&view=rev&rev=157063
Log:
PR debug/43166
* cfgexpand.c (expand_debug_expr)
--- 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=gcc&view=rev&rev=157062
Log:
PR debug/43165
* cfgexpand.c (expand_debug_expr):
--- 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 no
--- 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
implici
--- 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 have
--- 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 (myType)
100 matches
Mail list logo
