date:20110803

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #3 from Uros Bizjak  2011-08-03 07:00:12 
UTC ---
Basically, we should allow ZERO_EXTEND in address:

Trying 117 -> 118:
Failed to match this instruction:
(set (mem:SI (zero_extend:DI (plus:SI (mult:SI (reg/v:SI 150 [ n ])
(const_int 4 [0x4]))
(reg/f:SI 189))) [2 MEM[symbol: heap, index: D.2768_17, offset:
4B]+0 S4 A32])
(reg/v:SI 150 [ n ]))

We should emit addr32 in this case.

[Bug fortran/49954] New: ICE assigning concat expression to an array deferred-length string (realloc on assignment)

2011-08-03 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954

   Summary: ICE assigning concat expression to an array
deferred-length string (realloc on assignment)
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Blocks: 45170


Follow up to PR 47674.

The following ICEs in trans-arrays.c's gfc_alloc_allocatable_for_assignment

  tmp = expr2->ts.u.cl->backend_decl;
  gcc_assert (expr1->ts.u.cl->backend_decl);
  tmp = fold_convert (TREE_TYPE (expr1->ts.u.cl->backend_decl), tmp);

My guess is that the first "tmp" is a NULL_TREE.


character(len=:), allocatable :: array_string(:)
array_string = ["ABCDEFGH"]
array_string = array_string // "A"
print '(*(g0))','>',array_string,'<', len(array_string)
end

Also for the following variants:

  array_string // ["A"]
  array_string(1:2) // "A"
  array_string(1:2) // ["A"]

Expected: No ICE, the use of a temporary and the correct result ;-)

[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length

2011-08-03 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674

--- Comment #2 from Tobias Burnus  2011-08-03 
07:23:18 UTC ---
The problem seems to be that for strings, the dependency resolver does not
trigger: as there are no strides, certain dependencies are already handled, but
it fails if the LHS/RHS variables are the same and LHS is reallocated because
of a different (shorter) string length.

dependency.c's gfc_dep_resolver has:

case REF_SUBSTRING:
  /* Substring overlaps are handled by the string assignment code
 if there is not an underlying dependency.  */
  return (fin_dep == GFC_DEP_OVERLAP) ? 1 : 0;

which returns 0 for:

  string = string(1:2) ! Issue: Realloc without temporary

trans-expr.c's alloc_scalar_allocatable_for_assignment handles scalars, where
the value might bet wrong.

A similar issue exists for arrays, though here there are provisions for adding
temporaries. (Cf. also trans-array.c's gfc_alloc_allocatable_for_assignment.)

I am not quite sure whether which if any part should be handled in the
depenedency analysis and which in the assignment code. At least the scalar
assignment code does not seem provide for temporaries at all.


A related issue is PR 49954: ICE with concatenated array strings.

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Richard Guenther  2011-08-03 
08:42:25 UTC ---
Mine then.

[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c

2011-08-03 Thread amonakov at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496

--- Comment #7 from Alexander Monakov  2011-08-03 
09:00:34 UTC ---
(In reply to comment #6)
> Does bootstrap work again?

I haven't checked bootstrap, but the reduced testcase still induces the same
error, and Andreas' gcc-testresults@ mails suggest that bootstrap is still
broken after appearing "fixed" for June 15 - July 13.

[Bug tree-optimization/49955] New: Fails to do partial basic-block SLP

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49955

   Summary: Fails to do partial basic-block SLP
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: i...@gcc.gnu.org


410.bwaves in shell_lam.f has a lot of arrays with inner dimension 5 operated
on in loops that are either unrolled by early unrolling or manually unrolled
in source.  All but one loop in shell_lam.f are not vectorized.

One reason is that basic-block vectorization gives up if it sees
interleaving size that is not a multiple of a supported vectorization
factor.  Testcase:

double a[1024], b[1024];

void foo (int k)
{
  int j;
  a[k*5 + 0] = a[k*5 + 0] + b[k*5 + 0];
  a[k*5 + 1] = a[k*5 + 1] + b[k*5 + 1];
  a[k*5 + 2] = a[k*5 + 2] + b[k*5 + 2];
  a[k*5 + 3] = a[k*5 + 3] + b[k*5 + 3];
  a[k*5 + 4] = a[k*5 + 4] + b[k*5 + 4];
}

taken from the last loop in shell_lam.f which has its innermost loop unrolled
(and loop SLP refuses to vectorize as well, see separate bug).

For the above we get:

t.c:6: note: === vect_analyze_data_ref_accesses ===
t.c:6: note: Detected interleaving of size 5
t.c:6: note: Detected interleaving of size 5
t.c:6: note: Detected interleaving of size 5
t.c:6: note: Vectorizing an unaligned access.
t.c:6: note: Vectorizing an unaligned access.
t.c:6: note: Vectorizing an unaligned access.
t.c:6: note: === vect_analyze_slp ===
t.c:6: note: get vectype with 2 units of type double
t.c:6: note: vectype: vector(2) double
t.c:6: note: Build SLP failed: unrolling required in basic block SLP
t.c:6: note: Failed to SLP the basic block.
t.c:6: note: not vectorized: failed to find SLP opportunities in basic block.

but of course we could simply vectorize with an interleaving size of 4
leaving the excess operations unvectorized (with optimization opportunity
if we can pick a properly sized and aligned set of accesses).

[Bug target/49956] New: [4.7 Regression] FAIL: gfortran.dg/debug/(pr35154-dwarf2.f|pr37738.f) -gdwarf-2 -g3 (internal compiler error) on -apple-darwin

2011-08-03 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49956

   Summary: [4.7 Regression] FAIL:
gfortran.dg/debug/(pr35154-dwarf2.f|pr37738.f)
-gdwarf-2 -g3 (internal compiler error) on
*-apple-darwin*
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ja...@redhat.com
  Host: *-apple-darwin*
Target: *-apple-darwin*
 Build: *-apple-darwin*


Between revisions 176629 and 176671  (see
http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg02685.html and
http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg02727.html ) the following
tests failed on *-apple-darwin*

FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 (internal compiler
error)
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 (test for excess errors)
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
DIE[^\\n]*DW_TAG_common_block
...
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
"m[^\\n]*"[^\\n]*DW_AT_name
FAIL: gfortran.dg/debug/pr37738.f -gdwarf-2 -g3 (internal compiler error)
FAIL: gfortran.dg/debug/pr37738.f -gdwarf-2 -g3 (test for excess errors)
UNRESOLVED: gfortran.dg/debug/pr37738.f scan-assembler-times
DIE[^\\n]*DW_TAG_common_block 3

Revision 176653 seems to be a candidate. The ICE is

[macbook] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f -g3
-gno-strict-dwarf
/opt/gcc/work/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f:14:0: internal
compiler error: in darwin_asm_output_dwarf_offset, at config/darwin.c:2706

and needs -g3 -gno-strict-dwarf. Does the option -gno-strict-dwarf make any
sense on darwin? I thought that darwin is a "strict-dwarf" target.

[Bug tree-optimization/49957] New: Fails to SLP in 410.bwaves

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957

   Summary: Fails to SLP in 410.bwaves
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: s...@gcc.gnu.org, i...@gcc.gnu.org


While the loop

  subroutine shell(nx,ny,nz)
  implicit none
  integer i,j,k,l,nx,ny,nz
  real*8 q(21,nx,ny,nz),dq(21,nx,ny,nz)
  do k=1,nz
 do j=1,ny
do i=1,nx
   do l=1,21
  q(l,i,j,k)=q(l,i,j,k)+dq(l,i,j,k)
   enddo
enddo
 enddo
  enddo
  return
  end

is vectorized using loop vectorization the following variant is not
(as appearing in 410.bwaves):

  subroutine shell(nx,ny,nz)
  implicit none
  integer i,j,k,l,nx,ny,nz
  real*8 q(5,nx,ny,nz),dq(5,nx,ny,nz)
  do k=1,nz
 do j=1,ny
do i=1,nx
   do l=1,5
  q(l,i,j,k)=q(l,i,j,k)+dq(l,i,j,k)
   enddo
enddo
 enddo
  enddo
  return
  end

first of all dependence checking on the innermost unrolled loop fails:

(compute_affine_dependence
  (stmt_a =
D.1639_140 = *q_54[D.1638_139];
)
  (stmt_b =
*q_54[D.1638_157] = D.1647_160;
)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {((pretmp.33_209 + 6) + pretmp.33_213) + offset.5_32, +, 5}_3)
  (chrec_b = {((pretmp.33_209 + 7) + pretmp.33_213) + offset.5_32, +, 5}_3)
(analyze_siv_subscript
siv test failed: unimplemented.
)

as pretmp.33 is signed and we thus do not associate the constant offset
(well, I think this might be the problem at least).

That shouldn't prevent vectorization (and it doesn't).  But then
(probably due to the same reason) we get

t.f:7: note: === vect_analyze_data_ref_accesses ===
t.f:7: note: not consecutive access D.1639_140 = *q_54[D.1638_139];
t.f:7: note: not vectorized: complicated access pattern.
t.f:7: note: bad data access.
t.f:1: note: vectorized 0 loops in function.

so in the end it _does_ seem to be the underlying issue.

I will see what can be done here.

[Bug fortran/49954] ICE assigning concat expression to an array deferred-length string (realloc on assignment)

2011-08-03 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954

--- Comment #1 from Tobias Burnus  2011-08-03 
09:26:09 UTC ---
I thought about something like:

--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7322,8 +7322,8 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
   /* Get the new lhs size in bytes.  */
   if (expr1->ts.type == BT_CHARACTER && expr1->ts.deferred)
 {
-  tmp = expr2->ts.u.cl->backend_decl;
-  gcc_assert (expr1->ts.u.cl->backend_decl);
+  tmp = rss->string_length;
+  gcc_assert (expr1->ts.u.cl->backend_decl && tmp);
   tmp = fold_convert (TREE_TYPE (expr1->ts.u.cl->backend_decl), tmp);
   gfc_add_modify (&fblock, expr1->ts.u.cl->backend_decl, tmp);
 }

However, that yields ".array_length" (i.e. the LHS) even for
  array_string(:)(1:1)
which has the length 1. However, at a glance, gfc_conv_concat_op seems to
properly set "se->string_length = len". Maybe it is not properly called for
rse->string_length?

[Bug target/49956] [4.7 Regression] FAIL: gfortran.dg/debug/(pr35154-dwarf2.f|pr37738.f) -gdwarf-2 -g3 (internal compiler error) on -apple-darwin

2011-08-03 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49956

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-08-03 
09:32:23 UTC ---
I guess you want to define DEBUG_MACRO_SECTION in config/darwin.h, though, as
darwin defaults to -gno-strict-dwarf because of its completely broken debug
info handling tools, it is less urgent.

[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.08.03 09:34:43
   Target Milestone|--- |4.5.4
Summary|Debug stepping behavior |[4.5/4.6/4.7 Regression]
   |regarding g++ Class |Debug stepping behavior
   |destructor has changed for  |regarding g++ Class
   |the worse starting at gcc   |destructor has changed for
   |4.5.0   |the worse starting at gcc
   ||4.5.0
 Ever Confirmed|0   |1
  Known to fail||4.5.3, 4.6.1, 4.7.0

--- Comment #2 from Richard Guenther  2011-08-03 
09:34:43 UTC ---
Confirmed.

The destruction is implemented via a try {} finally where the finally
block seems to get the source location of the construction of the
object rather than the source location of it going out of scope:

int main(int, char**) (int argc, char * * argv)
{
  int D.2623;

  [t.C : 19:5] {
int i;
struct MyClass m;

[t.C : 13:11] i = 1;
[t.C : 14:11] MyClass::MyClass ([t.C : 14] &m);
[t.C : 19:5] try
  {
[t.C : 16:3] if (i == 1) goto ; else goto ;
:
[t.C : 18:37] printf ("Hello world %d\n", i);
goto ;
:
:
  }
finally
  {
[t.C : 14:11] MyClass::~MyClass ([t.C : 14] &m);
  }
  }
  [t.C : 0:0] D.2623 = 0;
  [t.C : 0:0] return D.2623;
}


With 4.4 we still had

int main(int, char**) (int argc, char * * argv)
{
  int D.2628;

  [t.C : 19] {
int i;
struct MyClass m;

[t.C : 13] i = 1;
[t.C : 14] __comp_ctor  ([t.C : 14] &m);
[t.C : 19] try
  {
[t.C : 16] if (i == 1) goto ; else goto ;
:
[t.C : 18] printf (&"Hello world %d\n"[0], i);
goto ;
:
:
  }
finally
  {
[t.C : 19] __comp_dtor  ([t.C : 19] &m);
  }
  }
  [t.C : 0] D.2628 = 0;
  [t.C : 0] return D.2628;
}

So the finally block stmts inherit the try/finally location.

Might be a gimplification or frontend issue.

[Bug fortran/49885] [4.6/4.7 Regression] Segmentation fault when writing to an automatic character array

2011-08-03 Thread domob at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49885

--- Comment #10 from Daniel Kraft  2011-08-03 
09:37:14 UTC ---
Author: domob
Date: Wed Aug  3 09:37:11 2011
New Revision: 177249

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177249
Log:
2011-08-03  Daniel Kraft  

PR fortran/49885
* trans-array.c (gfc_trans_auto_array_allocation): Change
gfc_start_block to gfc_init_block to avoid spurious extra-scope.

2011-08-03  Daniel Kraft  

PR fortran/49885
* gfortran.dg/auto_char_dummy_array_3.f90: New test.

Added:
   
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/auto_char_dummy_array_3.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/trans-array.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/49950] GOT relocation for -fPIE is excessive

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

--- Comment #1 from Richard Guenther  2011-08-03 
09:38:11 UTC ---
But int i is a common, with -fno-common I get no GOTPCREL but what you expect.
Not sure if we need a GOTPCREL for commons or not.

[Bug c++/49949] wrong sign for product of complex and double with -O2

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.08.03 09:40:46
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-03 
09:40:46 UTC ---
An attachment is missing.  Please try to create a small self-contained
testcase using .

[Bug fortran/49885] [4.6/4.7 Regression] Segmentation fault when writing to an automatic character array

2011-08-03 Thread domob at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49885

Daniel Kraft  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Daniel Kraft  2011-08-03 
09:40:40 UTC ---
Backported to 4.6.  Closing the PR now.

[Bug testsuite/48402] autogen fixincludes in GCC 4.6.0 testsuite fails on OS X 10.6.7

2011-08-03 Thread jeru.sheng at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48402

Cheng Sheng  changed:

   What|Removed |Added

 CC||jeru.sheng at gmail dot com

--- Comment #1 from Cheng Sheng  2011-08-03 
09:43:08 UTC ---
I encountered this problem as well in gcc-4.6.1, on Mac OS X 10.7. After some
checking, I found that the source of this error is that "sed" in Linux is
slightly different from "sed" in the POSIX spec (see
http://pubs.opengroup.org/onlinepubs/009695399/utilities/sed.html).
In Linux, the c-command of "sed" can be followed by the text directly, while in
the spec, the c-command should be followed immediately by a backslash, then a
newline, then the text. Therefore, one hack instruction in
gcc-4.6.0/fixinclude/inclhack.def doesn't work:

*
* Part of "inclhack.def" Begins *
*
/*
 * Solaris 10+  is wrapped in #ifndef __cplusplus.  Wrap in
 * extern "C" instead so libstdc++ can use it.
 */
fix = {
hackname  = solaris_complex_cxx;
mach  = "*-*-solaris2.*";
files = complex.h;
sed   = "/#if[ \t]*!defined(__cplusplus)/c"
"#ifdef\t__cplusplus\\\nextern \"C\" {\\\n#endif";
sed   = "/#endif[ \t]*\\/\\* !defined(__cplusplus) \\*\\//c"
"#ifdef\t__cplusplus\\\n}\\\n#endif";
test_text = "#if !defined(__cplusplus)\n"
"#endif /* !defined(__cplusplus) */";
};
***
* Part of "inclhack.def" Ends *
***

A fix would be to replace the "/c" commands of the two "sed"s to "/c\\\n",
i.e.:

--- inclhack.def.bak2011-08-03 17:40:44.0 +0800
+++ inclhack.def2011-08-03 17:40:52.0 +0800
@@ -3315,9 +3315,9 @@
 hackname  = solaris_complex_cxx;
 mach  = "*-*-solaris2.*";
 files = complex.h;
-sed  = "/#if[ \t]*!defined(__cplusplus)/c"
+sed  = "/#if[ \t]*!defined(__cplusplus)/c\\\n"
 "#ifdef\t__cplusplus\\\nextern \"C\" {\\\n#endif";
-sed  = "/#endif[ \t]*\\/\\* !defined(__cplusplus) \\*\\//c"
+sed  = "/#endif[ \t]*\\/\\* !defined(__cplusplus) \\*\\//c\\\n"
 "#ifdef\t__cplusplus\\\n}\\\n#endif";
 test_text = "#if !defined(__cplusplus)\n"
 "#endif/* !defined(__cplusplus) */";

[Bug tree-optimization/49948] ICE with -ftree-parallelize-loops: "address taken, but ADDRESSABLE bit not set"

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.08.03 09:43:32
  Component|rtl-optimization|tree-optimization
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-08-03 
09:43:32 UTC ---
Confirmed.  It looks like some update_stmt is missing (which would set
TREE_ADDRESSABLE when applied to vect_cst_.15_1 = {&l_48, &l_48};).

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

2011-08-03 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773

--- Comment #101 from Paolo Carlini  
2011-08-03 10:02:44 UTC ---
Thanks Marc. Thus, it seems to me that Rainer should have a look to the
fixincludes, double check make sense to him, aren't library bits and should be
sorted out between you two.

Also, the mangling bits should be sent to the attention of the C++ front-end
maintainers, like Jason, can you do that, Marc? Or let me know if I can help...

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #4 from Uros Bizjak  2011-08-03 10:24:17 
UTC ---
(In reply to comment #0)

> Many lea insns can be combined with the load/store insn followed.

I have a patch that generates addr32 prefix. The result:

.file"pr49781.c"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
testl%edi, %edi
jle.L9
subl$1, %edi
leaq4+heap(%rip), %rdx
xorl%eax, %eax
mov%edi, %ecx
addq$1, %rcx
.p2align 4,,10
.p2align 3
.L4:
movl%eax, (%rdx,%rax,4)
addq$1, %rax
cmpq%rcx, %rax
jne.L4
movl%edi, %ecx
.L3:
leaq2288+heap(%rip), %rax
movl$571, %edx
jmp.L6
.p2align 4,,10
.p2align 3
.L10:
leaqheap(%rip), %rcx
movslq%edi, %rsi
subl$1, %edi
movl(%rcx,%rsi,4), %ecx
.L6:
movl4+heap(%rip), %esi
movl%ecx, 4+heap(%rip)
movl%ecx, -4(%rax)
movl%esi, (%rax)
movl%edx, %esi
subq$8, %rax
subl$2, %edx
cmpl$1, %edi
jg.L10
movl%edi, heap_len(%rip)
movl%esi, heap_max(%rip)
ret
.L9:
movlheap(%rip), %ecx
movl$-1, %edi
jmp.L3
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globlmain
.typemain, @function
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$286, %edi
callfoo@PLT
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.sizemain, .-main
.localheap_len
.commheap_len,4,4
.localheap_max
.commheap_max,4,4
.localheap
.commheap,2292,32
.ident"GCC: (GNU) 4.7.0 20110801 (experimental) [trunk revision
176998]"
.section.note.GNU-stack,"",@progbits

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #5 from Uros Bizjak  2011-08-03 10:27:35 
UTC ---
(In reply to comment #4)
> (In reply to comment #0)
> 
> > Many lea insns can be combined with the load/store insn followed.
> 
> I have a patch that generates addr32 prefix. The result:

Er, wrong one (that was -m64). This one is -mx32:

.file"pr49781.c"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
xorl%eax, %eax
testl%edi, %edi
leal4+heap(%rip), %edx
jle.L10
.p2align 4,,10
.p2align 3
.L7:
movl%eax, (%edx,%eax,4)
addl$1, %eax
cmpl%edi, %eax
jne.L7
leal-1(%rdi), %eax
movl%eax, %ecx
.L3:
movl$573, %esi
leal2296+heap(%rip), %r10d
leal2292+heap(%rip), %r9d
lealheap(%rip), %r11d
jmp.L5
.p2align 4,,10
.p2align 3
.L11:
movl(%r11d,%eax,4), %ecx
subl$1, %eax
.L5:
movl4+heap(%rip), %r8d
movl%eax, %edx
subl$2, %esi
subl%edi, %edx
movl%ecx, 4+heap(%rip)
sall$3, %edx
cmpl$1, %eax
movl%r8d, (%r10d,%edx)
movl%ecx, (%r9d,%edx)
jg.L11
movl%eax, heap_len(%rip)
movl%esi, heap_max(%rip)
ret
.L10:
movlheap(%rip), %ecx
xorl%edi, %edi
movl$-1, %eax
jmp.L3
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globlmain
.typemain, @function
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$286, %edi
callfoo@PLT
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.sizemain, .-main
.localheap_len
.commheap_len,4,4
.localheap_max
.commheap_max,4,4
.localheap
.commheap,2292,32
    .ident"GCC: (GNU) 4.7.0 20110803 (experimental) [trunk revision
177229]"
.section.note.GNU-stack,"",@progbits

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #6 from Uros Bizjak  2011-08-03 10:30:39 
UTC ---
Created attachment 24899
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24899
Proposed patch that exploits addr32.

H.J., can you please test this patch on mx32.

The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu {,-m32}.

[Bug target/49473] [arm] poor scheduling of loads

2011-08-03 Thread philb at gnu dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49473

--- Comment #3 from philb at gnu dot org 2011-08-03 10:38:28 UTC ---
(In reply to comment #2)
> This looks like it might be to do with the latency of the call instruction at
> least for the LPIC0 case. The scheduler thinks that r0 isn't ready really till
> cycle 34 or so and hence the compiler can't hoist the mov r5, r0 above the add
> r4, pc, r4 . 

That seems rather peculiar.  The worst case behaviour that the called function
is likely to have would be something like:

ldr r0, [r1]
bx lr

It's possible that the ldr might have a result latency of up to four cycles (if
it were an ARM1136 unaligned access), but the bx will take a minimum of four
cycles even if it was correctly predicted by the return stack and hence the
result latency of the ldr will effectively be annulled.  So, as far as the
scheduler is concerned, it seems as though the result latency of the call
instruction should be considered to be one.

[Bug rtl-optimization/49941] [4.7 Regression] segmentation fault in redirect_jump_2

2011-08-03 Thread amodra at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941

Alan Modra  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch
 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-08/msg00290.htm
   ||l
   Last reconfirmed||2011.08.03 10:44:10
 CC|bernds at codesourcery dot  |
   |com |
 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938

--- Comment #5 from Richard Guenther  2011-08-03 
11:09:39 UTC ---
Author: rguenth
Date: Wed Aug  3 11:09:35 2011
New Revision: 177267

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177267
Log:
2011-08-03  Richard Guenther  

PR tree-optimization/49938
* tree-scalar-evolution.c (interpret_loop_phi): Gracefully
deal with a POLYNOMIAL_CHREC.

* g++.dg/torture/pr49938.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49938.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c

[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2011-08-03 
11:10:34 UTC ---
Fixed.

[Bug tree-optimization/49957] Fails to SLP in 410.bwaves

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.08.03 11:10:57
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-03 
11:10:57 UTC ---
When associating the index expression "properly" it works.

[Bug c++/49952] [C++0x] Unicode literals do not generate errors as prescribed by the FDIS standard

2011-08-03 Thread joseph at codesourcery dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49952

--- Comment #2 from joseph at codesourcery dot com  2011-08-03 11:19:01 UTC ---
C and C++ reference ISO 10646 instead of Unicode, meaning that it is 
natural and proper for the full ISO 10646 range of values to be accepted 
instead of the restricted Unicode range.  N3291 does appear to have this 
restriction on char32_t string (but not character) literals; C1X does not.

[Bug middle-end/49958] New: fold performs invalid association

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49958

   Summary: fold performs invalid association
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


extern void abort (void);
int foo (int i, int j, int o, int m) { return i*o + 1 + j*m > 1; }
int main()
{
  if (foo (- __INT_MAX__ - 1, -1, 1, 1))
abort ();
  return 0;
}

abort()s with -fstrict-overflow even though there is no overflow
involved in INT_MIN + 1 - 1.  But fold re-associates this to
INT_MIN - 1 + 1 which overflows (it does require the two multiplications
to trigger).

[Bug c++/49952] [C++0x] Unicode literals do not generate errors as prescribed by the FDIS standard

2011-08-03 Thread z0sh at sogetthis dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49952

--- Comment #3 from Kerrek SB  2011-08-03 11:36:41 
UTC ---
Maybe it could trigger a warning in -pedantic mode?

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

2011-08-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-08-03 11:37:17 UTC ---
> last part of output:
> ---
> libtool: link: /home/htl10/tmp-build/gcc-446-obj/gcc/gcj
> -B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/
> -B/home/htl10/tmp-build/gcc-446-obj/gcc/ -mieee -g -O2 -o .libs/jv-convert
> --main=gnu.gcj.convert.Convert -shared-libgcc 
> -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs
> -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava
> ./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
> /bin/ld:
> Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 

I've no idea what's going on there: modulo pathname and target triplet
differences, I have exactly the same gcj command line to link
jv-convert.  Could you please manually invoke that command with -v
added, so I can see how exactly collect2 resp. ld is called?

What I do see is that if you add some -W option to ld, you get exactly
the message you observe.  E.g.

ld -G 8 -O3 -S -call_shared -o .libs/jv-convert /usr/lib/cmplrs/cc/crt0.o
-L.libs -L. -L../../gcc -L/usr/lib/cmplrs/cc gnu.gcj.convert.Convertmain.o
./.libs/libgcj.so -lpthread -lrt -rpath /vol/gcc/lib -lgcc_s -lgcc -lgcj -lm
-liconv -lpthread -lrt -lgcc_s -lgcc -lc -lgcc_s -lgcc -Wno-unused
ld:
Invalid flag usage: Wno-unused, -Wx,-option must appear after -_SYSTYPE_SVR4 
ld: Usage: ld [options] file [...]

Do you happen to have some environment variable set to -W?
Though I have found no hint that ld would check for this, it's a
possibility.

Rainer

[Bug middle-end/49958] fold performs invalid association

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49958

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.08.03 11:42:12
 CC||rth at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-03 
11:42:12 UTC ---
Done by

  /* Reassociate (plus (plus (mult) (foo)) (mult)) as
 (plus (plus (mult) (mult)) (foo)) so that we can
 take advantage of the factoring cases below.  */
  if (((TREE_CODE (arg0) == PLUS_EXPR
|| TREE_CODE (arg0) == MINUS_EXPR)
   && TREE_CODE (arg1) == MULT_EXPR)
...

caused by

Tue Aug 24 15:37:03 1999  Richard Henderson  

   * fold-const.c (fold): Reassociate (+ (+ (* a b) c) (* d e))
   as (+ (+ (* a b) (* d e)) c).  Factor a common power-of-two
   multiplicand out of (+ (* a b) (* c d)).

I have a fix.

[Bug rtl-optimization/49941] [4.7 Regression] segmentation fault in redirect_jump_2

2011-08-03 Thread amodra at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941

--- Comment #8 from Alan Modra  2011-08-03 11:48:24 
UTC ---
Author: amodra
Date: Wed Aug  3 11:48:21 2011
New Revision: 177268

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177268
Log:
PR rtl-optimization/49941
* jump.c (mark_jump_label): Comment.
(mark_jump_label_1): Set JUMP_LABEL for return jumps.
* emit-rtl.c (copy_rtx_if_shared_1, copy_insn_1): Leave RETURN shared.
(mark_used_flags): Don't mark RETURN.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/jump.c

[Bug rtl-optimization/49941] [4.7 Regression] segmentation fault in redirect_jump_2

2011-08-03 Thread amodra at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Alan Modra  2011-08-03 11:50:07 
UTC ---
Fixed

[Bug c++/49952] [C++0x] Unicode literals do not generate errors as prescribed by the FDIS standard

2011-08-03 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49952

--- Comment #4 from Paolo Carlini  2011-08-03 
12:00:30 UTC ---
Adding a warning would be easy.

[Bug middle-end/49959] New: ABS pattern is not recognized

2011-08-03 Thread enkovich.gnu at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49959

   Summary: ABS pattern is not recognized
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: enkovich@gmail.com


Created attachment 24900
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24900
Simple test where ABS pattern is not recognized

Here is optimization opportunity for ABS pattern recognizer which does not
catch all cases.

Here is a simple test for ABS computation:

#define ABS(X)(((X)>0)?(X):-(X))
int
test_abs(int *cur)
{
  unsigned long sad = 0;
  sad = ABS(cur[0]);
  return sad;
}

GIMPLE for the test is good (phase optimized):

test_abs (int * cur)
{
  int D.2783;
  int D.2782;

:
  D.2782_3 = *cur_2(D);
  D.2783_4 = ABS_EXPR ;
  return D.2783_4;
}

Now try to make a minor change in test:
#define ABS(X)(((X)>0)?(X):-(X))
int
test_abs(int *cur)
{
  unsigned long sad = 0;
  sad += ABS(cur[0]);
  return sad;
}

GIMPLE becomes worse:

test_abs (int * cur)
{
  int D.2788;
  int D.2787;
  int D.2783;
  long unsigned int iftmp.0;

:
  D.2783_4 = *cur_3(D);
  if (D.2783_4 > 0)
goto ;
  else
goto ;

:
  iftmp.0_6 = (long unsigned int) D.2783_4;
  goto ;

:
  D.2787_8 = -D.2783_4;
  iftmp.0_9 = (long unsigned int) D.2787_8;

:
  # iftmp.0_1 = PHI 
  D.2788_11 = (int) iftmp.0_1;
  return D.2788_11;
}

Compiler used for tests:

Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/export/gcc-build
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.7.0 20110707 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-S' '-mtune=generic'
'-march=x86-64'

[Bug tree-optimization/49959] ABS pattern is not recognized

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49959

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.08.03 12:49:46
  Component|middle-end  |tree-optimization
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-03 
12:49:46 UTC ---
Confirmed.

[Bug tree-optimization/49960] New: inconsistant outputs when enabling autopar for a self -dependence testcase

2011-08-03 Thread razya at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49960

   Summary: inconsistant outputs when enabling autopar for a self
-dependence testcase
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@gcc.gnu.org
CC: rakd...@kam.mff.cuni.cz, seb...@gmail.com
  Host: Linux power7/Linux x86
Target: Linux power7/Linux x86
 Build: Linux power7/Linux x86


Compiling with :
/gcc -O3 -ftree-parallelize-loops=8 -fdump-tree-parloops-details
parallelization-2.c -fno-tree-vectorize

The runs do not always generate the same output:
For example:

> ./a.out 
tmps[1]=1044481
tmps[2]=1044482
tmps[3]=1044483
tmps[4]=1044484
tmps[5]=1044485
tmps[6]=1044486
tmps[7]=1044487
> ./a.out 
tmps[1]=786433
tmps[2]=786434
tmps[3]=786435
tmps[4]=786436
tmps[5]=786437
tmps[6]=786438
tmps[7]=786439

[Bug tree-optimization/49960] inconsistant outputs when enabling autopar for a self -dependence testcase

2011-08-03 Thread razya at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49960

--- Comment #1 from razya at gcc dot gnu.org 2011-08-03 12:54:02 UTC ---
Created attachment 24901
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24901
self dependence testcase

[Bug fortran/49961] New: type bounded function can not return a pointer of a array

2011-08-03 Thread quaintchewster at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49961

   Summary: type bounded function can not return a pointer of a
array
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: quaintchews...@gmail.com


!--- code -


module aa
  type bb
   integer,pointer,dimension(:) :: cc
   integer,pointer :: dd
   contains
 procedure :: getcc
 procedure :: getdd
  end type

  contains
 function getcc(this)  result(cc)
class(bb) :: this
integer,pointer,dimension(:) :: cc
cc => this%cc
 end function

 function getdd(this)  result(dd)
class(bb) :: this
integer,pointer :: dd
dd => this%dd
 end function
end module

program main
  use aa
  implicit none
  type(bb) :: b1
  integer,pointer,dimension(:) :: p1
  integer,pointer :: p2

  allocate(b1%cc(10),b1%dd)
  b1%cc = 10
  b1%dd = 5
  p1 => b1%getcc()   ! Line 34, HERE !!
  write(*,*) 'p1 ',p1(1)
  p2 => b1%getdd()
  write(*,*) 'p2 ',p2
end



!--- code -


2 compile command line and info

$ gfortran -v  -save-temps test_point_arg02.f95
Driving: gfortran -v -save-temps test_point_arg02.f95 -lgfortran -lm
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/f951 test_point_arg02.f95
-quiet -dumpbase test_point_arg02.f95 -mtune=generic -march=x86-64 -auxbase
test_point_arg02 -version -fintrinsic-modules-path
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/finclude -o
test_point_arg02.s
GNU Fortran (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (x86_64-linux-gnu)
compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (x86_64-linux-gnu)
compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test_point_arg02.f95: In function ‘MAIN__’:
test_point_arg02.f95:34:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:551
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/49961] type bounded function can not return a pointer of a array

2011-08-03 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49961

--- Comment #1 from Dominique d'Humieres  2011-08-03 
13:17:42 UTC ---
With gfortran 4.6.1 and trunk, the code compiles and gives at run time

 p1   10
 p25

but I get the ICE with 4.5.3. So the bug has been fixed, but not backported to
4.5.

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #7 from H.J. Lu  2011-08-03 13:26:20 
UTC ---
(In reply to comment #6)
> Created attachment 24899 [details]
> Proposed patch that exploits addr32.
> 
> H.J., can you please test this patch on mx32.
> 
> The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu {,-m32}.

I started it now. Thanks.

[Bug tree-optimization/49948] ICE with -ftree-parallelize-loops: "address taken, but ADDRESSABLE bit not set"

2011-08-03 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-08-03 
13:30:05 UTC ---
I believe this is a bug in execute_update_addresses_taken (well, functions it
calls), because until that function (for parloops pass) c is addressable, but
then when processing
vect_cst_.15_1 = {&c, &c};
stmt it doesn't consider c to be address taken.

[Bug middle-end/49958] fold performs invalid association

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49958

--- Comment #2 from Richard Guenther  2011-08-03 
13:33:31 UTC ---
Author: rguenth
Date: Wed Aug  3 13:33:28 2011
New Revision: 177270

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177270
Log:
2011-08-03  Richard Guenther  

PR middle-end/49958
* fold-const.c (fold_binary_loc): Only associate
(+ (+ (* a b) c) (* d e)) as (+ (+ (* a b) (* d e)) c) if
overflow wraps.

* gcc.dg/torture/pr49958.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr49958.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/49958] fold performs invalid association

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49958

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #3 from Richard Guenther  2011-08-03 
13:37:11 UTC ---
Fixed.

[Bug tree-optimization/49948] ICE with -ftree-parallelize-loops: "address taken, but ADDRESSABLE bit not set"

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Richard Guenther  2011-08-03 
13:38:57 UTC ---
Which means it is a bug in walk_stmt_load_store_addr_ops then (and indeed
that doesn't seem to handle CONSTRUCTOR.

Well.  Mine then.

[Bug target/40819] 32x32->64 - asm code from "longlong.h" is not inlined for 68060's builds

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40819

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Uros Bizjak  2011-08-03 13:41:18 
UTC ---
(In reply to comment #0)

> There is an asm code for 32x32->64 function in the "longlong.h" file which can
> be used for 68060 CPU:

These functions are for internal use only, i.e. in building libgcc.

[Bug tree-optimization/49948] ICE with -ftree-parallelize-loops: "address taken, but ADDRESSABLE bit not set"

2011-08-03 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948

--- Comment #5 from Jakub Jelinek  2011-08-03 
13:44:14 UTC ---
Created attachment 24902
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24902
gcc47-pr49948.patch

Untested patch.

[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721

--- Comment #20 from H.J. Lu  2011-08-03 13:56:05 
UTC ---
(In reply to comment #17)
> H.J., I agree with what you write in comment 16.  But unless we are sure that
> the problematic composition will never be generated (e.g. by ivopts), we 
> cannot
> afford that.

I come to a conclusion that we must transform

ptr_extend:DI (plus:SI (FOO:SI) (const_int Y)))

to

(plus:DI (ptr_extend:DI (FOO:SI)) (const_int Y))

since this this how GCC supports Pmode != ptr_mode. You can
disable it and watch its fallout on HP-UX.  We never run into
it for zero_extend before since x32 is the first zero_extend
target.  We should extend it to zero_extend.

> The patch in comment 7 may have some snafu, but overall it looks very sane. 
> It's just that a const is not being stripped.  Can it be applied on top of the

I tried to strip const with

diff --git a/gcc/explow.c b/gcc/explow.c
index 069a68a..17afbbc 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -380,7 +380,7 @@ convert_memory_address_addr_space_1 (enum machine_mode
to_mode ATTRIBUTE_UNUSED,
 case CONST:
   temp = convert_memory_address_addr_space_1 (to_mode, XEXP (x, 0),
as, no_emit);
-  return temp ? gen_rtx_CONST (to_mode, temp) : temp;
+  return temp && !REG_P (temp) ? gen_rtx_CONST (to_mode, temp) : temp;
   break;

 case PLUS:

and it still has massive failures:

http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00264.html

> x32 branch?  Or do I first have to revert some earlier revision?

The patch in comment 7 is for trunk.

[Bug lto/49922] I try to build libgmp using PGO and lto, but the test will result in "internal compiler error"

2011-08-03 Thread xunxun1982 at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49922

--- Comment #1 from PcX  2011-08-03 14:00:26 UTC 
---
Change to lto component

[Bug tree-optimization/49957] Fails to SLP in 410.bwaves

2011-08-03 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2011-08-03 
14:05:13 UTC ---
Cf. RFC Fortran patch at http://gcc.gnu.org/ml/fortran/2011-08/msg00012.html to
change the index order into the canonical form.

[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721

--- Comment #21 from Uros Bizjak  2011-08-03 14:05:06 
UTC ---
(In reply to comment #20)

> and it still has massive failures:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00264.html

You broke exceptions. Similar problem can be currently seen on alpha, see PR
49688.

[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403

2011-08-03 Thread hjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744

--- Comment #40 from hjl at gcc dot gnu.org  2011-08-03 
14:07:36 UTC ---
Author: hjl
Date: Wed Aug  3 14:07:32 2011
New Revision: 177271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177271
Log:
Add testcases for PR target/47744.

2011-08-03  H.J. Lu  

PR target/47744
* gcc.dg/torture/pr47744-1.c: New.
* gcc.dg/torture/pr47744-2.c: Likewise.
* gcc.dg/torture/pr47744-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47744-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr47744-2.c
trunk/gcc/testsuite/gcc.dg/torture/pr47744-3.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #8 from H.J. Lu  2011-08-03 14:10:25 
UTC ---
(In reply to comment #6)
> Created attachment 24899 [details]
> Proposed patch that exploits addr32.
> 
> H.J., can you please test this patch on mx32.
> 
> The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu {,-m32}.

It failed the testcase for PR 47744, which I just checked in:

[hjl@gnu-33 ilp32-24]$
/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3
-std=gnu99
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c: In
function \u2018matmul_i16\u2019:
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
error: insn does not satisfy its constraints:
(insn 146 66 67 4 (set (reg:TI 0 ax)
(mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:119 ivtmp.30 ]
[119])
(reg:SI 5 di [orig:102 dest_y ] [102]))) [6 MEM[base:
dest_y_18, index: ivtmp.30_63, offset: 0B]+0 S16 A128]))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:34 60
{*movti_internal_rex64}
 (nil))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-33 ilp32-24]$

[Bug fortran/49962] New: "internal compiler error" when using type-bounded function returning vector

2011-08-03 Thread wangmianzhi1 at linuxmail dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962

   Summary: "internal compiler error" when using type-bounded
function returning vector
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wangmianz...@linuxmail.org


Created attachment 24903
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24903
a reduced example

when compiling "reducedcase.f90", a code using type-bounded function returning
vector:
$ gfortran -o reducedcase reducedcase.f90 
reducedcase.f90: In function ‘test’:
reducedcase.f90:18:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:551
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I think this code should be valid according to fortran 2003 standard.
Even if it is not valid, I think better error handling would be good.
many thanks.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 


$ uname -a
Linux mianzhi-laptop 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux

[Bug fortran/49962] "internal compiler error" when using type-bounded function returning vector

2011-08-03 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962

--- Comment #1 from Dominique d'Humieres  2011-08-03 
14:22:47 UTC ---
With gfortran 4.6.1 and trunk, the code compiles and gives at run time

   1   2   3

but I get the ICE with 4.5.3. So the bug has been fixed, but not backported to
4.5.

[Bug fortran/49962] "internal compiler error" when using type-bounded function returning vector

2011-08-03 Thread wangmianzhi1 at linuxmail dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962

--- Comment #2 from wangmianzhi  2011-08-03 
14:24:19 UTC ---
On 2011年08月03日 10:23, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962
>
> --- Comment #1 from Dominique d'Humieres  
> 2011-08-03 14:22:47 UTC ---
> With gfortran 4.6.1 and trunk, the code compiles and gives at run time
>
> 1   2   3
>
> but I get the ICE with 4.5.3. So the bug has been fixed, but not backported to
> 4.5.
>
Thank you for your help very much!

Mianzhi

[Bug tree-optimization/49963] New: ICE: in abs_hwi, at hwint.c:108

2011-08-03 Thread gjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963

   Summary: ICE: in abs_hwi, at hwint.c:108
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
  Host: x86-linux-gnu
Target: avr
 Build: x86-linux-gnu


Observed this ICE in the test suite for 4.7 trunk r177267 after upgrading from
177070:

gcc.c-torture/execute/divconst-2.c: In function 'std_eqn':

gcc.c-torture/execute/divconst-2.c:20:3: internal compiler error: in abs_hwi,
at hwint.c:108


FAIL: gcc.c-torture/execute/divconst-2.c compilation,  -O0  (internal compiler
error)
FAIL: gcc.c-torture/execute/divconst-2.c compilation,  -O1  (internal compiler
error)
FAIL: gcc.c-torture/execute/divconst-2.c compilation,  -O2  (internal compiler
error)
...

== configure 

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2 --disable-lto
Thread model: single
gcc version 4.7.0 20110803 (experimental) (GCC)
GNU C (GCC) version 4.7.0 20110803 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

== hwint.c:abs_hwi() 

hwint.c:abs_hwi() reads

/* Compute the absolute value of X.  */

HOST_WIDE_INT
abs_hwi (HOST_WIDE_INT x)
{
  gcc_checking_assert (x != HOST_WIDE_INT_MIN);
  return x >= 0 ? x : -x;
}

== Backtrace =


#0  fancy_abort (file=0x8890660 "../../../gcc.gnu.org/trunk/gcc/hwint.c",
line=108, function=0x889069b "abs_hwi") at
../../../gcc.gnu.org/trunk/gcc/diagnostic.c:893
#1  0x08395087 in abs_hwi (x=-2147483648) at
../../../gcc.gnu.org/trunk/gcc/hwint.c:108
#2  0x08306e8a in fold_plusminus_mult_expr (loc=2983, code=PLUS_EXPR,
type=0xb7d5d420, arg0=0xb7dcdcb0, arg1=0xb7dce24c) at
../../../gcc.gnu.org/trunk/gcc/fold-const.c:7040
#3  0x082bbef6 in fold_binary_loc (loc=2983, code=PLUS_EXPR, type=0xb7d5d420,
op0=0xb7dcdcb0, op1=0xb7dce24c) at
../../../gcc.gnu.org/trunk/gcc/fold-const.c:9685
#4  0x083174d5 in fold (expr=0xb7dcdccc) at
../../../gcc.gnu.org/trunk/gcc/fold-const.c:13666
#5  0x0813c46c in c_fully_fold_internal (expr=0xb7dcdccc, in_init=0 '\0',
maybe_const_operands=0xbfffdf4b "\001\030", maybe_const_itself=0xbfffde6a
"\001\001ÌÜÜ· ÔÕ·") at ../../../gcc.gnu.org/trunk/gcc/c-family/c-common.c:1238
#6  0x0813d19b in c_fully_fold (expr=0xb7dcdccc, in_init=212 'Ô',
maybe_const=0xbfffdf4b "\001\030") at
../../../gcc.gnu.org/trunk/gcc/c-family/c-common.c:1029
#7  0x080eadcb in build_binary_op (location=2989, code=EQ_EXPR,
orig_op0=0xb7dcdccc, orig_op1=0xb7dce150, convert_p=1) at
../../../gcc.gnu.org/trunk/gcc/c-typeck.c:10172
#8  0x080ef279 in parser_build_binary_op (location=2989, code=EQ_EXPR,
arg1={value = 0xb7dcdccc, original_code = PLUS_EXPR, original_type = 0x0},
arg2={value = 0xb7dce150, original_code = ERROR_MARK, original_type =
0xb7d5d420}) at ../../../gcc.gnu.org/trunk/gcc/c-typeck.c:3218
#9  0x080fbe57 in c_parser_binary_expression (parser=0xb7dcda9c, after=, prec=PREC_NONE) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:5663
#10 0x080fc49f in c_parser_conditional_expression (parser=0xb7dcda9c,
after=0x8000) at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:5330
#11 0x080fc9c8 in c_parser_expr_no_commas (parser=0xb7dcda9c, after=0x8000)
at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:5250
#12 0x080fce68 in c_parser_expression (parser=0xb7d97dd4) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:6716
#13 0x080fe5f3 in c_parser_expression_conv (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:6747
#14 0x080f887a in c_parser_statement_after_labels (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:4416
#15 0x080f997a in c_parser_compound_statement_nostart (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:4147
#16 0x08107852 in c_parser_compound_statement (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:3984
#17 0x080f7fc3 in c_parser_declaration_or_fndef (parser=0xb7dcda9c, fndef_ok=1
'\001', static_assert_ok=, empty_ok=1 '\001', nested=0
'\0', start_attr_ok=, objc_foreach_object_declaration=0x0)
at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:1749
#18 0x081081da in c_parser_external_declaration (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:1354
#19 0x08108a1b in c_parse_file () at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:1242
#20 0x081501b5

[Bug bootstrap/49964] New: Bootstrap failed with AVX turned on

2011-08-03 Thread kirill.yukhin at intel dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964

   Summary: Bootstrap failed with AVX turned on
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirill.yuk...@intel.com


Revision 177268 failed to bootstrap with AVX enabled.

[Bug bootstrap/49964] Bootstrap failed with AVX turned on

2011-08-03 Thread kirill.yukhin at intel dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964

--- Comment #1 from Yukhin Kirill  2011-08-03 
14:28:55 UTC ---
Started from here
http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00051.html

[Bug tree-optimization/49957] Fails to SLP in 410.bwaves

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957

--- Comment #3 from Richard Guenther  2011-08-03 
14:41:49 UTC ---
The patch now makes us vectorize

shell_lam.f:303: note: LOOP VECTORIZED.
shell_lam.f:262: note: LOOP VECTORIZED.
shell_lam.f:205: note: LOOP VECTORIZED.

compared to just

shell_lam.f:262: note: LOOP VECTORIZED.

without.

[Bug middle-end/47383] [x32] ivopts miscompiles Pmode != ptr_mode

2011-08-03 Thread hjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383

--- Comment #17 from hjl at gcc dot gnu.org  2011-08-03 
14:44:59 UTC ---
Author: hjl
Date: Wed Aug  3 14:44:54 2011
New Revision: 177277

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177277
Log:
Add a testcase for PR middle-end/47383.

2011-08-03  H.J. Lu  

PR middle-end/47383
* gcc.dg/torture/pr47383.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47383.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #9 from Uros Bizjak  2011-08-03 14:45:40 
UTC ---
(In reply to comment #8)

> > Created attachment 24899 [details]
> > Proposed patch that exploits addr32.
> > 
> > H.J., can you please test this patch on mx32.
> > 
> > The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu {,-m32}.
> 
> It failed the testcase for PR 47744, which I just checked in:
> 
> [hjl@gnu-33 ilp32-24]$
> /export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3
> -std=gnu99
> /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c
> /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c: In
> function \u2018matmul_i16\u2019:
> /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
> error: insn does not satisfy its constraints:
> (insn 146 66 67 4 (set (reg:TI 0 ax)
> (mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:119 ivtmp.30 ]
> [119])
> (reg:SI 5 di [orig:102 dest_y ] [102]))) [6 MEM[base:
> dest_y_18, index: ivtmp.30_63, offset: 0B]+0 S16 A128]))
> /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:34 60
> {*movti_internal_rex64}
>  (nil))
> /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
> internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> [hjl@gnu-33 ilp32-24]$

Hm, offsetable operand ...

[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721

--- Comment #22 from H.J. Lu  2011-08-03 14:48:09 
UTC ---
(In reply to comment #17)
> H.J., I agree with what you write in comment 16.  But unless we are sure that
> the problematic composition will never be generated (e.g. by ivopts), we 
> cannot
> afford that.

My understanding is ivopts only works on ptr_mode (see PR 47383).

[Bug rtl-optimization/49900] [4.7 regression] ICE in advance_target_bb, at sched-ebb.c:691

2011-08-03 Thread sch...@linux-m68k.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49900

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #4 from Andreas Schwab  2011-08-03 14:49:56 
UTC ---
Works on Babe.

[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC

2011-08-03 Thread ro at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug bootstrap/49740] [4.7 Regression] powerpc native bootstrap with -O3 produces "Bootstrap comparison failure!"

2011-08-03 Thread dougmencken at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740

--- Comment #2 from Douglas Mencken  2011-08-03 
14:56:23 UTC ---
(In reply to comment #1)
> Did it recover?

What shall I try? gcc-4.7-20110730? svn checkout? Some patch? (Nothing has been
attached or reported.)

[Bug libgomp/49965] New: libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC

2011-08-03 Thread ro at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965

   Summary: libgomp.c++/reduction-4.C and libgomp.c++/task-8.C
FAIL on Solaris 11/SPARC
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11


Two new libgomp testcases FAIL on Solaris 11/SPARC:

FAIL: libgomp.c++/reduction-4.C  -O0  execution test

  both 32 and 64-bit

  abort () here:

#3  0x000183b8 in foo () at
/vol/gcc/src/hg/trunk/solaris/libgomp/testsuite/libgomp.c++/reduction-4.C:26

  j = 8, p = inf

  This doesn't happen on Solaris 10/x86.

FAIL: libgomp.c++/task-8.C  -O0  (test for excess errors)
Excess errors:
ld: warning: symbol 'err' has differing types:
(file /var/tmp//ccD0aiQD.o type=OBJT; file /lib/libc.so type=FUNC);
/var/tmp//ccD0aiQD.o definition taken
ld: warning: symbol 'err' has differing types:
(file /var/tmp//ccD0aiQD.o type=OBJT; file /lib/libc.so type=FUNC);

  err() was only introduced in Solaris 11.  Replacing err by error fixes this.

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #10 from Uros Bizjak  2011-08-03 15:01:10 
UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> 
> > > Created attachment 24899 [details]
> > > Proposed patch that exploits addr32.
> > > 
> > > H.J., can you please test this patch on mx32.
> > > 
> > > The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu 
> > > {,-m32}.
> > 
> > It failed the testcase for PR 47744, which I just checked in:
> > 
> > [hjl@gnu-33 ilp32-24]$
> > /export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
> > -B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3
> > -std=gnu99
> > /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c
> > /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c: In
> > function \u2018matmul_i16\u2019:
> > /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
> > error: insn does not satisfy its constraints:
> > (insn 146 66 67 4 (set (reg:TI 0 ax)
> > (mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:119 ivtmp.30 ]
> > [119])
> > (reg:SI 5 di [orig:102 dest_y ] [102]))) [6 MEM[base:
> > dest_y_18, index: ivtmp.30_63, offset: 0B]+0 S16 A128]))
> > /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:34 
> > 60
> > {*movti_internal_rex64}
> >  (nil))
> > /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
> > internal compiler error: in reload_cse_simplify_operands, at 
> > postreload.c:403
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > [hjl@gnu-33 ilp32-24]$
> 
> Hm, offsetable operand ...

This additional patch prevents zero_extend when we deal with
wider-than-word-size moves.  These moves need offsetable_operand, which
zero_extend (...) isn't.

Index: i386.c
===
--- i386.c(revision 177281)
+++ i386.c(working copy)
@@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_
   rtx base, index, disp;
   HOST_WIDE_INT scale;

+  if (GET_CODE (addr) == ZERO_EXTEND
+  && GET_MODE_SIZE (mode) > UNITS_PER_WORD)
+  return false;
+
   if (ix86_decompose_address (addr, &parts) <= 0)
 /* Decomposition failed.  */
 return false;

[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none

2011-08-03 Thread amodra at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |

[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC

2011-08-03 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965

--- Comment #1 from Jakub Jelinek  2011-08-03 
15:10:13 UTC ---
for task-8.C, error is a function on linux, so please replace it by errval
or err_atomic or similar instead if err doesn't work on Solaris.

Fur reduction-4.C, perhaps Solaris long double handling is broken?  The
testcase doesn't use anything complicated, in *.omp_fn* of the long long/long
double version the private f is initialized to +Inf, then in some iterations
set to 9.0 or -2.0 and finally everything is MIN_EXPRed together in a critical
section.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

2011-08-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773

--- Comment #102 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-08-03 15:12:29 UTC ---
> --- Comment #101 from Paolo Carlini  
> 2011-08-03 10:02:44 UTC ---
> Thanks Marc. Thus, it seems to me that Rainer should have a look to the
> fixincludes, double check make sense to him, aren't library bits and should be
> sorted out between you two.

What would help enormously for this would be a complete justification
for the individual fixes:

* Does a standard call for some specific declaration?  If so, which one,
  chapter and verse?

  In such a case, it will be easier get Oracle's attention so the issue
  is also fixed upstream.(If only C++ 2011, it might be a bit of a
  tougher ride.)

* If this is a libstdc++ requirement not currently demanded by a
  standard, would there be an alternative way to fix this inside
  libstdc++?  The reason I'm asking is that the OS headers tend to be a
  moving target, and you may have to keep updating the fix to keep it
  working.

Please keep in mind that my understanding of C++ is minimal, so what may
be obvious to you might not be to me.  I'm not at all opposed to perform
fixincludes fixes, but if there are alternatives, they should at least
be considered.

Thanks.
Rainer

[Bug tree-optimization/49955] Fails to do partial basic-block SLP

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49955

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.08.03 15:12:42
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-03 
15:12:42 UTC ---
The loop that remains after fixing PR49957 in 410.bwaves is the following,
which loop SLP does not handle (well, I'm not exactly sure) because

t.f:18: note: ==> examining statement: t1_62 = *q_61(D)[D.1645_60];

t.f:18: note: num. args = 4 (not unary/binary/ternary op).
t.f:18: note: vect_is_simple_use: operand *q_61(D)[D.1645_60]
t.f:18: note: not ssa-name.
t.f:18: note: use not simple.
t.f:18: note: no array mode for V2DF[5]
t.f:18: note: the size of the group of strided accesses is not a power of 2
t.f:18: note: not vectorized: relevant stmt not supported: t1_62 =
*q_61(D)[D.1645_60];

t.f:18: note: bad operation or unsupported loop bound.
t.f:1: note: vectorized 0 loops in function.

probably the issue that we can't handle this kind of "invariants" in the
SLP group?  Thus, the SLP group should be q(2,..), q(3,...) ... q(5, ...)
which is size 4, q(1,..) should be treated as invariant. 


  subroutine shell(nx,ny,nz,q,dt,cfl,dx,dy,dz)
  implicit none
  integer nx,ny,nz,n,i,j,k
  real*8 cfl,dx,dy,dz,dt
  real*8 gm,Re,Pr,cfll,t1,t2,t3,t4,t5,t6,t7,t8,mu

  real*8 q(5,nx,ny,nz)

C   This particular problem is periodic only


  cfll=0.1d0+(n-1.0d0)*cfl/20.0d0
  if (cfll.ge.cfl) cfll=cfl
  t8=0.0d0

  do k=1,nz
 do j=1,ny
do i=1,nx
   t1=q(1,i,j,k)
   t2=q(2,i,j,k)/t1
   t3=q(3,i,j,k)/t1
   t4=q(4,i,j,k)/t1
   t5=(gm-1.0d0)*(q(5,i,j,k)-0.5d0*t1*(t2*t2+t3*t3+t4*t4))
   t6=dSQRT(gm*t5/t1)
   mu=gm*Pr*(gm*t5/t1)**0.75d0*2.0d0/Re/t1
   t7=((dabs(t2)+t6)/dx+mu/dx**2)**2 +
 1((dabs(t3)+t6)/dy+mu/dy**2)**2 +
 2((dabs(t4)+t6)/dz+mu/dz**2)**2
   t7=DSQRT(t7)
   t8=max(t8,t7)
enddo
 enddo
  enddo
  dt=cfll / t8

  return
  end

[Bug tree-optimization/49957] Fails to SLP in 410.bwaves

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Richard Guenther  2011-08-03 
15:17:42 UTC ---
Mine.

[Bug fortran/49961] type bounded function can not return a pointer of a array

2011-08-03 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49961

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2011-08-03 
15:21:32 UTC ---
Thanks for the report. As it is not a regression, I don't think the fix will be
back-ported. Fortunately, it seems to be fixed in 4.6.x and in the current
developer version 4.7.

For using OOP programming features such as type-bound procedures and
polymorphism, it is best to use GCC 4.6 or 4.7. See http://gcc.gnu.org/wiki/OOP
for an overview of fixed and still unfixed OOP bugs by GCC version.

Maybe Ubuntu also has a newer version, which can be installed besides (or
instead of) the system GCC. If not, Debian has GCC 4.6.1 in Testing/Unstable,
cf.
http://packages.debian.org/search?keywords=gfortran&searchon=names&suite=all§ion=all

Additionally, unofficial nightly builds of GCC are available from
http://gcc.gnu.org/wiki/GFortranBinaries
Those can also be installed without root permissions in some directory.

[Bug fortran/49962] "internal compiler error" when using type-bounded function returning vector

2011-08-03 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  2011-08-03 
15:21:23 UTC ---
Thanks for the report. As it is not a regression, I don't think the fix will be
back-ported. Fortunately, it seems to be fixed in 4.6.x and in the current
developer version 4.7.

For using OOP programming features such as type-bound procedures and
polymorphism, it is best to use GCC 4.6 or 4.7. See http://gcc.gnu.org/wiki/OOP
for an overview of fixed and still unfixed OOP bugs by GCC version.

Maybe Ubuntu also has a newer version, which can be installed besides (or
instead of) the system GCC. If not, Debian has GCC 4.6.1 in Testing/Unstable,
cf.
http://packages.debian.org/search?keywords=gfortran&searchon=names&suite=all§ion=all

Additionally, unofficial nightly builds of GCC are available from
http://gcc.gnu.org/wiki/GFortranBinaries
Those can also be installed without root permissions in some directory.

[Bug middle-end/49946] Thread jumps confuse loop unrolling

2011-08-03 Thread izamyatin at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49946

--- Comment #1 from Igor Zamyatin  2011-08-03 
15:26:57 UTC ---
Used compiler:

Target: x86_64-unknown-linux-gnu
Thread model: posix
gcc version 4.7.0 20110802 (experimental) (GCC)

[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.08.03 15:26:26
 CC||paolo.carlini at oracle dot
   ||com, rth at gcc dot
   ||gnu.org, spop at gcc dot
   ||gnu.org
   Target Milestone|--- |4.7.0
Summary|ICE: in abs_hwi, at |[4.7 Regression] ICE: in
   |hwint.c:108 |abs_hwi, at hwint.c:108
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-03 
15:26:26 UTC ---
Well - as I said.  Here we go.

Please fix :P

[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108

2011-08-03 Thread rguenth at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963

--- Comment #2 from Richard Guenther  2011-08-03 
15:27:36 UTC ---
Probably fails on any 32bit HWI platform.

[Bug c/49966] New: gcc.c-torture/execute/pr45034.c execution timeouts

2011-08-03 Thread howarth at nitro dot med.uc.edu

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49966

   Summary: gcc.c-torture/execute/pr45034.c execution timeouts
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


At r177224  as well as in current gcc trunk, the
gcc.c-torture/execute/pr45034.c execution tests are timing out on
x86_64-apple-darwin11 at -m32 and -m64...

WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O2 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O3 -fomit-frame-pointer 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O3 -g 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -Os 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O2 -flto
-flto-partition=none 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/pr45034.c execution,  -O2 -flto

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

2011-08-03 Thread htl10 at users dot sourceforge.net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #12 from Hin-Tak Leung  
2011-08-03 15:29:50 UTC ---
(In reply to comment #11)
> Did you use an absolute path for the source dir?  There have been
> problems with relative paths in the past.

Tried absolute path with 4.6.1, and compilation finishes alright.

cd /home/htl10/tmp-build
tar jxpvf
../sources/www.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.6.1/gcc-4.6.1.tar.bz2
mkdir gcc-461-obj
cd gcc-461-obj
CONFIG_SHELL=/usr/local/bin/bash /home/htl10/tmp-build/gcc-4.6.1/configure &&
CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make

---

I am running make -k check at the moment but will retry 4.5.3/4.6.0 afterwards.
Note that 4.4.6 fails even with absolute path at a later place.
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947#c14)

So I can probably say this bug was fixed with 4.6.1.

[Bug c/49966] gcc.c-torture/execute/pr45034.c execution timeouts

2011-08-03 Thread howarth at nitro dot med.uc.edu

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49966

--- Comment #1 from Jack Howarth  2011-08-03 
15:31:28 UTC ---
Created attachment 24904
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24904
preprocessed source file for gcc.c-torture/execute/pr45034.c on
x86_64-apple-darwin11

Generated with...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110803/gcc/testsuite/gcc.c-torture/execute/pr45034.c
-w -O2 -lm -m32 -o
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/pr45034.x2
--save-temps

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

2011-08-03 Thread htl10 at users dot sourceforge.net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.6.1

--- Comment #13 from Hin-Tak Leung  
2011-08-03 15:32:31 UTC ---
adding 4.6.1 known to work. pending retrying 4.5.3/4.6.0

[Bug c/49966] gcc.c-torture/execute/pr45034.c execution timeouts

2011-08-03 Thread howarth at nitro dot med.uc.edu

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49966

--- Comment #2 from Jack Howarth  2011-08-03 
15:32:57 UTC ---
Created attachment 24905
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24905
assembly file for gcc.c-torture/execute/pr45034.c on x86_64-apple-darwin11 at
-O2

Created with...

 /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110803/gcc/testsuite/gcc.c-torture/execute/pr45034.c
-w -O2 -lm -m32 -o
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/pr45034.x2
--save-temps

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

2011-08-03 Thread htl10 at users dot sourceforge.net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.6.1

--- Comment #16 from Hin-Tak Leung  
2011-08-03 15:38:30 UTC ---
(In reply to comment #15)

> > Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
> 

> What I do see is that if you add some -W option to ld, you get exactly
> the message you observe.  E.g.

That's stating the obvious... it is essentially what the error message is
complaining ('flags must be ordered in some way")

> Do you happen to have some environment variable set to -W?
> Though I have found no hint that ld would check for this, it's a
> possibility.

No I don't - just tried export |grep W . In any case, 4.6.1 does not show this
problem, so it seems to be fixed in 4.6.1 somehow; and it is *not*
full/relative path related.

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

2011-08-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-08-03 15:42:46 UTC ---
>> > Invalid flag usage: Wl,-rpath, -Wx,-option must appear after 
>> > -_SYSTYPE_SVR4 
>
>> What I do see is that if you add some -W option to ld, you get exactly
>> the message you observe.  E.g.
>
> That's stating the obvious... it is essentially what the error message is
> complaining ('flags must be ordered in some way")

Not really: there's no documented -_SYSTYPE_SVR4 flag, and ld doesn't
accept such a flag at all.  The error message is sort of nonsensical.

>> Do you happen to have some environment variable set to -W?
>> Though I have found no hint that ld would check for this, it's a
>> possibility.
>
> No I don't - just tried export |grep W . In any case, 4.6.1 does not show this
> problem, so it seems to be fixed in 4.6.1 somehow; and it is *not*
> full/relative path related.

Still really strange: I've never seen such a ld message before, building
gcc or otherwise.

Anyway, great that it works for you now.

Rainer

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #11 from H.J. Lu  2011-08-03 15:44:59 
UTC ---
(In reply to comment #10)
> This additional patch prevents zero_extend when we deal with
> wider-than-word-size moves.  These moves need offsetable_operand, which
> zero_extend (...) isn't.
> 
> Index: i386.c
> ===
> --- i386.c(revision 177281)
> +++ i386.c(working copy)
> @@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_
>rtx base, index, disp;
>HOST_WIDE_INT scale;
> 
> +  if (GET_CODE (addr) == ZERO_EXTEND
> +  && GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> +  return false;
> +
>if (ix86_decompose_address (addr, &parts) <= 0)
>  /* Decomposition failed.  */
>  return false;

gcc.dg/torture/pr47744-2.c compiled with

-mx32 -O3 -std=gnu99 -ftree-vectorize -funroll-loops

generates codes  like

leal(%rax,%r9), %r12d
leal(%rax,%rdi), %r10d
mov%r12d, %edx
movq(%r12d), %rbp
movq8(%rdx), %rdx
movq(%r12d), %rax

Many leal aren't necessary.

[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108

2011-08-03 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963

--- Comment #3 from Paolo Carlini  2011-08-03 
15:45:06 UTC ---
Eh, my way of fixing it would be removing the assert ;) Seriously, too bad, I
can try to look a bit into it but help is welcome of course, I don't think the
project wants to rely on my judgment about this vs 49914...

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

2011-08-03 Thread marc.glisse at normalesup dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773

--- Comment #103 from Marc Glisse  
2011-08-03 15:52:09 UTC ---
(In reply to comment #102)
> What would help enormously for this would be a complete justification
> for the individual fixes:

Of course. I tried to keep the fixincludes to the minimum.

One fixes the issue with getc/getchar explained above.

One removes the extern "C++" overloads of bsearch/qsort because of PR 2316 :
Solaris is right to have those, but most compilers (wrongly) don't consider
linkage (C vs C++) as part of the type and thus to them Solaris is defining the
same function twice.

One wraps the declarations of pow(*,int) with #ifdef so that they remain
available in C++03 (Solaris is right to have them, section 26.5.6 of the
standard) but they disappear in C++0X (to match section 26.8.9 of N3291).

The first 2 are necessary. I believe the last one is not required (it should
just cause one minor bug in C++0X) and can be reconsidered later if you prefer.

I haven't tested the version of the fixinclude patch attached to the bug, I was
going to do that once I get access to a Solaris 10 (we have one, but it takes a
while to register so I can use it). I wrote the patch on S11, so I also wanted
to get a look at the S10 headers to check for differences.

>   In such a case, it will be easier get Oracle's attention so the issue
>   is also fixed upstream.(If only C++ 2011, it might be a bit of a
>   tougher ride.)

I guess Oracle will implement C++2011 at some point, no need to push them. The
libstdc++ headers will need adjusting when that happens.

The getc issue is worth reporting upstream though.

> * If this is a libstdc++ requirement not currently demanded by a
>   standard, would there be an alternative way to fix this inside
>   libstdc++?  The reason I'm asking is that the OS headers tend to be a
>   moving target, and you may have to keep updating the fix to keep it
>   working.

I completely agree with this, but it looks hard without fixinclude.

Note that I am not a fixinclude expert and it is possible the fixes could be
written in a less fragile way. And I think one "c_fix_arg" is supposed to be
"select" instead.

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread ubizjak at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #12 from Uros Bizjak  2011-08-03 16:08:47 
UTC ---
(In reply to comment #11)

> gcc.dg/torture/pr47744-2.c compiled with
> 
> -mx32 -O3 -std=gnu99 -ftree-vectorize -funroll-loops
> 
> generates codes  like
> 
> leal(%rax,%r9), %r12d
> leal(%rax,%rdi), %r10d
> mov%r12d, %edx
> movq(%r12d), %rbp
> movq8(%rdx), %rdx
> movq(%r12d), %rax
> 
> Many leal aren't necessary.

This is the tradeof for using offsetable address for DWI operands.

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #13 from H.J. Lu  2011-08-03 16:18:45 
UTC ---
(In reply to comment #10)
> 
> This additional patch prevents zero_extend when we deal with
> wider-than-word-size moves.  These moves need offsetable_operand, which
> zero_extend (...) isn't.
> 
> Index: i386.c
> ===
> --- i386.c(revision 177281)
> +++ i386.c(working copy)
> @@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_
>rtx base, index, disp;
>HOST_WIDE_INT scale;
> 
> +  if (GET_CODE (addr) == ZERO_EXTEND
> +  && GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> +  return false;
> +
>if (ix86_decompose_address (addr, &parts) <= 0)
>  /* Decomposition failed.  */
>  return false;


Doesn't work. I got

FAIL: gcc.dg/graphite/pr35356-2.c (internal compiler error)
FAIL: gcc.dg/graphite/pr35356-2.c (test for excess errors)
FAIL: libgomp.fortran/omp_parse4.f90  -Os  (internal compiler error)
FAIL: libgomp.fortran/omp_parse4.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/gomp/crayptr5.f90  -O  (internal compiler error)
FAIL: gfortran.dg/gomp/crayptr5.f90  -O  (test for excess errors)

so far:

spawn -ignore SIGHUP /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/graphite/pr35356-2.c -O2
-fgraphite-identity -fdump-tree-graphite-all -S -mx32 -o pr35356-2.s^M
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/graphite/pr35356-2.c: In
function 'foo':^M
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/graphite/pr35356-2.c:17:1:
internal compiler error: Segmentation fault^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M
compiler exited with status 1

[Bug c++/49949] wrong sign for product of complex and double with -O2

2011-08-03 Thread begovic79 at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949

--- Comment #2 from Ilker R Capoglu  2011-08-03 
16:20:53 UTC ---
(In reply to comment #1)
> An attachment is missing.  Please try to create a small self-contained
> testcase using .

Sorry, I think it didn't get uploaded because it was above 1000k. I'll try and
get a smaller .ii file.

Thanks!

[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC

2011-08-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-08-03 16:26:45 UTC ---
> --- Comment #1 from Jakub Jelinek  2011-08-03 
> 15:10:13 UTC ---
> for task-8.C, error is a function on linux, so please replace it by errval
> or err_atomic or similar instead if err doesn't work on Solaris.

Sure: I'd have tested that on Linux/x86_64 before submitting anyway.

> Fur reduction-4.C, perhaps Solaris long double handling is broken?  The

Not in general :-)

> testcase doesn't use anything complicated, in *.omp_fn* of the long long/long
> double version the private f is initialized to +Inf, then in some iterations
> set to 9.0 or -2.0 and finally everything is MIN_EXPRed together in a critical
> section.

What I've done is adding a couple of printf's all over
template  void foo (): before the #pragma omp
parallel for, before and after each assignement in the for loop, and
before and after the abort, every time casting the args to long long
resp. long double with matching format strings.  It I initialize i to 0
before the #pragma so I get comparable output, there's no difference in
output between i386-pc-solaris2.10 and sparc-sun-solaris2.11 except for
the abort.

Rainer

[Bug c++/49949] wrong sign for product of complex and double with -O2

2011-08-03 Thread redi at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949

--- Comment #3 from Jonathan Wakely  2011-08-03 
16:27:23 UTC ---
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction is useful

if you can't reduce it then using gzip or bzip2 might make it small enough to
attach

[Bug target/49950] GOT relocation for -fPIE is excessive

2011-08-03 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-08-03 
16:29:48 UTC ---
default_binds_local_p_1 has:
  /* Uninitialized COMMON variable may be unified with symbols
 resolved from other modules.  */
  else if (DECL_COMMON (exp)
   && !resolved_locally
   && (DECL_INITIAL (exp) == NULL
   || DECL_INITIAL (exp) == error_mark_node))
local_p = false;

Now, it depends on what the callers expect.  If they want to figure out if the
decl can't be interposed by other library etc., then the above lines are
unnecessary, but if it wants to find out e.g. if it can trust DECL_INITIAL or
lack thereof of the DECL etc., then the above is needed.  E.g. we use
targetm.binds_local_p to find out if anchoring should be used, for commons it
certainly shouldn't be.

[Bug c++/49949] wrong sign for product of complex and double with -O2

2011-08-03 Thread begovic79 at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949

--- Comment #4 from Ilker R Capoglu  2011-08-03 
16:32:47 UTC ---
(In reply to comment #3)
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction is useful
> 
> if you can't reduce it then using gzip or bzip2 might make it small enough to
> attach

I actually read the instructions very carefully and managed to go through a lot
of it. The problem is that (a) I'm not so familiar with the internals of the
blitz++ library to prune out the crud effectively (b) the STL headers are
buried so deep into blitz++ that it takes a blitz++ developer to take them out.

I'll try to gzip the file and resubmit, though.

[Bug c++/49949] wrong sign for product of complex and double with -O2

2011-08-03 Thread begovic79 at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949

--- Comment #5 from Ilker R Capoglu  2011-08-03 
16:34:31 UTC ---
Created attachment 24906
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24906
The preprocessed file with the STL and blitz++ headers. (bzip2'd)

[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC

2011-08-03 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965

--- Comment #3 from Jakub Jelinek  2011-08-03 
16:37:36 UTC ---
So what values it printed?  Did it print -2.0 and 9.0 in some iterations?
The final merging is done in a critical section between GOMP_atomic_start and
GOMP_atomic_end, perhaps you can put a breakpoint in there and watch how the
values are merged using the MIN_EXPR.
Can you reproduce the failure with OMP_NUM_THREADS=1 BTW?

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #14 from H.J. Lu  2011-08-03 16:47:09 
UTC ---
Created attachment 24907
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24907
A testcase

[hjl@gnu-33 delta]$
/export/build/gnu/gcc-x32-test/release/usr/gcc-4.7.0-x32/bin/gcc -mx32  
-std=gnu99 -fgnu89-inline -O2-S testcase.c

testcase.c:634:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/49967] New: The -static-libstdc++ does not work on HP-UX (IA64 B.11.23, probably others)

2011-08-03 Thread jvb at cyberscience dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49967

   Summary: The -static-libstdc++ does not work on HP-UX (IA64
B.11.23, probably others)
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@cyberscience.com
  Host: HP-UX IA64
Target: HP-UX IA64


The -static-libstdc++ option is silently ignored on HP-IX, IA64 platform.

The reason for this seems to be that g++spec.c relies on HAVE_LD_STATIC_DYNAMIC
from auto-host.h, and if this is not set silently fails to implement
-static-libstdc++.

The HP linker does have options to implement HAVE_LD_STATIC_DYNAMIC, but
configure has not detected them. Presumably this is because they are not the
usual -Bstatic and -Bdynamic, the HP options are -aarchive and -ashared_archive
(not -ashared which disables archive libs completely). Changing auto-host.h to
use:

  #define HAVE_LD_STATIC_DYNAMIC 1
  #define LD_DYNAMIC_OPTION "-ashared_archive"
  #define LD_STATIC_OPTION "-aarchive"

resolves the issue, but of course is not the right fix since this file is
generated. So, this is really a configuration time issue.

As an additional fix though, I would really expect g++ to error or warn if
-static-libstdc++ can't be implemented, instead of silently ignoring. Also it
could provide the archive name to the linker in place of -lstdc++ for systems
where HAVE_LD_STATIC_DYNAMIC really doesn't exist - but possibly if this were
fixed for HP there might not be any systems with this restriction.

[Bug target/49781] [x32] Unnecessary lea in x32 mode

2011-08-03 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

--- Comment #15 from H.J. Lu  2011-08-03 16:49:12 
UTC ---
(In reply to comment #13)
> (In reply to comment #10)
> > 
> > This additional patch prevents zero_extend when we deal with
> > wider-than-word-size moves.  These moves need offsetable_operand, which
> > zero_extend (...) isn't.
> > 
> > Index: i386.c
> > ===
> > --- i386.c(revision 177281)
> > +++ i386.c(working copy)
> > @@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_
> >rtx base, index, disp;
> >HOST_WIDE_INT scale;
> > 
> > +  if (GET_CODE (addr) == ZERO_EXTEND
> > +  && GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> > +  return false;
> > +
> >if (ix86_decompose_address (addr, &parts) <= 0)
> >  /* Decomposition failed.  */
> >  return false;
> 
> 
> Doesn't work. I got
> 
> FAIL: gcc.dg/graphite/pr35356-2.c (internal compiler error)
> FAIL: gcc.dg/graphite/pr35356-2.c (test for excess errors)
> FAIL: libgomp.fortran/omp_parse4.f90  -Os  (internal compiler error)
> FAIL: libgomp.fortran/omp_parse4.f90  -Os  (test for excess errors)
> FAIL: gfortran.dg/gomp/crayptr5.f90  -O  (internal compiler error)
> FAIL: gfortran.dg/gomp/crayptr5.f90  -O  (test for excess errors)

Total regressions:

FAIL: gcc.c-torture/compile/2717-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/2717-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/builtins/strcat.c compilation,  -O1  (internal
compiler error)
FAIL: gcc.c-torture/unsorted/xdi.c,  -O1   (internal compiler error)
FAIL: gcc.dg/graphite/pr35356-2.c (internal compiler error)
FAIL: gcc.dg/graphite/pr35356-2.c (test for excess errors)
FAIL: gcc.dg/torture/pr45636.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/pr45636.c  -O1  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/bounds_check_array_ctor_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/bounds_check_array_ctor_1.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/bounds_check_array_ctor_6.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/bounds_check_array_ctor_6.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/bounds_check_array_ctor_8.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/bounds_check_array_ctor_8.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/character_array_constructor_1.f90  -O1  (internal compiler
error)
FAIL: gfortran.dg/character_array_constructor_1.f90  -O1  (test for excess
errors)
FAIL: gfortran.dg/char_expr_3.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/char_expr_3.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/char_length_3.f90  -O  (internal compiler error)
FAIL: gfortran.dg/char_length_3.f90  -O  (test for excess errors)
FAIL: gfortran.dg/extends_1.f03  -O1  (internal compiler error)
FAIL: gfortran.dg/extends_1.f03  -O1  (test for excess errors)
FAIL: gfortran.dg/g77/7388.f  -O1  (internal compiler error)
FAIL: gfortran.dg/g77/7388.f  -O1  (test for excess errors)
FAIL: gfortran.dg/gomp/crayptr5.f90  -O  (internal compiler error)
FAIL: gfortran.dg/gomp/crayptr5.f90  -O  (test for excess errors)
FAIL: gfortran.dg/namelist_66.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/namelist_66.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_22.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/proc_ptr_22.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_22.f90  -O3 -fomit-frame-pointer  (internal compiler
error)
FAIL: gfortran.dg/proc_ptr_22.f90  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: gfortran.dg/proc_ptr_22.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/proc_ptr_22.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.fortran-torture/execute/where_11.f90,  -Os  (internal compiler
error)
FAIL: gfortran.fortran-torture/execute/where_2.f90,  -Os  (internal compiler
error)
FAIL: libgomp.fortran/omp_parse4.f90  -Os  (internal compiler error)
FAIL: libgomp.fortran/omp_parse4.f90  -Os  (test for excess errors)

1 2 >

1 - 100 of 153 matches

Mail list logo