[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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) x%a = 42. end select end subroutine Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 08:38:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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 sub-namespaces e.g. in the following cases: 1) BLOCK 2) SELECT TYPE 3) contained procedures 4) ...? Comment #0 shows the failure for case (2), but the others may also be affected. I'll check this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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 implicit none real :: r1 r1 = 42. block real :: r2 r2 = 43. glob = 0. end block end subroutine end The assignment to 'glob' is clearly invalid, but is not being caught. 'gfc_impure_variable' is only called for 'r1', the other two are left unchecked. Seems like statements inside a BLOCK are not being resolved at all?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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 none contains pure subroutine swap implicit none real :: r1 contains pure subroutine cont real :: r2 r1 = 42. r2 = 43. end subroutine end subroutine end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug debug/43165] [4.5 Regression] ice in simplify_subreg, at simplify-rtx.c:5146
--- 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): Don't call simplify_gen_subreg if bitpos isn't multiple of mode's bitsize. * gcc.dg/torture/pr43165.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr43165.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43165
[Bug debug/43166] [4.5 Regression] ICE in simplify_subreg on fortran code
--- 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) : If mode is BLKmode, assert op0 is a MEM and just adjust its mode. * trans-common.c (build_common_decl): Also update DECL_MODE, and DECL_SIZE when encountering a larger common block and call layout_decl. * gfortran.dg/debug/pr43166.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/debug/pr43166.f Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43166
[Bug debug/43165] [4.5 Regression] ice in simplify_subreg, at simplify-rtx.c:5146
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43165
[Bug debug/43166] [4.5 Regression] ICE in simplify_subreg on fortran code
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43166
[Bug fortran/43172] New: Unnecessary array temporary - non-pointer/non-target does not alias
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 alias as it is neither a POINTER nor a TARGET; if there are components, one needs to be more careful - one also needs to check for POINTER in the ultra most component. (By the way, dependency.c's check_data_pointer_types needs to be modified to fix this.) -- Summary: Unnecessary array temporary - non-pointer/non-target does not alias Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43172
[Bug fortran/43173] New: Unnecessary array temporary: Passing contiguous array as actual argument
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 is allocatable), stride = 1, and thus all arguments are simple contiguous - unless the stride is non-unity or one has, e.g., "ot( [1,3,5])". Note 2: If one has an explicit-size array, it works - there is no temporary for: REAL :: ot(5) integer :: time_steps call foo (ot(1:time_steps)) I think the issue is that one mixes up the (:) of an allocatable array with the (:) of a non-allocatable, assumed-shape dummy argument or a pointer. The temporary seems to be generated in trans-arrays.c's gfc_conv_array_parameter; the issue seems to be that "full_array_var" is false and then later there is either no_pack or contiguous set to false. -- Summary: Unnecessary array temporary: Passing contiguous array as actual argument Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43173
[Bug c/20631] Support -std=c90 as alias for -std=c89
--- 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 CC||joseph at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20631
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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 inside a pure function). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug debug/43160] Wrong debug info in guality/vla-1.c (f1)
--- 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 request to handle that is a separate issue). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43160
[Bug fortran/43172] Unnecessary array temporary - non-pointer/non-target does not alias
--- 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, Hendrickson, Maine, Martin and Smith very carefully to understand what is defined and what is not in respect of actual versus real arguments. 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 it correctly, this is undefined and so processor dependent. Thus, we could cure the PR very simply by fixing 'gfc_symbols_could_alias' but I think that it might be a good idea to warn of the undefined status of the actual argument corresponding to 'ptr'. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 12:42:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43172
[Bug fortran/43173] Unnecessary array temporary: Passing contiguous array as actual argument
--- 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
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- 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-check=full ? Without the =full option, > I also do not get any line info output but just in the summary "definitely > lost: 288 bytes in 4 blocks". Tobias, I cannot remember how valgrind puts it but I get the no memory leaks possible message, even with =full. Cheers Possible -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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 procedure has sub-namespaces. Actually it seems that 'gfc_impure_variable' works fine, but for SELECT TYPE the 'gfc_current_ns' is not set correctly. Setting the namespace happens in 'resolve_codes', but the pureness check happens inside 'gfc_resolve_blocks'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43173] Unnecessary array temporary: Passing contiguous array as actual argument
--- 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 -fdump-tree-original. Do you have by chance local changes which fix this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43173
[Bug tree-optimization/43164] [4.5 Regression] ice in completely_scalarize_record, at tree-sra.c:85
--- 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 at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 13:07:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43164
[Bug fortran/43172] Unnecessary array temporary - non-pointer/non-target does not alias
--- 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 it correctly, this is > undefined and so processor dependent. Without studying the standard, I had assumes that your example is valid and well-defined (of cause assuming that the proper actual arguments are used). Actually, I do see no closer relation to my test case in comment 0 as there neither kpts nor syp are dummy arguments and kpts is allocatable. * * * > Thus, we could cure the PR very simply > by fixing 'gfc_symbols_could_alias' but I think that it might be a good idea > to warn of the undefined status of the actual argument corresponding to 'ptr' Well, I think I now slowly start to understand your point. If one does real :: a(4,4) real,pointer :: p(:,:) call foo(p,a) a = 7 p = 0 if (a(1,1) == 0) stop 'Aliases' the "processor" may optimize the "stop" line away since "a" has no target attribute and is known to be 7. This code is invalid just because accessing the target of "p" is invalid as "p" is has undefined association status. However, if one slightly extends the subroutine, even the code above is valid: subroutine foo (ptr, tar) [...] ptr => tar ptr = 8 allocate(ptr(1,1)) end subroutine The problem is not much different from: subroutine foo(p) integer, pointer :: p integer, target :: t p => t which is also perfectly valid - except that after the call the actual argument associated with "p" is a pointer with "undefined" association state. I think in both cases one can warn with -Wsurprising, but especially your case is still valid if the actual argument has also the TARGET attribute. Thus, I would probably only warn with -Wsurprising for dummy_ptr => local_target (i.e. "local_target" is not host/use associated nor a dummy argument) - but warning for dummy arguments is also fine with me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43172
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- 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 not work (checking if we're inside a pure function).
The BLOCK issue in comment #3 is fixed by the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157055)
+++ gcc/fortran/resolve.c (working copy)
@@ -11689,18 +11695,30 @@ gfc_impure_variable (gfc_symbol *sym)
}
-/* Test whether a symbol is pure or not. For a NULL pointer, checks the
- symbol of the current procedure. */
+/* Test whether a symbol is pure or not. For a NULL pointer, checks if the
+ current namespace is inside a pure procedure. */
int
gfc_pure (gfc_symbol *sym)
{
symbol_attribute attr;
+ gfc_namespace *ns;
if (sym == NULL)
-sym = gfc_current_ns->proc_name;
- if (sym == NULL)
-return 0;
+{
+ /* Check if the current namespace or one of its parents
+belongs to a pure procedure. */
+ for (ns = gfc_current_ns; ns; ns = ns->parent)
+ {
+ sym = ns->proc_name;
+ if (sym == NULL)
+ return 0;
+ attr = sym->attr;
+ if (attr.flavor == FL_PROCEDURE && (attr.pure || attr.elemental))
+ return 1;
+ }
+ return 0;
+}
attr = sym->attr;
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-02-25 08:38:03 |2010-02-25 13:40:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- 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 case. If I read the dump correctly, one effectively does: tmp = thytype([555]) x = mytype(tmp) however, for "mytype(tmp)" the data is copied instead of simply assigning the pointer "tmp.data" and "tmp.data" is never freed. a) One creates "thytype" with the value 555: (*(struct thytype[1] * restrict) atmp.1.data)[0] = thytype.4; - and recopying again: (*(struct thytype[1] * restrict) atmp.7.data)[S.9] = (*(struct thytype[1] * restrict) atmp.1.data)[S.9]; b) One now assigns that data to "mytype" - but not directly but via malloc+memcopy: D.1592 = (void * restrict) __builtin_malloc (MAX_EXPR ); (*(struct thytype[0:] * restrict) mytype.0.q.data)[S.10].h.data = D.1592; __builtin_memcpy ((integer(kind=4)[0:] * restrict) (*(struct thytype[0:] * restrict) mytype.0.q.data)[S.10].h.data, (integer(kind=4)[0:] * restrict) (*(struct thytype[1] * restrict) atmp.7.data)[S.10].h.data, D.1590 * 4); The problem is now that "atmp.7.data.h.data" is never freed. It would be fantastic if instead of freeing atmp.7.data.h.data one could simply assign atmp.7.data.h.data to mytype.0.q.data[S.10].h.data without malloc/memcpy. I am sure it is nontrivial, but I would really like to see the number of temporaries be cut down. The dumps are pretty hard to read and we probably give also the middle end a hard time in figuring out that we do not need ~8 mallocs but one three - especially since the middle end does not really optimize malloc/free (it could, but it doesn't - yet). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug tree-optimization/43174] New: Teaching SCEV about ADDR_EXPR causes regression
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][N], a3[N][N][N],
a4[N][N][N], a5[N][N][N], a6[N][N][N], a7[N][N][N];
int foo() {
int i, j, k, s = 0;
for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
for (k = 0; k < N; k++) {
s += a0[i][j][k]; s += a1[i][j][k]; s += a2[i][j][k]; s += a3[i][j][k];
s += a4[i][j][k]; s += a5[i][j][k]; s += a6[i][j][k]; s += a7[i][j][k];
}
return s;
}
/* ---8<--- */
Without the patch, IVopts produce one IV for j loop and 8 IVs for k loop. With
the patch, IVopts additionally produce 8 IVs for j loop (with 123*4 increment),
4 of which live on stack (on x86-64, -O2).
Creation of IVs that live on stack is likely due to inexact register pressure
estimation in IVopts.
However, it would be nice if IVopts could notice that it's cheaper to take the
final value of inner loop IVs (e.g. &a0[i][j][k]) instead of incrementing IV
holding &a0[i][j][0] by 123*4. It would decrease register pressure and allow
to generate perfect code for the test case.
--
Summary: Teaching SCEV about ADDR_EXPR causes regression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amonakov at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43174
[Bug target/43175] New: __builtin_ia32_vec_perm_v4si doesn't work with AVX
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[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;
b.v = __builtin_ia32_vec_perm_v4si (i[0].v, i[1].v, (IV){4, 1, 2, 3});
c.s[0] = i[0].s[4];
c.s[1] = i[0].s[1];
c.s[2] = i[0].s[2];
c.s[3] = i[0].s[3];
__asm__("" : : : "memory");
if (memcmp (&b, &c, sizeof(c)) != 0)
abort ();
return 0;
}
--
aborted with -mavx. You can get Intel AVX SDE from
http://software.intel.com/en-us/avx/
to run it:
[...@gnu-6 gcc]$ ./xgcc -B./ -O -mavx /tmp/perm.c
[...@gnu-6 gcc]$ ./sde -- ./a.out
Aborted
[...@gnu-6 gcc]$ ./xgcc -B./ -O -mssse3 /tmp/perm.c
[...@gnu-6 gcc]$ ./a.out
[...@gnu-6 gcc]$
--
Summary: __builtin_ia32_vec_perm_v4si doesn't work with AVX
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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
29abort ();
(gdb) p b
$6 = {s = {0, 0, 0, 0}, v = 0x600920}
(gdb) p c
$7 = {s = {4, 1, 2, 3}, v = 0x600930}
(gdb) disass
Dump of assembler code for function main:
0x004004a4 <+0>: sub$0x8,%rsp
0x004004a8 <+4>: movl $0x0,0x20044e(%rip)# 0x600900
0x004004b2 <+14>:movl $0x1,0x200448(%rip)# 0x600904
0x004004bc <+24>:movl $0x2,0x200442(%rip)# 0x600908
0x004004c6 <+34>:movl $0x3,0x20043c(%rip)# 0x60090c
0x004004d0 <+44>:movl $0x4,0x200436(%rip)# 0x600910
0x004004da <+54>:movl $0x5,0x200430(%rip)# 0x600914
0x004004e4 <+64>:movl $0x6,0x20042a(%rip)# 0x600918
0x004004ee <+74>:movl $0x7,0x200424(%rip)# 0x60091c
0x004004f8 <+84>:vpxor %xmm0,%xmm0,%xmm0
0x004004fc <+88>:vpblendw $0x3,%xmm0,%xmm0,%xmm0
0x00400502 <+94>:vmovdqa %xmm0,0x200416(%rip)# 0x600920
0x0040050a <+102>: movl $0x4,0x20041c(%rip)# 0x600930
---Type to continue, or q to quit---
0x00400514 <+112>: movl $0x1,0x200416(%rip)# 0x600934
0x0040051e <+122>: movl $0x2,0x200410(%rip)# 0x600938
0x00400528 <+132>: movl $0x3,0x20040a(%rip)# 0x60093c
0x00400532 <+142>: mov$0x600920,%esi
0x00400537 <+147>: mov$0x600930,%edi
0x0040053c <+152>: mov$0x10,%ecx
0x00400541 <+157>: repz cmpsb %es:(%rdi),%ds:(%rsi)
0x00400543 <+159>: seta %dl
0x00400546 <+162>: setb %al
0x00400549 <+165>: cmp%al,%dl
0x0040054b <+167>: je 0x400552
0x0040054d <+169>: callq 0x4003a0
=> 0x00400552 <+174>: mov$0x0,%eax
0x00400557 <+179>: add$0x8,%rsp
0x0040055b <+183>: retq
End of assembler dump.
(gdb)
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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 ^ 0x00400502 <+94>:vmovdqa %xmm0,0x200416(%rip) is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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)
(subreg:V8HI (reg:V4SI 75) 0)
(const_int 3 [0x3]))) -1 (nil))
(insn 28 27 29 3 x.i:22 (set (reg:V4SI 60 [ D.3242 ])
(reg:V4SI 75)) -1 (nil))
But reg 75 is never set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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.org/bugzilla/show_bug.cgi?id=43175
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
--- 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. The timings wit/without the options correspond to a missed vectorization of the critical loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
[Bug tree-optimization/43174] Teaching SCEV about ADDR_EXPR causes regression
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 15:26:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43174
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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. You have i[1].s[4]. > This testcase is extracted out of gcc.target/i386/vperm-v4si-2.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/42951] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- 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
[Bug c/20631] Support -std=c90 as alias for -std=c89
--- 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=20631
[Bug rtl-optimization/42502] [4.4/4.5 Regression] Bad register allocation in a very simple code
--- 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 {*thumb1_movsi_insn} (nil))
(insn 47 46 40 7 c.c:23 (set (reg:SI 1 r1 [+4 ])
(subreg:SI (reg:DI 133 [ D.2015 ]) 4)) 167 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:DI 133 [ D.2015 ])
(nil)))
As the IRA dumps show, this splitting into two insns causes r0 to conflict with
the lifetime of r133, preventing it to be assigned to r0-r1 and coalesced.
I don't have a patch for this, but I found turning off the subreg lowering by
-fno-split-wide-types retains the DImode return:
(insn 37 32 40 7 c.c:23 (set (reg/i:DI 0 r0)
(reg:DI 133 [ D.2015 ])) 164 {*thumb1_movdi_insn} (expr_list:REG_DEAD
(reg:DI 133 [ D.2015 ])
(nil)))
and generates:
push{r4, r5, r6, lr}
sub sp, sp, #16
mov r5, r0
mov r0, sp
mov r6, r1
mov r4, sp
bl func
cmp r5, #1
bne .L2
ldr r0, [sp]
ldr r1, [sp, #4]
b .L3
.L2:
ldr r0, [r4, #8]
ldr r1, [r4, #12]
cmp r6, #2
beq .L3
ldr r3, [r4]
ldr r4, [r4, #4]
sub r0, r0, r3
sbc r1, r1, r4
.L3:
add sp, sp, #16
@ sp needed for prologue
pop {r4, r5, r6, pc}
which should be similar to what 4.2.1 generated.
The sp duplication in r4, as mentioned by others, is another problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
[Bug debug/43176] New: var-tracking fails to notice a value change
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]);
return i;
}
int
main (void)
{
foo (7);
return 0;
}
on x86_64-linux -O2 -g has wrong location info for i during epilogue - i is
said to live in %edi initially (correct), then in %ebx starting from middle of
the first call (also correct), but at the end of function it does:
movl%ebx, %eax
popq%rbx
and of course the restoring of %rbx invalidates the location (so var-tracking
should say that i now lives in %eax instead).
--
Summary: var-tracking fails to notice a value change
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43176
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
--- 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 _ZNK3FooIPvEcvS_IT_EIiEEv, which should correspond to template template Foo::operator Foo() const; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
--- 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: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/3.4.3 --enable-libgcj-multifile --enable-languages=c,c++,java,f95 --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070626 (Red Hat 4.1.2-14) /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE demangle.cc -mtune=generic -fpch-preprocess -o demangle.ii ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/3.4.3 /usr/include/c++/3.4.3/x86_64-redhat-linux /usr/include/c++/3.4.3/backward /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include /usr/include End of search list. /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -fpreprocessed demangle.ii -quiet -dumpbase demangle.cc -mtune=generic -auxbase-strip demangle.o -version -o demangle.s GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-14) (x86_64-redhat-linux) compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 184adf145435f56fdcc7b1a1fb1af981 as -V -Qy -o demangle.o demangle.s GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version 2.15.92.0.2 20040927 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
[Bug debug/43160] Wrong debug info in guality/vla-1.c (f1)
--- 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 PR for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43160
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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] Aborted (core dumped) [...@gnu-1 pr43175]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|__builtin_ia32_vec_perm_v4si|__builtin_ia32_vec_perm_v4si |doesn't work with AVX |doesn't work with -msse4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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_vec } /* This matches five different patterns with the different modes. */ - x = gen_rtx_VEC_MERGE (vmode, op0, op1, GEN_INT (mask)); + x = gen_rtx_VEC_MERGE (vmode, op1, op0, GEN_INT (mask)); x = gen_rtx_SET (VOIDmode, target, x); emit_insn (x); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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 CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 19:51:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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 @@ expand_vec_perm_blend (struct expand_vec > } > >/* This matches five different patterns with the different modes. */ > - x = gen_rtx_VEC_MERGE (vmode, op0, op1, GEN_INT (mask)); > + x = gen_rtx_VEC_MERGE (vmode, op1, op0, GEN_INT (mask)); >x = gen_rtx_SET (VOIDmode, target, x); >emit_insn (x); > > That works. Thanks. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug ada/42253] Wrong handling of null for fat pointers forced thin by size clause
--- 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 already defined. (gnat_to_gnu_entity) : Try to get a smaller form of the component for packing, if possible, as well as if a component size clause is specified. : For an array type used to implement a packed array, get the component type from the original array type. Try to get a smaller form of the component for packing, if possible, as well as if a component size clause is specified. (round_up_to_align): New function. (make_packable_type): Add in_record parameter. For a padding record, preserve the size. If not in_record and the size is too large for an integral mode, attempt to shrink the size by lowering the alignment. Ditch the padding bits of the last component. Compute sizes and mode manually, and propagate the RM size. Return a BLKmode record type if its size has shrunk. (maybe_pad_type): Use MAX_FIXED_MODE_SIZE instead of BIGGEST_ALIGNMENT. Use Original_Array_Type to retrieve the type in case of an error. Adjust call to make_packable_type. (gnat_to_gnu_field): Likewise. (concat_id_with_name): Minor tweak. * trans.c (larger_record_type_p): New predicate. (call_to_gnu): Compute the nominal type of the object only if the parameter is by-reference. Do the conversion actual type -> nominal type if the nominal type is a larger record. (gnat_to_gnu): Do not require integral modes on the source type to avoid the conversion for types with identical names. (addressable_p): Add gnu_type parameter. If it is specified, do not return true if the expression is not addressable in gnu_type. Adjust recursive calls. * utils.c (finish_record_type): Remove dead code. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug target/37488] register allocation spills floats needlessly
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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 expand_vec do_subreg: vmode = V8HImode; target = gen_lowpart (vmode, target); - op0 = gen_lowpart (vmode, target); - op1 = gen_lowpart (vmode, target); + op0 = gen_lowpart (vmode, op0); + op1 = gen_lowpart (vmode, op1); break; default: H.J., can you please try this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
--- 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 correct: _ZN9convertercvPN4DestEI4DestEEv which demangles to converter::operator Dest*(). Similarly, in the second example, if I replace T_ with i, I get _ZNK3FooIPvEcvS_IiEIiEEv which demangles to Foo::operator Foo() const. http://www.codesourcery.com/public/cxx-abi/abi.html#mangling is helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
[Bug target/23983] the altivec builtins should be marked as pure/const
--- 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 CC||meissner at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23983
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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) movl$7, i+28(%rip) vmovdqa i+16(%rip), %xmm0 movl$0, i(%rip) movl$1, i+4(%rip) movl$2, i+8(%rip) movl$3, i+12(%rip) vpblendw$3, i(%rip), %xmm0, %xmm0 movl$4, c(%rip) movl$1, c+4(%rip) movl$2, c+8(%rip) movl$3, c+12(%rip) vmovdqa %xmm0, b(%rip) > -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 19:02:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug rtl-optimization/37490] [4.4/4.5 Regression] IRA causes FP code to have more spills
--- 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 it should be kept open, feel free to re-open it. -- law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with AVX
--- 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 @@ expand_vec_perm_blend (struct expand_vec
> do_subreg:
>vmode = V8HImode;
>target = gen_lowpart (vmode, target);
> - op0 = gen_lowpart (vmode, target);
> - op1 = gen_lowpart (vmode, target);
> + op0 = gen_lowpart (vmode, op0);
> + op1 = gen_lowpart (vmode, op1);
>break;
>
> default:
>
> H.J., can you please try this patch?
>
Doesn't work:
(gdb) p b
$1 = {s = {0, 5, 6, 7}, v = 0x600920}
(gdb) p c
$2 = {s = {4, 1, 2, 3}, v = 0x600930}
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug fortran/43179] New: ICE invalid if accessing array member of non-array
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: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug target/43154] vec_mergel and vec_mergeh should support V2DF/V2DI
--- 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-meissner/gcc/testsuite/gcc.target/powerpc/pr43154.c Modified: branches/ibm/power7-meissner/gcc/ChangeLog.power7 branches/ibm/power7-meissner/gcc/config/rs6000/rs6000-builtin.def branches/ibm/power7-meissner/gcc/config/rs6000/rs6000-c.c branches/ibm/power7-meissner/gcc/config/rs6000/rs6000.c branches/ibm/power7-meissner/gcc/config/rs6000/vector.md branches/ibm/power7-meissner/gcc/testsuite/ChangeLog.power7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43154
[Bug fortran/43180] New: [4.5 Regression] Bad results without temporary copy of intent(in) argument
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 gfortran
fails (i.e., the resulting c contains bad values), while
tmp_c = ru(i)% c ! ("temp") Works
call set_set_v (tmp_c, c)
works. For details see the attached code.
I have compared the output of -fdump-tree-original of the fortran-dev
and of the trunk versions of gfortran and found that they are identical
for the "temp" variant, while there is a significant different for the
notemp variant. Maybe someone knowledgeable can identify the cause of
the problem.
--
Summary: [4.5 Regression] Bad results without temporary copy of
intent(in) argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anlauf at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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
[Bug target/43181] New: branches in conditional move code
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
movz$6,$2,$3
$L2:
j $31
move$2,$6
But we should be able to have no branches in this case and only one conditional
move. I checked the spu-elf target and noticed there are no branches there so
the middle-end is able to do it.
--
Summary: branches in conditional move code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: mips64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43181
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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 |Added Attachment #19959|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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. that one can run & debug. My first guess is that a temporary there is not needed, unless there is an aliasing problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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 > on Intel Core i7? I think that following ChangeLog text better describes the change: PR target/43175 * config/i386/i386.c (expand_vec_perm_blend): Use correct operands in V8HImode subregs. Fix operand order in VEC_MERGE rtx. Also, please post patch to gcc-patches@ ML for others to see/comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- 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 is
> expanded
> in the toplevel or not, ${PACKAGE} is important so that it can vary between
> the
> different components of the tree.
>
> Right now I don't see how to escape this thing properly so it gets through the
> toplevel machinery.
>
Maybe Paolo has a good idea (or alternative) for this, let's CC him.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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 is 'fully functional' i.e. that one > can run & debug. It will take some time as I need to dump a snapshot of the table of rules and an excerpt of the input data that are processed. Will do, but don't hold your breath. > My first guess is that a temporary there is not needed, unless > there is an aliasing problem. There is no real need for a temporary copy of ru(i)%c, but as I wrote without the copy I get wrong results. Maybe it's as simple as an improper offset and the like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug target/41145] My VSX changes broke gcc.dg/dfp/altivec-types.c
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41145
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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 -- pault at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2010-02-25 19:51:38 |2010-02-25 21:42:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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 of a temporary. Printing the argument src in the contained subroutine set_set_v shows that it contains junk on ia32 if there is no temporary. I'm working on a self-contained test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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 *) &ru[(integer(kind=8)) i + -1].c[0]; < parm.19.offset = -1; < D.1619 = _gfortran_internal_pack (&parm.19); ... > parm.19.dim[0].ubound = D.1620; > parm.19.dim[0].stride = NON_LVALUE_EXPR ; > parm.19.data = (void *) &(*c.0)[0]; > parm.19.offset = NON_LVALUE_EXPR ; Are the NON_LVALUE_EXPR expected? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- 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 CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 22:12:16 date|| Summary|Wrong handling of null for |[4.4/4.5 regression] run |fat pointers forced thin by |time crash on null for thin |size clause |pointers Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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. -10. -10. -10. -10. -10. -10. -10. -10. -10. -10 -127 Using temporary: set_set_v: src(1) = -10 -10 -10. -10. -10. -10. -10. -10. -10. -10. -10. -10. -10. -10 -127 No temporary: set_set_v: src(1) = 538976288 538976288 6.01347001699906849E-154 6.01347001699906849E-154 6.01347001699906849E-154 6.01347001699906849E-154 -3.13018361251940323E+021 -10. -10. -10. -10. -10. -10. 0 101 No problem with older gfortrans. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug target/43154] vec_mergel and vec_mergeh should support V2DF/V2DI
--- 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.target/powerpc/pr43154.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-builtin.def trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/vector.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43154
[Bug middle-end/43182] New: gcc could not vectorize this simple loop (un-handled data-ref)
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.
It seems gcc gets confused at a[0] and gives up vectorization. There
is no dependence in this loop, and we should teach gcc to handle a[0]
to vectorize it.
--
Summary: gcc could not vectorize this simple loop (un-handled
data-ref)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43182
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
--- 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 the "comment" component, it works - but only because then "&ru" and "&ru.data[0].c.use" point to the same memory - otherwise it is as wrong as before. ! module mo_obs_rules type t_set integer :: use = 42 end type t_set type t_rules character(len=40) :: comment type(t_set) :: c (1) end type t_rules type (t_rules), save :: ru (1) contains subroutine get_rule (c) type(t_set) :: c (:) !print *, ru(1)%c(1)%use ! 42 -> OK !print *, c(1)%use ! 42 -> OK call set_set_v (ru(1)%c, c) contains subroutine set_set_v (src, dst) type(t_set), intent(in):: src(1) type(t_set), intent(inout) :: dst(1) ! print *, src(1)%use ! garbage (should be 42) ! print *, dst(1)%use ! 42 -> OK end subroutine set_set_v end subroutine get_rule end module mo_obs_rules program test use mo_obs_rules type(t_set) :: c (1) call get_rule (c) end program test -- burnus at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2010-02-25 21:42:55 |2010-02-25 23:38:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug middle-end/43182] gcc could not vectorize this simple loop (un-handled data-ref)
--- 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 Keywords||alias, missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43182
[Bug middle-end/43182] GCC does not pull out a[0] from loop that changes a[i] for i:[1,n]
--- 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] which means D.2724_7 can never equal a_6 so we don't pull out the load from a_6. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 23:50:10 date|| Summary|gcc could not vectorize this|GCC does not pull out a[0] |simple loop (un-handled |from loop that changes a[i] |data-ref) |for i:[1,n] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43182
[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs
--- 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-tree-original) for initializations.
a) For variables in PROGRAM which are static (note: variables in PROGRAM are
implicitly SAVE).
b) For all kind of derived types with default initializer, especially those
which have allocatable components
I am quite confident that the code is correct, however, one should check
whether the "dealloc" argument is correct. If it is wrong, there will be either
unnecessarily a if(var != NULL) { free } or the program will leak memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43178
[Bug libstdc++/43183] New: std::unique_ptr::reset() does not conform to N3035.
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 it should be changed to:
void
reset(pointer __p = pointer())
{
pointer old_p = get();
if (__p != old_p)
{
std::get<0>(_M_t) = __p;
get_deleter()(old_p);
}
}
--
Summary: std::unique_ptr::reset() does not conform to N3035.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tjgolubi at netins dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug middle-end/43182] GCC does not pull out a[0] from loop that changes a[i] for i:[1,n]
--- 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
[Bug middle-end/43184] New: gcc could not vectorize floating point reduction statements
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.
foo.c:4: note: unexpected pattern.
foo.c:1: note: vectorized 0 loops in function.
I have verified that gcc can vectorize integer reduction, but not float and
double.
--
Summary: gcc could not vectorize floating point reduction
statements
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43184
[Bug fortran/43185] New: [F2008] Implicit SAVE in MODULEs
"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 variables end up in static memory. In the most cases, it also makes no difference in diagnostics; however, there is one case. Currently, the following program fails with Error: Object 'a' at (1) must have the SAVE attribute for default initialization of a component module m type t integer :: a = 5 end type t type(t) :: a end module m -- Summary: [F2008] Implicit SAVE in MODULEs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43185
[Bug middle-end/43184] gcc could not vectorize floating point reduction statements
--- 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 too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43184
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- 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 general, Bugzilla is for *bugs* in normal releases, not for tracking the development of the experimental implementation of the ongoing drafts of the new standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- 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
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- 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 CC||chris dot fairles at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug middle-end/43184] gcc could not vectorize floating point reduction statements
--- 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 not be vectorized even with -ffast-math. Do you think this is the problem of fortran frontend? Thanks, -- Changpeng c%3.1 subroutine s311 (ntimes,ld,n,ctime,dtime,a,b,c,d,e,aa,bb,cc) c c reductions c sum reduction c integer ntimes, ld, n, i, nl double precision a(n), b(n), c(n), d(n), e(n), aa(ld,n), + bb(ld,n), cc(ld,n) double precision chksum, sum real t1, t2, second, ctime, dtime call init(ld,n,a,b,c,d,e,aa,bb,cc,'s311 ') t1 = second() do 1 nl = 1,ntimes sum = 0.d0 do 10 i = 1,n sum = sum + a(i) 10 continue call dummy(ld,n,a,b,c,d,e,aa,bb,cc,sum) 1 continue t2 = second() - t1 - ctime - ( dtime * float(ntimes) ) chksum = sum call check (chksum,ntimes*n,n,t2,'s311 ') return end From: pinskia at gcc dot gnu dot org [gcc-bugzi...@gcc.gnu.org] Sent: Thursday, February 25, 2010 5:57 PM To: Fang, Changpeng Subject: [Bug middle-end/43184] gcc could not vectorize floating point reduction statements --- 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 too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43184 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43184
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- 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 better than nothing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug middle-end/43184] gcc could not vectorize floating point reduction statements
--- 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 a fortran program and > found the > the reduction statement. And that is PR 32824 (which I filed awhile back). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43184
[Bug target/43175] __builtin_ia32_vec_perm_v4si doesn't work with -msse4.1
--- 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: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||02/msg01088.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43175
[Bug regression/41204] [4.4/4.5 regression] worse code generated compared to GCC 4.3.2
--- 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 and.l %d3,%d2 add.l %d2,%d0 move.l %d0,%d4 sub.l 24(%sp),%d4 move.l %d4,%d3 add.l %d3,%d3 subx.l %d3,%d3 and.l %d4,%d3 sub.l %d3,%d0 sub.l %d2,%d1 sub.l %d0,%d1 move.l %d1,%d2 add.l %d2,%d2 subx.l %d2,%d2 and.l %d1,%d2 add.l %d2,%d0 movem.l (%sp)+,#28 rts Note the two unwanted move insns are gone. Likely due to IRA work as it eliminated part of regmove and generally gives better register allocations. -- law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41204
[Bug target/27016] [4.3/4.4/4.5 Regression] ARM optimizer produces severely suboptimal code
--- 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 .L3 bx lr .L5: This is probably a direct result of Bernd's work to improve auto-inc addressing modes, particularly the ability to discover them when the memref and increment are in different basic blocks. -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
[Bug tree-optimization/28868] [4.3/4.4 Regression] Not eliminating the PHIs which have the same arguments
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug lto/42453] Assertion `syms' failed in lto-plugin
--- 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
[Bug tree-optimization/43186] New: A loop in tree_unroll_loops_completely never ends
-- 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 org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug tree-optimization/43186] A loop in tree_unroll_loops_completely never ends
--- 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
[Bug fortran/43173] Unnecessary array temporary: Passing contiguous array as actual argument
--- 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? CALL foo ((MAIN__:ot(FULL))) CALL foo ((MAIN__:ot(0_8:5_8:1_8))) CALL foo ((MAIN__:ot(0_8:__convert_i4_i8[[((MAIN__:time_steps))]]))) I was distracted by the convert_i4_i8. Not only does it not appear for the second line but it does not appear at all with -fdefault-integer-8. I will go back and confirm that the tree on my machine at work is clean. Confirmed Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-26 05:28:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43173
[Bug target/43187] New: unnecessary register spill
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:
func:
push{r4, r5, r6, r7, lr}
ldr r4, [r0, #8]
mov r5, r0
ldr r2, [r0, #0]
ldr r6, [r0, #4]
sub sp, sp, #28
ldr r7, [r0, #12]
ldr r3, [r0, #16]
mov r0, r4
cbz r4, .L2
addsr1, r7, r6
movsr0, #100
addsr1, r1, r4
mulsr0, r4, r0
str r2, [sp, #20]// A
str r3, [sp, #16]// B
bl __aeabi_idiv
ldr r2, [sp, #20]// C
ldr r3, [sp, #16]// D
.L2:
str r3, [sp, #4]
mov r1, r2
ldr r3, [r5, #20]
mov r2, r6
str r0, [sp, #8]
ldr r0, .L4
str r3, [sp, #12]
mov r3, r4
str r7, [sp, #0]
bl printf
add sp, sp, #28
pop {r4, r5, r6, r7, pc}
.L5:
.align 2
.L4:
.word .LC0
.size func, .-func
.section.rodata.str1.1,"aMS",%progbits,1
.LC0:
.ascii "%d %d %d %d %d %d %d\000"
Instructions AB spills register r2 and r3 to stack. Instructions CD reloads r2
and r3 from stack. Register r2 contains p->f0, r3 contains p->f4. After
function call to __aeabi_idiv, pointer p is still in register r5. So we can
directly reload r2 and r3 through register r5, avoiding spill them to stack.
--
Summary: unnecessary register spill
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43187
[Bug tree-optimization/43188] New: [4.5 Regression] "error: alignment of array elements is greater than element size"
$ 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: alignment of array elements is
greater than element size"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43188
[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43180
[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- 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)
*** gfc_check_allocated (gfc_expr *array)
*** 537,542
--- 537,550
if (variable_check (array, 0) == FAILURE)
return FAILURE;
+ if (array->expr_type != EXPR_VARIABLE && array->expr_type != EXPR_FUNCTION)
+ {
+ gfc_error ("The argument of '%s' intrinsic at %L is not a variable "
+"or function expression", gfc_current_intrinsic,
+&array->where);
+ return FAILURE;
+ }
+
attr = gfc_variable_attr (array, NULL);
if (!attr.allocatable)
{
OK for trunk with the usual embellishments of ChangeLogs and testcase?
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-02-26 07:35:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug fortran/43185] [F2008] Implicit SAVE in MODULEs
--- 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_initializer (cf. patch in PR 43178). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43185
[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs
--- 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 where
not re-initialized if they were (TREE_)STATIC due to -fmax-stack-var-size=1. I
now check also for is_main_program. (wrong-code)
b) Initializing the static variables in such cases is pointless if one needs to
initialize them explicitly afterwards. (missed optimization - will at least
increase the file size.)
(Note: I build the patch, I have not regtested it, but I think it is very
unlikely that it fails. What I wrote before still holds: The value for the
actual argument to the dummy "dealloc" should be checked - esp. in
trans-openmp.f90.)
Example: Have a look at the dump of. You should not see
static struct t1 x = {.a={-43, -43, ...
static struct t1 y = {.a={-43, -43, ...
but you should see
t1.2.a[S.3 + -1] = -43;
y.b.data = 0B;
t2.0.a[S.1 + -1] = -43;
! { dg-options "-fmax-stack-var-size=1" }
module m
type t1
integer :: a(200) = -43
end type t1
type t2
integer :: a(200) = -43
integer, allocatable :: b(:)
end type t2
contains
subroutine sub()
type(t1) :: x
type(t2) :: y
if (x%a(1) /= -43) call abort()
if (y%a(1) /= -43) call abort()
!if (any (x%a /= -43)) call abort()
!if (any (y%a /= -43)) call abort()
end subroutine sub
end module m
use m
call sub()
call sub()
end
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #19962|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43178
[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- 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 this case. If I try: allocate(foo()) contains function foo() integer, allocatable :: foo end function foo end gfortran already bails out with: Error: Allocate-object at (1) is not a nonprocedure pointer or an allocatable variable > OK for trunk with the usual embellishments of ChangeLogs and testcase? Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that EXPR_VARIABLE is enough. Fortran 2008 has: R631 allocation is allocate-object [ ( allocate-shape-spec-list ) ] [ lbracket allocate-coarray-spec rbracket ] R632 allocate-object is variable-name or structure-component -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
