date:20110123

[Bug rtl-optimization/47420] New: ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread silver24k at gmail dot com

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

   Summary: ICE: in calc_dfs_tree, at dominance.c:395 with c++
code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: silver...@gmail.com


Created attachment 23085
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23085
reduced testcase

gcc version 4.6.0 20110120

$ g++ -c -Os test.cpp / g++ -c -O2 test.cpp
test.cpp: In constructor 'sfTextCtrl::sfTextCtrl(void*)':
test.cpp:55:5: internal compiler error: in calc_dfs_tree, at dominance.c:395
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #28 from Dominique d'Humieres  
2011-01-23 08:44:45 UTC ---
According to http://gcc.gnu.org/ml/gcc-regression/2011-01/msg00375.html
revision 169136 caused a bootstrap failure on powerpc-apple-darwin9.8.0:


/Users/regress/tbox/native/build/./prev-gcc/xgcc
-B/Users/regress/tbox/native/build/./prev-gcc/
-B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/
-B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/
-B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/lib/ -isystem
/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/include -isystem
/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/sys-include-c   -g -O2
-mdynamic-no-pic -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/Users/regress/tbox/svn-gcc/gcc -I/Users/regress/tbox/svn-gcc/gcc/.
-I/Users/regress/tbox/svn-gcc/gcc/../include -I./../intl
-I/Users/regress/tbox/svn-gcc/gcc/../libcpp/include 
-I/Users/regress/tbox/svn-gcc/gcc/../libdecnumber
-I/Users/regress/tbox/svn-gcc/gcc/../libdecnumber/dpd -I../libdecnumber   
/Users/regress/tbox/svn-gcc/gcc/compare-elim.c -o compare-elim.o
/Users/regress/tbox/svn-gcc/gcc/compare-elim.c: In function
'maybe_select_cc_mode':
/Users/regress/tbox/svn-gcc/gcc/compare-elim.c:407:58: error: unused parameter
'b' [-Werror=unused-parameter]
cc1: all warnings being treated as errors

[Bug inline-asm/47419] missed 'mov (base,index,scale),reg' optimization?

2011-01-23 Thread pluto at agmk dot net

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

--- Comment #1 from Pawel Sikora  2011-01-23 09:36:57 
UTC ---
(In reply to comment #0)
> following code...
> 
> unsigned __attribute__((regparm(2)))
> asm_read_mapped_register( unsigned* address, unsigned long index )
> {
> unsigned value;
> asm /* reading has side-effects in hardware */ volatile (
> "movl (%1), %0"
> : /* output operands */ "=r" ( value )
> : /* input operands */ "r" ( address + index )

btw. ^^^ changing "r" to "g" doesn't help.

> : /* clobbers */
> );
> return value;
> }
> 
> produces...
> 
> asm_read_mapped_register:
> leaq (%rdi,%rsi,4), %rax
> movl (%rax), %eax
> ret
> 
> is it a bug in asm inline? why the 'movl (%rdi,%rsi,4),%eax' isn't emitted?

[Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815

2011-01-23 Thread tkoenig at gcc dot gnu.org

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  2011-01-23 
10:10:33 UTC ---
Another test case, from

http://groups.google.com/group/comp.lang.fortran/msg/e6a865eda59e86db?hl=de


module mytypes
   implicit none
   private
   public :: mytype, get_i

   integer, save :: i_priv = 13

   type :: mytype
  integer :: dummy
contains
  procedure, nopass :: i => get_i
   end type mytype

 contains

   pure function get_i () result (i)
 integer :: i
 i = i_priv
   end function get_i

end module mytypes


program test
   use mytypes
   implicit none

   type(mytype) :: a
   type(mytype), parameter :: a_const = mytype (0)

!   integer, dimension (get_i()) :: x! #1
!   integer, dimension (a%i()) :: x  ! #2
   integer, dimension (a_const%i()) :: x! #3

   print *, size (x)

end program test

[Bug inline-asm/47419] missed 'mov (base,index,scale),reg' optimization?

2011-01-23 Thread pinskia at gcc dot gnu.org

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2011-01-23 
10:22:37 UTC ---
Well there is no constraint for reg+reg*N really. You should do:
  asm /* reading has side-effects in hardware */ volatile (
"movl %1, %0"
: /* output operands */ "=r" ( value )
: /* input operands */ "m" ( *(address + index) )
: /* clobbers */
);


This will be the correct way of expressing it and not to mention will produce
the code you want.  Though you might as well just do:
unsigned __attribute__((regparm(2)))
asm_read_mapped_register( unsigned* address, unsigned long index )
{
  volatile *unsigned a = address + index;
  return *a;
}

 CUT -
The constraint r just means register and nothing else can match it.

[Bug fortran/47421] New: Wrong-code: Value of scalar ALLOCATABLE CHARACTER(len=n) dummy is mangled

2011-01-23 Thread burnus at gcc dot gnu.org

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

   Summary: Wrong-code: Value of scalar ALLOCATABLE
CHARACTER(len=n) dummy is mangled
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org, ja...@gcc.gnu.org


The following program outputs
  >1bcde<
  >
rather than the expected
  >1bcde<
  >1bcde<

The problem only occurs for "len=n" using "len=5" or "len=*" works. Also using
a pointer instead of an allocatable works. Or using an array instead of a
scalar.

Found when writing a test case for PR 47339 / PR 43062. Fails with GCC 4.5 and
GCC 4.6 - earlier versions did not have allocatable scalars.


implicit none
character(len=5), allocatable :: str
allocate(str)
str = '1bcde'
print '(">",a,"<")',str
call sub(str,len(str))
contains
  subroutine sub(x,n)
 integer :: n
 character(len=n), allocatable :: x
 print '(">",a,"<")', x
  end subroutine sub
end

[Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #5 from Dominique d'Humieres  2011-01-23 
10:57:05 UTC ---
> Another test case, from ...

It is pr47399.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #29 from Dominique d'Humieres  
2011-01-23 11:17:32 UTC ---
>From http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01607.html  the bootstrap
failure seems rather due to revision 169131. Note that revision 169142
bootstrapped on x86_64-apple-darwin10 configured with
--enable-checking=release.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #30 from Dominique d'Humieres  
2011-01-23 11:43:09 UTC ---
Concerning the timings in comment #27 they may reflect the fact the the inliner
is not aggressive enough for fortran codes and that it is worsen when using
-flto:

For rnflow.f90 I get

26.75s   with -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
26.66s   with -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-finline-limit=600
27.60s   with -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-fwhole-program -flto
27.14s   with -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-finline-limit=600 -fwhole-program -flto
26.79s  with -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-finline-limit=2000 -fwhole-program -flto

The result is more spectacular for fatigue.f90

8.50swith -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-finline-limit=600 -fwhole-program -flto
4.69swith -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-finline-limit=2000 -fwhole-program -flto

Note that revision 169136 seems to require higher values of -finline-limit:
before it, 600 was sufficient to see the speed-up (I have reported that in an
other pr), now it has been increased (I did not tried values lower than 2000
yet).

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #31 from Dominique d'Humieres  
2011-01-23 12:06:00 UTC ---
The relevant pr for comment #30 is pr45810 comment #9. The threshold for
fatigue.f90 was322 before revision 169136 and is now 1520 (~x5).

[Bug inline-asm/47419] missed 'mov (base,index,scale),reg' optimization?

2011-01-23 Thread pluto at agmk dot net

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

--- Comment #3 from Pawel Sikora  2011-01-23 13:02:02 
UTC ---
(In reply to comment #2)
> Well there is no constraint for reg+reg*N really. You should do:
>   asm /* reading has side-effects in hardware */ volatile (
> "movl %1, %0"
> : /* output operands */ "=r" ( value )
> : /* input operands */ "m" ( *(address + index) )
> : /* clobbers */
> );
> 
> 
> This will be the correct way of expressing it and not to mention will produce
> the code you want.

thanks, this assembly with "m" constraint produces one nice move i need.

> Though you might as well just do:
> unsigned __attribute__((regparm(2)))
> asm_read_mapped_register( unsigned* address, unsigned long index )
> {
>   volatile *unsigned a = address + index;
>   return *a;
> }

this access via volatile pointer produces unoptimal lea+mov combo.
i'll stay with improved asm inline.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread hubicka at ucw dot cz

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

--- Comment #33 from Jan Hubicka  2011-01-23 13:15:27 
UTC ---
Please use -fdump-ipa-inline-details to generate the dump.  Perhaps we just
miscompute function body size somehow.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread hubicka at ucw dot cz

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

--- Comment #32 from Jan Hubicka  2011-01-23 13:14:56 
UTC ---
> The relevant pr for comment #30 is pr45810 comment #9. The threshold for
> fatigue.f90 was322 before revision 169136 and is now 1520 (~x5).
Interesting. Do you know what function we fail to inline?
Can you attach ipa-inline dump from both settings?
I know that also c-ray wants to increase inline limits.  I can increase them a
bit,
but not by factor of 5, since that would cause code size explosion at -O3.
(I did some tests on this two weeks ago)

Honza

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread hubicka at ucw dot cz

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

--- Comment #34 from Jan Hubicka  2011-01-23 13:16:34 
UTC ---
Pretty obvoius fix to the compare-elim issue is adding ATTRIBUTE_UNUSED to b
parameter.
It is used by SELECT_CC_MODE macro that is defined to not use it by default.

Honza

[Bug c++/47049] [C++0x] ICE in write_unnamed_type_name with lambda use

2011-01-23 Thread emn13+gcc at nerbonne dot org

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

--- Comment #7 from Eamon Nerbonne  2011-01-23 
13:31:38 UTC ---
(In reply to comment #5)
> it might get analysed sooner if you try to reduce the code to something 
> smaller
> than 7 lines

Yeah, I realize: I've been putting that off, because, well, I don't exactly
grok what the issue is and was hoping someone would say "oh, it's obviously
just XYZ" without having to minimize the test case.

I've tried removing the eigen headers and causing the ICE in a more manageable
bit, but so far the resulting programs compile without ICE, so that's not
helping.

Thanks for the response anyhow - I was wondering whether anyone had spotted the
report at all - I can empathize with feeling that it's not exactly a nice
test-case...

[Bug bootstrap/47422] New: [4.6 regression] bootstrap failure due to warnings in compare-elim.c

2011-01-23 Thread mikpe at it dot uu.se

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

   Summary: [4.6 regression] bootstrap failure due to warnings in
compare-elim.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


Bootstrapping 4.6-20110122 on powerpc64-linux fails with:

/mnt/archive/gcc-4.6-20110122/gcc/compare-elim.c: In function
'maybe_select_cc_mode':
/mnt/archive/gcc-4.6-20110122/gcc/compare-elim.c:407:58: error: unused
parameter 'b' [-Werror=unused-parameter]
cc1: all warnings being treated as errors

make[3]: *** [compare-elim.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod gcj.pod gc-analyze.pod
cpp.pod gfdl.pod gij.pod gcov.pod gfortran.pod fsf-funding.pod gcc.pod
make[3]: Leaving directory `/mnt/archive/objdir46/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/archive/objdir46'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/archive/objdir46'
make: *** [bootstrap] Error 2

The problem is that the rs6000 SELECT_CC_MODE macro ignores its last parameter,
so the 'b' parameter to maybe_select_cc_mode is unused, triggering the error.

Targets without SELECT_CC_MODE (e.g. m68k) also break, see
.

[Bug bootstrap/47422] [4.6 regression] bootstrap failure due to warnings in compare-elim.c

2011-01-23 Thread sch...@linux-m68k.org

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Andreas Schwab  2011-01-23 14:30:08 
UTC ---
Fixed in r169142.

[Bug fortran/47421] Wrong-code: Value of scalar ALLOCATABLE CHARACTER(len=n) dummy is mangled

2011-01-23 Thread burnus at gcc dot gnu.org

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.23 14:45:20
 Ever Confirmed|0   |1

--- Comment #1 from Tobias Burnus  2011-01-23 
14:45:20 UTC ---
sub (character(kind=1)[1:.x] * & restrict x, integer(kind=4) & restrict n,
integer(kind=4) _x)
{
  try
{
  *x = 0B;
  finally
   if (*x != 0B)
  __builtin_free ((void *) *x);

Ups! Why is the argument nullified? And freed at the end?


The issue seems to be related the following in gfc_get_symbol_decl:

  if (sym->ts.type == BT_CHARACTER)
{
  if (TREE_CODE (length) == VAR_DECL
  && DECL_FILE_SCOPE_P (length))
{
  gfc_defer_symbol_init (sym);

and thus to gfc_trans_deferred_vars's

  if (sym->attr.dimension)
  else if (sym->attr.allocatable

   || (sym->ts.type == BT_CLASS
   && CLASS_DATA (sym)->attr.allocatable))
{
  if (!sym->attr.save)
  /* Nullify and automatic deallocation of allocatable
 scalars.  */

Draft patch:

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 254db76..55d2f32 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3304,7 +3304,7 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym,
gfc_wrapped_block * block)
  if (sym_has_alloc_comp && !seen_trans_deferred_array)
gfc_trans_deferred_array (sym, block);
}
-  else if (sym->attr.allocatable
+  else if ((sym->attr.allocatable && !sym->attr.dummy)
   || (sym->ts.type == BT_CLASS
   && CLASS_DATA (sym)->attr.allocatable))
{

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #35 from Dominique d'Humieres  
2011-01-23 15:02:43 UTC ---
> Do you know what function we fail to inline?

It is generalized_hookes_law.

I have looked to fatigue.f90 in more details. With revision 168741, I see the
transitions:

 9.25s for inline-limit < 214
 6.50s for 213 < inline-limit < 322
 4.76s for 321 < inline-limit

With revision 169142, I see

 9.25s for inline-limit < 214
 6.50s for 213 < inline-limit < 322
 8.48s for 321 < inline-limit < 1520
 4.70s for 1519 < nline-limit

Indeed I may have missed other thresholds (especially in the range 322--1519).

I have dumps for values below and above the thresholds (10 of them). Do you
want them all? or only a subset? In the later case which ones?

[Bug rtl-optimization/47420] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.01.23 15:33:35
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-01-23 15:33:35 
UTC ---
Works for me with revision 169143 on Linux/x86.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread howarth at nitro dot med.uc.edu

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

--- Comment #36 from Jack Howarth  2011-01-23 
15:45:19 UTC ---
Created attachment 23086
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23086
bzip2 compressed ipa-inline-details dump without -finline-limit

generated at r169137 on x86_64-apple-darwin10 with...

gfortran -O3 -ffast-math -funroll-loops -fdump-ipa-inline-details -flto
-fwhole-program ../fatigue.f90 -o ../fatigue

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread howarth at nitro dot med.uc.edu

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

--- Comment #37 from Jack Howarth  2011-01-23 
15:47:54 UTC ---
Created attachment 23087
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23087
bzip2 compressed ipa-inline-details dump with -finline-limit=600

bzip2 compressed ipa-inline-details dump with -finline-limit=600

generated at r169137 on x86_64-apple-darwin10 with...

gfortran -O3 -ffast-math -funroll-loops  -finline-limit=600
-fdump-ipa-inline-details -flto
-fwhole-program ../fatigue.f90 -o ../fatigue

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread howarth at nitro dot med.uc.edu

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

--- Comment #38 from Jack Howarth  2011-01-23 
15:49:19 UTC ---
Created attachment 23088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23088
bzip2 compressed ipa-inline-details dump with -finline-limit=2000

generated at r169137 on x86_64-apple-darwin10 with...

gfortran -O3 -ffast-math -funroll-loops  -finline-limit=2000
-fdump-ipa-inline-details -flto
-fwhole-program ../fatigue.f90 -o ../fatigue

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread hubicka at gcc dot gnu.org

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.23 15:59:30
 Ever Confirmed|0   |1

--- Comment #12 from Jan Hubicka  2011-01-23 
15:59:30 UTC ---
Reproduces for me.

Perdida is funcion called once, what happens with default settings is that
perdida is not considered as inline candidate for small function inlining (it
is estimated to over 700 instructions, so it is huge)

later we try to inline it as function called once, but hit large function
growth limit. Compiling with --param large-function-growth=100 solve the
problem, but it does not make the testcase faster.
So problem is elsewhere.

[Bug c++/47049] [C++0x] ICE in write_unnamed_type_name with lambda use

2011-01-23 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.23 16:25:32
 Ever Confirmed|0   |1

--- Comment #8 from Jonathan Wakely  2011-01-23 
16:25:32 UTC ---
Oops, I did mean to confirm this though - I can reproduce it

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #39 from Dominique d'Humieres  
2011-01-23 16:32:38 UTC ---
Created attachment 23089
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23089
-finline-limit=321 revision 168741

bzip2 fatigue.f90.048i.inline generated at revision168741  with -Ofast
-funroll-loops -ftree-loop-linear -fomit-frame-pointer -finline-limit=321
-fwhole-program -flto -fdump-ipa-inline-details

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #40 from Dominique d'Humieres  
2011-01-23 16:33:39 UTC ---
Created attachment 23090
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23090
-finline-limit=322 revision168741

bzip2 fatigue.f90.048i.inline generated at revision168741  with -Ofast
-funroll-loops -ftree-loop-linear -fomit-frame-pointer -finline-limit=322
-fwhole-program -flto -fdump-ipa-inline-details

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #41 from Dominique d'Humieres  
2011-01-23 16:35:02 UTC ---
Created attachment 23091
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23091
-finline-limit=321 revision 169142

bzip2 fatigue.f90.048i.inline generated at revision 169142  with -Ofast
-funroll-loops -ftree-loop-linear -fomit-frame-pointer -finline-limit=321
-fwhole-program -flto -fdump-ipa-inline-details

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #42 from Dominique d'Humieres  
2011-01-23 16:36:00 UTC ---
Created attachment 23092
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23092
-finline-limit=322 revision 169142

bzip2 fatigue.f90.048i.inline generated at revision 169142  with -Ofast
-funroll-loops -ftree-loop-linear -fomit-frame-pointer -finline-limit=322
-fwhole-program -flto -fdump-ipa-inline-details

[Bug c++/47049] [4.5/4.6 Regression] [C++0x] ICE in write_unnamed_type_name with lambda use

2011-01-23 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jason at redhat dot com
   Target Milestone|--- |4.5.3
Summary|[C++0x] ICE in  |[4.5/4.6 Regression]
   |write_unnamed_type_name |[C++0x] ICE in
   |with lambda use |write_unnamed_type_name
   ||with lambda use

--- Comment #9 from H.J. Lu  2011-01-23 16:39:52 
UTC ---
It is caused by revision 152429:

http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00078.html

which implements write_unnamed_type_name.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread hubicka at gcc dot gnu.org

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

--- Comment #13 from Jan Hubicka  2011-01-23 
16:45:23 UTC ---
OK, the slowdown comes away when both hookers_law and perida is inlined.
First needs -finline-limit=380 the second needs large-function-growth=1000
(or large increase of inline limit to make perida to be considered as small
function and inlined before iztaccihuatl grows that much).

Without large-function-growth we fail at:
Considering perdida size 1056.
 Called once from iztaccihuatl 6151 insns.
 Not inlining: --param large-function-growth limit reached.

This is because inlining for functions called once first process read_input:
Considering read_input size 3099.
 Called once from iztaccihuatl 3128 insns.
 Inlined into iztaccihuatl which now has 6151 size for a net change of -76
size.

that makes it too large.

large-function-insns is 2700, large-function-growth is 100%, so iztaccihuatl
can't growth past 3128*2 insns.

We might increase large-function-growth (I will give it a try on our
benchmarks) or we might convince inlined to inline first perida rather than
read_input because perida is smaller...

Honza

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #14 from Dominique d'Humieres  
2011-01-23 17:04:07 UTC ---
After removing the comments, generalized_hookes_law reads

  function generalized_hookes_law (strain_tensor, lambda, mu) result
(stress_tensor)
!
  real (kind = LONGreal), dimension(:,:), intent(in) :: strain_tensor
  real (kind = LONGreal), intent(in) :: lambda, mu
  real (kind = LONGreal), dimension(3,3) :: stress_tensor
  real (kind = LONGreal), dimension(6) ::generalized_strain_vector,
&
 generalized_stress_vector
  real (kind = LONGreal), dimension(6,6) :: generalized_constitutive_tensor
  integer :: i
!
  generalized_constitutive_tensor(:,:) = 0.0_LONGreal
  generalized_constitutive_tensor(1,1) = lambda + 2.0_LONGreal * mu
  generalized_constitutive_tensor(1,2) = lambda
  generalized_constitutive_tensor(1,3) = lambda
  generalized_constitutive_tensor(2,1) = lambda
  generalized_constitutive_tensor(2,2) = lambda + 2.0_LONGreal * mu
  generalized_constitutive_tensor(2,3) = lambda
  generalized_constitutive_tensor(3,1) = lambda
  generalized_constitutive_tensor(3,2) = lambda
  generalized_constitutive_tensor(3,3) = lambda + 2.0_LONGreal * mu
  generalized_constitutive_tensor(4,4) = mu
  generalized_constitutive_tensor(5,5) = mu
  generalized_constitutive_tensor(6,6) = mu
!
  generalized_strain_vector(1) = strain_tensor(1,1)
  generalized_strain_vector(2) = strain_tensor(2,2)
  generalized_strain_vector(3) = strain_tensor(3,3)
  generalized_strain_vector(4) = strain_tensor(2,3)
  generalized_strain_vector(5) = strain_tensor(1,3)
  generalized_strain_vector(6) = strain_tensor(1,2)
!
  do i = 1, 6
  generalized_stress_vector(i) =
dot_product(generalized_constitutive_tensor(i,:),  &   
   
generalized_strain_vector(:))
  end do
!
  stress_tensor(1,1) = generalized_stress_vector(1)
  stress_tensor(2,2) = generalized_stress_vector(2)
  stress_tensor(3,3) = generalized_stress_vector(3)
  stress_tensor(2,3) = generalized_stress_vector(4)
  stress_tensor(1,3) = generalized_stress_vector(5)
  stress_tensor(1,2) = generalized_stress_vector(6)
  stress_tensor(3,2) = stress_tensor(2,3)
  stress_tensor(3,1) = stress_tensor(1,3)
  stress_tensor(2,1) = stress_tensor(1,2)
!
  end function generalized_hookes_law

Note that 24 elements out of the 36 ones of generalized_constitutive_tensor are
null. Using that, the subroutine can be replaced with

  function generalized_hookes_law (strain_tensor, lambda, mu) result
(stress_tensor)
!
  real (kind = LONGreal), dimension(:,:), intent(in) :: strain_tensor
  real (kind = LONGreal), intent(in) :: lambda, mu
  real (kind = LONGreal), dimension(3,3) :: stress_tensor
  real (kind = LONGreal) :: tmp
!
  stress_tensor(:,:) = mu * strain_tensor(:,:)
  tmp = lambda * (strain_tensor(1,1) + strain_tensor(2,2) +
strain_tensor(3,3))
  stress_tensor(1,1) = tmp + 2.0_LONGreal * stress_tensor(1,1)
  stress_tensor(2,2) = tmp + 2.0_LONGreal * stress_tensor(2,2)
  stress_tensor(3,3) = tmp + 2.0_LONGreal * stress_tensor(3,3)
!
  end function generalized_hookes_law

end module perdida_m

which is inlined at -finline-limit=320.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread hubicka at gcc dot gnu.org

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

--- Comment #15 from Jan Hubicka  2011-01-23 
17:56:31 UTC ---
Enabling early FRE
Index: passes.c
===
--- passes.c(revision 169136)
+++ passes.c(working copy)
@@ -760,6 +760,7 @@
  NEXT_PASS (pass_remove_cgraph_callee_edges);
  NEXT_PASS (pass_rename_ssa_copies);
  NEXT_PASS (pass_ccp);
+  NEXT_PASS (pass_fre);
  NEXT_PASS (pass_forwprop);
  /* pass_build_ealias is a dummy pass that ensures that we
 execute TODO_rebuild_alias at this point.  Re-building
@@ -782,7 +783,7 @@

reduces perida size estimate to 694 (so by about 30%) and hookes law to 141 (by
11%). Not enough to make inlining happen, still.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread hubicka at gcc dot gnu.org

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

--- Comment #16 from Jan Hubicka  2011-01-23 
17:57:58 UTC ---
Also w/o inlining hookes_law but with inlining perida (by using
large-function-growth parameter only and the patch abov), I get 30% speedup,
not 50% as with inlining both, but it seems that we miss some optimization that
is independent on inlining w/o early FRE.

[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2011-01-23 Thread howarth at nitro dot med.uc.edu

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

--- Comment #43 from Jack Howarth  2011-01-23 
18:07:36 UTC ---
On x86_64-apple-darwin10 at r169137, the pb05 benchmarks compiled with

benchmark  -O3 -ffast-math -funroll-loops  -O3 -ffast-math -funroll-loops 
%change
   -flto -fwhole-program   -finline-limit=2000 -flto 
   -fwhole-program

ac8.81  7.30  
-17.1
aermod   17.50 17.43   
-0.4
air   5.57  5.57
0.0
capacita 33.35 31.86   
-4.5
channel   1.89  1.76   
-6.9
doduc26.52 25.15   
-5.2
fatigue   8.36  4.21  
-49.6
gas_dyn   4.35  4.28   
-1.6
induct   13.04 13.05
0.1
linpk17.05 17.31
1.5
mdbx 11.26 11.26
0.0
nf   33.50 30.97   
-7.6
protein  32.27 32.62
1.1
rnflow   24.84 24.16   
-2.7
test_fpu  8.20  8.90
8.5
tfft  1.88  1.94
3.2

Geometric11.11 10.42   
-6.2
Mean

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #17 from Dominique d'Humieres  
2011-01-23 19:38:30 UTC ---
With the patch in comment #15 and -finline-limit=300, I get


Date & Time : 23 Jan 2011 20:18:02
Test Name   : pbharness
Compile Command : gfcp %n.f90 -Ofast -funroll-loops -ftree-loop-linear
-fomit-frame-pointer -finline-limit=300 -fwhole-program -flto -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  3.55   54576  8.12   2  0.0062
  aermod103.51 1595448 18.87   2  0.0079
 air  8.87   90048  6.89   2  0.0798
capacita  5.84   89056 40.27   2  0.0199
 channel  1.62   34448  2.98   2  0.0168
   doduc 14.30  203936 27.79   2  0.0162
 fatigue  4.89   89264  4.74   2  0.0106
 gas_dyn 11.72  148176  4.64   5  0.0535
  induct 10.87  205976 14.00   2  0.0036
   linpk  1.58   21536 21.71   2  0.0415
mdbx  5.60   84752 12.56   2  0.1871
  nf  7.24   83712 29.23   5  0.0744
 protein 11.81  163760 35.10   2  0.0342
  rnflow 14.86  171392 26.91   2  0.0223
test_fpu 11.35  145848 11.03   2  0.0952
tfft  1.10   22072  3.30   2  0.1817

Geometric Mean Execution Time =  12.36 seconds

to be compared to the lowest Geometric Mean I have got so far (most of the
difference is due to nf which depends a lot of the mood of my laptop)


Date & Time : 22 Dec 2010 10:33:08
Test Name   : pbharness
Compile Command : gfc %n.f90 -Ofast -funroll-loops -ftree-loop-linear
-fomit-frame-pointer -finline-limit=600 --param hot-bb-frequency-fraction=2000
-fwhole-program -flto -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac 11.55   58672  8.11   2  0.0123
  aermod164.78 1522240 19.11   2  0.1151
 air 20.73   85984  6.87   5  0.1914
capacita 14.66  105472 40.22   2  0.0584
 channel  3.22   34448  2.92   4  0.1714
   doduc 24.70  212360 27.81   2  0.1025
 fatigue  9.81   85144  4.70   3  0.1862
 gas_dyn 24.13  144240  4.66   5  0.4507
  induct 22.50  214136 13.69   2  0.1096
   linpk  2.56   21536 21.68   2  0.0231
mdbx  8.93   84744 12.52   2  0.0080
  nf 22.61  104136 27.63   2  0.0778
 protein 26.19  155768 35.51   2  0.0127
  rnflow 30.99  163200 26.15   2  0.0248
test_fpu 18.79  145848 10.98   2  0.0182
tfft  1.92   22072  3.29   2  0.0304

Geometric Mean Execution Time =  12.27 seconds

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread hubicka at gcc dot gnu.org

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

Jan Hubicka  changed:

   What|Removed |Added

   Last reconfirmed|2011-01-23 15:59:30 |
 CC||rguenther at suse dot de

--- Comment #18 from Jan Hubicka  2011-01-23 
20:00:23 UTC ---
We produce very lousy code for the out of line copy of
__perdida_m_MOD_generalized_hookes_law. This seems to be reason why we inline
it.

Code is bit better with early FRE but still we get in
vect_pgeneralized_constitutive_tensor (optimized dump):

  generalized_constitutive_tensor = {};
  D.4502_45 = *lambda_44(D);
  D.4503_47 = *mu_46(D);
  D.4504_48 = D.4503_47 * 2.0e+0;
  D.4505_49 = D.4504_48 + D.4502_45;
  generalized_constitutive_tensor[0] = D.4505_49;
  generalized_constitutive_tensor[6] = D.4502_45;
  generalized_constitutive_tensor[12] = D.4502_45;
  generalized_constitutive_tensor[1] = D.4502_45;
  generalized_constitutive_tensor[7] = D.4505_49;
  generalized_constitutive_tensor[13] = D.4502_45;
  generalized_constitutive_tensor[2] = D.4502_45;
  generalized_constitutive_tensor[8] = D.4502_45;
  generalized_constitutive_tensor[14] = D.4505_49;
  generalized_constitutive_tensor[21] = D.4503_47;
  generalized_constitutive_tensor[28] = D.4503_47;
  generalized_constitutive_tensor[35] = D.4503_47;

initialize the array with mostly zeros and then we use it in vectorized loop:

  vect_cst_.855_301 = {D.4508_69, D.4508_69};
  vect_cst_.862_295 = {D.4511_73, D.4511_73};
  vect_cst_.870_288 = {D.4514_77, D.4514_77};
  vect_cst_.878_323 = {D.4519_82, D.4519_82};
  vect_cst_.886_330 = {D.4522_86, D.4522_86};
  vect_cst_.894_337 = {D.4526_90, D.4526_90};
  vect_var_.853_205 = MEM[(real(kind=8)[36]
*)&generalized_constitutive_tensor];
  vect_var_.854_210 = vect_var_.853_205 * vect_cst_.855_301;
  vect_var_.860_211 = MEM[(real(kind=8)[36] *)&generalized_constitutive_tensor
+ 48B];
  vect_var_.861_214 = vect_var_.860_211 * vect_cst_.862_295;
  vect_var_.863_215 = vect_var_.861_214 + vect_var_.854_210;
  vect_var_.868_220 = MEM[(real(kind=8)[36] *)&generalized_constitutive_tensor
+ 96B];
  vect_var_.869_221 = vect_var_.868_220 * vect_cst_.870_288;
  vect_var_.871_224 = vect_var_.863_215 + vect_var_.869_221;
  vect_var_.876_225 = MEM[(real(kind=8)[36] *)&generalized_constitutive_tensor
+ 144B];

we would better go with unrolling this and optimizing away 0 terms.
W/o -ftree-vectorize we however still don't do this transform. We end up with:

  generalized_constitutive_tensor = {};
  D.4502_45 = *lambda_44(D);
  D.4503_47 = *mu_46(D);
  D.4504_48 = D.4503_47 * 2.0e+0;
  D.4505_49 = D.4504_48 + D.4502_45;
  generalized_constitutive_tensor[1] = D.4502_45;
  generalized_constitutive_tensor[7] = D.4505_49;
  generalized_constitutive_tensor[13] = D.4502_45;
  generalized_constitutive_tensor[2] = D.4502_45;
  generalized_constitutive_tensor[8] = D.4502_45;
  generalized_constitutive_tensor[14] = D.4505_49;
  generalized_constitutive_tensor[21] = D.4503_47;
  generalized_constitutive_tensor[28] = D.4503_47;
  generalized_constitutive_tensor[35] = D.4503_47;

 pretmp.827_334 = generalized_constitutive_tensor[1];
  pretmp.830_336 = generalized_constitutive_tensor[7];
  pretmp.832_338 = generalized_constitutive_tensor[13];
  pretmp.834_340 = generalized_constitutive_tensor[19];
  pretmp.836_342 = generalized_constitutive_tensor[25];
  pretmp.838_344 = generalized_constitutive_tensor[31];

so copy propagation and SRA are missing. Moreover we can't figure out that
generalized_constitutive_tensor[31] is 0.

So it is quite good testcase for optimization queue ordering.
Honza

[Bug lto/47423] New: Many testsuite failures caused by missing gxx_visibility_sj0

2011-01-23 Thread ktietz at gcc dot gnu.org

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

   Summary: Many testsuite failures caused by missing
gxx_visibility_sj0
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org


By using lto-plugin via ld a lot of testcases failing in g++.dg testsuite as
gxx_visibility_sj0 can be resolved by linker in one-pass linking.
The g++ frontend doesn't add here for LTO linker-plugin case the pass-through
options. For the standard C case this is done in gcc.c in spec.
As COFF targets aren't able to use gold as linker, Ian's additions aren't here
of much help.
So for making things at least consistent, we should either remove from gcc.c
the pass-through part from spec, or add them for other libraries (like gomp,
etc) and for FE specific libraries, too.
Patch for this was sent recent by my to add the pass-through options for C++
FE, which solved that issue.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread hubicka at gcc dot gnu.org

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

Jan Hubicka  changed:

   What|Removed |Added

   Last reconfirmed||2011-01-23 15:59:30

--- Comment #19 from Jan Hubicka  2011-01-23 
21:05:51 UTC ---
This adds enough passes so we generate sane code for hookes_law.
(and we do that before inlining)
Index: passes.c
===
--- passes.c(revision 169136)
+++ passes.c(working copy)
@@ -775,6 +775,14 @@
  NEXT_PASS (pass_convert_switch);
   NEXT_PASS (pass_cleanup_eh);
   NEXT_PASS (pass_profile);
+ NEXT_PASS (pass_tree_loop_init);
+ NEXT_PASS (pass_complete_unroll);
+ NEXT_PASS (pass_tree_loop_done);
+  NEXT_PASS (pass_ccp);
+  NEXT_PASS (pass_fre);
+  NEXT_PASS (pass_dse);
+  NEXT_PASS (pass_fre);
+  NEXT_PASS (pass_cd_dce);
   NEXT_PASS (pass_local_pure_const);
  /* Split functions creates parts that are not run through
 early optimizations again.  It is thus good idea to do this
@@ -782,7 +790,7 @@

We need to unroll the loop, do ccp to get constant array indexes, FRE to
propagate through memory acceses. For some reason FRE is needed twice or the
loads from the temporary array are not copy propagated.

I didn't tested if DSE is really needed or cd_dce gets rid of the dead store
into the array. Still a lot of copyprop oppurtunity is left.

This makes hookes_law estimate to be 91 instructions, so -finline-limit=183
should be enough.

[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

2011-01-23 Thread bernds at gcc dot gnu.org

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

--- Comment #20 from Bernd Schmidt  2011-01-23 
21:11:27 UTC ---
Author: bernds
Date: Sun Jan 23 21:11:24 2011
New Revision: 169144

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169144
Log:
PR rtl-optimization/47166
* reload1.c (emit_reload_insns): Disable the spill_reg_store
mechanism for PRE_MODIFY and POST_MODIFY.
(inc_for_reload): For PRE_MODIFY, return the insn that sets the
reloadreg.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload1.c

[Bug target/47424] New: [4.6 Regression] Glibc miscompiled

2011-01-23 Thread hjl.tools at gmail dot com

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

   Summary: [4.6 Regression] Glibc miscompiled
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, gcc 4.6.0 20110119 miscompiled glibc trunk.
I got

/bin/sh: line 1:  9941 Illegal instruction
GCONV_PATH=/export/build/gnu/glibc/build-x86_64-linux/iconvdata LC_ALL=C
LD_AUDIT=/export/build/gnu/glibc/build-x86_64-linux/elf/tst-auditmod4b.so
/export/build/gnu/glibc/build-x86_64-linux/elf/ld-linux-x86-64.so.2
--library-path
/export/build/gnu/glibc/build-x86_64-linux:/export/build/gnu/glibc/build-x86_64-linux/math:/export/build/gnu/glibc/build-x86_64-linux/elf:/export/build/gnu/glibc/build-x86_64-linux/dlfcn:/export/build/gnu/glibc/build-x86_64-linux/nss:/export/build/gnu/glibc/build-x86_64-linux/nis:/export/build/gnu/glibc/build-x86_64-linux/rt:/export/build/gnu/glibc/build-x86_64-linux/resolv:/export/build/gnu/glibc/build-x86_64-linux/crypt:/export/build/gnu/glibc/build-x86_64-linux/nptl
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-audit4 >
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-audit4.out
/bin/sh: line 1:  9952 Illegal instruction
GCONV_PATH=/export/build/gnu/glibc/build-x86_64-linux/iconvdata LC_ALL=C
LD_AUDIT=/export/build/gnu/glibc/build-x86_64-linux/elf/tst-auditmod7b.so
/export/build/gnu/glibc/build-x86_64-linux/elf/ld-linux-x86-64.so.2
--library-path
/export/build/gnu/glibc/build-x86_64-linux:/export/build/gnu/glibc/build-x86_64-linux/math:/export/build/gnu/glibc/build-x86_64-linux/elf:/export/build/gnu/glibc/build-x86_64-linux/dlfcn:/export/build/gnu/glibc/build-x86_64-linux/nss:/export/build/gnu/glibc/build-x86_64-linux/nis:/export/build/gnu/glibc/build-x86_64-linux/rt:/export/build/gnu/glibc/build-x86_64-linux/resolv:/export/build/gnu/glibc/build-x86_64-linux/crypt:/export/build/gnu/glibc/build-x86_64-linux/nptl
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-audit7 >
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-audit7.out
/bin/sh: line 1:  9951 Illegal instruction
GCONV_PATH=/export/build/gnu/glibc/build-x86_64-linux/iconvdata LC_ALL=C
LD_AUDIT=/export/build/gnu/glibc/build-x86_64-linux/elf/tst-auditmod6b.so:/export/build/gnu/glibc/build-x86_64-linux/elf/tst-auditmod6c.so
/export/build/gnu/glibc/build-x86_64-linux/elf/ld-linux-x86-64.so.2
--library-path
/export/build/gnu/glibc/build-x86_64-linux:/export/build/gnu/glibc/build-x86_64-linux/math:/export/build/gnu/glibc/build-x86_64-linux/elf:/export/build/gnu/glibc/build-x86_64-linux/dlfcn:/export/build/gnu/glibc/build-x86_64-linux/nss:/export/build/gnu/glibc/build-x86_64-linux/nis:/export/build/gnu/glibc/build-x86_64-linux/rt:/export/build/gnu/glibc/build-x86_64-linux/resolv:/export/build/gnu/glibc/build-x86_64-linux/crypt:/export/build/gnu/glibc/build-x86_64-linux/nptl
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-audit6 >
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-audit6.out

Gcc 4.5 is OK.

[Bug fortran/47421] Wrong-code: Value of scalar ALLOCATABLE CHARACTER(len=n) dummy is mangled

2011-01-23 Thread burnus at gcc dot gnu.org

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

--- Comment #2 from Tobias Burnus  2011-01-23 
22:26:35 UTC ---
Author: burnus
Date: Sun Jan 23 22:26:27 2011
New Revision: 169145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169145
Log:
2011-01-23  Tobias Burnus  

PR fortran/47421
* trans-decl.c (gfc_trans_deferred_vars): Do not nullify
scalar allocatable dummy arguments.

2011-01-23  Tobias Burnus  

PR fortran/47421
* gfortran.dg/allocatable_scalar_12.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/47425] New: Array constructor with type-spec: Fails with more complicated length type expr

2011-01-23 Thread burnus at gcc dot gnu.org

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

   Summary: Array constructor with type-spec: Fails with more
complicated length type expr
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/397b3520a4dd1a9f#

James Van Buskirk found an example for an Array constructor with type-spec,
which fails at gimpling. Full example: See c.l.f. Short example:

subroutine sub1(L,s,e)
   implicit none
   character(*) L
   integer s,e
   if(any(L(s:e+1) == [character(len(L(s:e))+1)::'that','those'])) then
   end if
end subroutine sub1

Gives:

test.f90:5:0: error: size of variable 'A.1' is too large

Looking at the dump, one sees that the character length is strangely optimized
away into two uninitialized variables. The dump has:


sub1 (character(kind=1)[1:_l] & restrict l, integer(kind=4) & restrict s,
integer(kind=4) & restrict e, integer(kind=4) _l)
{
  bit_size_type D.1546;
   D.1547;

  D.1546 = (bit_size_type) (() _l * 8);
  D.1547 = () (_l + -1) + 1;
  {
static character(kind=1) A.1[2][1:MAX_EXPR <(D.1541 - D.1540) + 1, 0> + 1]
= {"that", "those"};

and only much later:

D.1540 = *s;
D.1541 = *e;

[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2

2011-01-23 Thread ebotcazou at gcc dot gnu.org

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #9 from Eric Botcazou  2011-01-23 
22:41:06 UTC ---
Yes, the regression is fixed on Solaris, thanks.

[Bug fortran/47421] Wrong-code: Value of scalar ALLOCATABLE CHARACTER(len=n) dummy is mangled

2011-01-23 Thread burnus at gcc dot gnu.org

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Tobias Burnus  2011-01-23 
22:41:09 UTC ---
FIXED on the trunk (4.6) - and too lazy to apply it to 4.5.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

2011-01-23 Thread dominiq at lps dot ens.fr

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

--- Comment #20 from Dominique d'Humieres  
2011-01-23 23:20:34 UTC ---
> This makes hookes_law estimate to be 91 instructions, so -finline-limit=183
> should be enough.

With the patch in comment #19, I rather find a threshold of -finline-limit=256.
In top of that as shown by the timing below the patch increases the threshold
for ac.f90 and breaks the vectorization for induct.f90.

Would the patch in comment #15 and an increase of the default value for
-finline-limit to 300 be acceptable at this stage (with the usual bells and
whisles: SPEC, ...)?


Date & Time : 23 Jan 2011 23:18:23
Test Name   : pbharness
Compile Command : gfcp %n.f90 -Ofast -funroll-loops -ftree-loop-linear
-fomit-frame-pointer -finline-limit=300 -fwhole-program -flto -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  3.15   50536  9.58   2  0.0156
  aermod104.98 1652280 18.79   2  0.1011
 air  8.83   90048  6.99   5  0.7334
capacita  5.95   89056 40.21   2  0.0174
 channel  1.65   34448  2.99   2  0.0502
   doduc 14.59  208056 27.91   2  0.0036
 fatigue  4.80   89264  4.72   2  0.0212
 gas_dyn 11.65  148176  4.66   5  0.4391
  induct 11.20  205976 22.34   2  0.0672
   linpk  1.59   21536 21.70   2  0.0299
mdbx  5.78   84760 12.58   2  0.0119
  nf  7.60   83712 29.53   5  0.3854
 protein 11.69  163760 35.18   2  0.1109
  rnflow 15.23  167296 26.97   2  0.0890
test_fpu 11.33  145848 11.06   5  0.3715
tfft  1.13   22072  3.30   2  0.0607

Geometric Mean Execution Time =  12.89 seconds


Date & Time : 23 Jan 2011 23:54:28
Test Name   : pbharness
Compile Command : gfcp %n.f90 -Ofast -funroll-loops -ftree-loop-linear
-fomit-frame-pointer -finline-limit=600 -fwhole-program -flto -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  3.59   54576  8.10   2  0.0062
  aermod103.73 1558344 18.91   2  0.0238
 air 10.47   89992  6.77   5  0.1563
capacita  7.47  101344 40.08   2  0.0137
 channel  1.65   34448  2.97   5  0.5872
   doduc 15.82  216376 27.61   2  0.
 fatigue  5.10   89264  4.73   2  0.
 gas_dyn 12.09  152264  4.69   5  0.6428
  induct 11.10  205976 22.33   2  0.0403
   linpk  1.59   21536 21.72   2  0.0368
mdbx  5.85   84760 12.58   2  0.0517
  nf 11.34  108280 28.98   2  0.1087
 protein 11.65  163760 35.18   3  0.1422
  rnflow 17.39  183696 26.71   2  0.0243
test_fpu 11.49  145816 11.02   2  0.1226
tfft  1.43   22072  3.29   2  0.0911

Geometric Mean Execution Time =  12.70 seconds

[Bug rtl-optimization/47420] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread silver24k at gmail dot com

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

--- Comment #2 from Yu Simin  2011-01-24 00:57:35 
UTC ---
failed on both mingw32- and arm-none-eabi-,

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/lto-wrapper.exe
Target: mingw32
Configured with: ../../../gcc_trunk/configure --build=x86_64-unknown-linux-gnu
--host=mingw32 --target=mingw32 --prefix=/mingw --disable-win32-registry
--enable-shared --enable-static --enable-libgomp
--enable-version-specific-runtime-libs --with-gmp=/mingw --with-mpfr=/mingw
--with-ppl=/mingw --with-cloog=/mingw --enable-libstdcxx-debug
--with-build-time-tools=/platform/cross-on-linux/mingw --disable-nls
--with-mpc=/mingw --enable-languages=c,c++ --enable-lto --disable-plugin
--enable-checking=release --enable-sjlj-exceptions --enable-cloog-backend=isl
--disable-cloog-version-check
Thread model: win32
gcc version 4.6.0 20110123 (experimental)
COLLECT_GCC_OPTIONS='-c' '-O2' '-v' '-mtune=generic' '-march=pentiumpro'
 c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/cc1plus.exe -quiet -v
-iprefix c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/ -D__MSVCRT_DLL__
PR47420_ICE.cpp -quiet -dumpbase PR47420_ICE.cpp -mtune=generic
-march=pentiumpro -auxbase PR47420_ICE -O2 -version -o D:\Temp\ccN8BzbK.s
GNU C++ version 4.6.0 20110123 (experimental) (mingw32)
compiled by GNU C version 4.6.0 20110123 (experimental), GMP version 5.0.1,
MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../mingw32/include"
ignoring duplicate directory
"c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++"
ignoring duplicate directory
"c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/mingw32"
ignoring duplicate directory
"c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/backward"
ignoring duplicate directory
"c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include"
ignoring nonexistent directory "/mingw/include"
ignoring duplicate directory "c:/snowfishroot/mingw/lib/gcc/../../include"
ignoring duplicate directory
"c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include-fixed"
ignoring nonexistent directory
"c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include/c++
 c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include/c++/mingw32
 c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include/c++/backward
 c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include
 c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include
 c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include-fixed
End of search list.
GNU C++ version 4.6.0 20110123 (experimental) (mingw32)
compiled by GNU C version 4.6.0 20110123 (experimental), GMP version 5.0.1,
MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 950018fa43a5603ab5e33743958395b0
PR47420_ICE.cpp: In function 'sfTextCtrl* CreateTextCtrl()':
PR47420_ICE.cpp:66:13: internal compiler error: in calc_dfs_tree, at
dominance.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.



Using built-in specs.
COLLECT_GCC=arm-gcc
COLLECT_LTO_WRAPPER=c:/snowfishroot/share/sdk/crosssdk/bin/../libexec/gcc/arm/4.6.0/lto-wrapper.exe
Target: arm
Configured with: ../../../gcc_trunk/configure --host=mingw32
--build=x86_64-unknown-linux-gnu --target=arm --prefix=/CROSSSDK
--with-local-prefix=/CROSSSDK/vendor --enable-version-specific-runtime-libs
--disable-threads --disable-tls --disable-nls --enable-multilib --with-newlib
--with-headers=/home/starlight/src/gnu-toolchain/newlib/newlib/libc/include
--with-pkgversion='General ARM GCC' --enable-languages=c,c++
--enable-checking=release --with-gmp=/mingw --with-mpfr=/mingw
--with-ppl=/mingw --with-cloog=/mingw
--with-libelf=/platform/cross-on-linux/mingw/gcc_build_support_libelf
--with-mpc=/mingw --disable-plugin --disable-libstdcxx-pch
--enable-cloog-backend=isl --disable-cloog-version-check
Thread model: single
gcc version 4.6.0 20110123 (experimental) (General ARM GCC) 
COLLECT_GCC_OPTIONS='-c' '-O2' '-v'
 c:/snowfishroot/share/sdk/crosssdk/bin/../libexec/gcc/arm/4.6.0/cc1plus.exe
-quiet -v -iprefix c:\snowfishroot\share\sdk\crosssdk\bin\../lib/gcc/arm/4.6.0/
-D__USES_INITFINI__ PR47420_ICE.cpp -quiet -dumpbase PR47

[Bug rtl-optimization/47420] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread silver24k at gmail dot com

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

--- Comment #3 from Yu Simin  2011-01-24 00:58:58 
UTC ---
(In reply to comment #2)
> failed on both mingw32- and arm-none-eabi-,
> 
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/lto-wrapper.exe
> Target: mingw32
> Configured with: ../../../gcc_trunk/configure --build=x86_64-unknown-linux-gnu
> --host=mingw32 --target=mingw32 --prefix=/mingw --disable-win32-registry
> --enable-shared --enable-static --enable-libgomp
> --enable-version-specific-runtime-libs --with-gmp=/mingw --with-mpfr=/mingw
> --with-ppl=/mingw --with-cloog=/mingw --enable-libstdcxx-debug
> --with-build-time-tools=/platform/cross-on-linux/mingw --disable-nls
> --with-mpc=/mingw --enable-languages=c,c++ --enable-lto --disable-plugin
> --enable-checking=release --enable-sjlj-exceptions --enable-cloog-backend=isl
> --disable-cloog-version-check
> Thread model: win32
> gcc version 4.6.0 20110123 (experimental)
> COLLECT_GCC_OPTIONS='-c' '-O2' '-v' '-mtune=generic' '-march=pentiumpro'
>  c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/cc1plus.exe -quiet -v
> -iprefix c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/ -D__MSVCRT_DLL__
> PR47420_ICE.cpp -quiet -dumpbase PR47420_ICE.cpp -mtune=generic
> -march=pentiumpro -auxbase PR47420_ICE -O2 -version -o D:\Temp\ccN8BzbK.s
> GNU C++ version 4.6.0 20110123 (experimental) (mingw32)
> compiled by GNU C version 4.6.0 20110123 (experimental), GMP version 
> 5.0.1,
> MPFR version 3.0.0-p3, MPC version 0.8.2
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> ignoring nonexistent directory
> "c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../mingw32/include"
> ignoring duplicate directory
> "c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++"
> ignoring duplicate directory
> "c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/mingw32"
> ignoring duplicate directory
> "c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/backward"
> ignoring duplicate directory
> "c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include"
> ignoring nonexistent directory "/mingw/include"
> ignoring duplicate directory "c:/snowfishroot/mingw/lib/gcc/../../include"
> ignoring duplicate directory
> "c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/include-fixed"
> ignoring nonexistent directory
> "c:/snowfishroot/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.0/../../../../mingw32/include"
> ignoring nonexistent directory "/mingw/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include/c++
>  c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include/c++/mingw32
>  c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include/c++/backward
>  c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include
>  c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include
>  c:\snowfishroot\mingw\bin\../lib/gcc/mingw32/4.6.0/include-fixed
> End of search list.
> GNU C++ version 4.6.0 20110123 (experimental) (mingw32)
> compiled by GNU C version 4.6.0 20110123 (experimental), GMP version 
> 5.0.1,
> MPFR version 3.0.0-p3, MPC version 0.8.2
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> Compiler executable checksum: 950018fa43a5603ab5e33743958395b0
> PR47420_ICE.cpp: In function 'sfTextCtrl* CreateTextCtrl()':
> PR47420_ICE.cpp:66:13: internal compiler error: in calc_dfs_tree, at
> dominance.c:395
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> 
> 
> Using built-in specs.
> COLLECT_GCC=arm-gcc
> COLLECT_LTO_WRAPPER=c:/snowfishroot/share/sdk/crosssdk/bin/../libexec/gcc/arm/4.6.0/lto-wrapper.exe
> Target: arm
> Configured with: ../../../gcc_trunk/configure --host=mingw32
> --build=x86_64-unknown-linux-gnu --target=arm --prefix=/CROSSSDK
> --with-local-prefix=/CROSSSDK/vendor --enable-version-specific-runtime-libs
> --disable-threads --disable-tls --disable-nls --enable-multilib --with-newlib
> --with-headers=/home/starlight/src/gnu-toolchain/newlib/newlib/libc/include
> --with-pkgversion='General ARM GCC' --enable-languages=c,c++
> --enable-checking=release --with-gmp=/mingw --with-mpfr=/mingw
> --with-ppl=/mingw --with-cloog=/mingw
> --with-libelf=/platform/cross-on-linux/mingw/gcc_build_support_libelf
> --with-mpc=/mingw --disable-plugin --d

[Bug rtl-optimization/47420] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread silver24k at gmail dot com

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

Yu Simin  changed:

   What|Removed |Added

 Target||mingw32

--- Comment #4 from Yu Simin  2011-01-24 01:07:01 
UTC ---
I will rebuild a clean version to verify this these days.

[Bug tree-optimization/47426] New: [4.6 Regression] wrong code with -O2 -fipa-pta

2011-01-23 Thread zsojka at seznam dot cz

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

   Summary: [4.6 Regression] wrong code with -O2 -fipa-pta
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: rgue...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23093
foo.c

Output:
$ gcc main.c foo.c -O2
$ ./a.out


$ gcc main.c foo.c -O2 -fipa-pta
$ ./a.out 
Aborted

foo.c is miscompiled


I don't know if this should be marked as regression.

Tested revisions:
r169143 - fail

[Bug tree-optimization/47426] [4.6 Regression] wrong code with -O2 -fipa-pta

2011-01-23 Thread zsojka at seznam dot cz

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

--- Comment #1 from Zdenek Sojka  2011-01-24 02:05:12 
UTC ---
Created attachment 23094
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23094
main.c

[Bug web/45785] Bugzilla search sometimes fails with an internal error

2011-01-23 Thread zsojka at seznam dot cz

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

Zdenek Sojka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #7 from Zdenek Sojka  2011-01-24 02:12:08 
UTC ---
I haven't seen an internal error for long time now.
Also, now I search with all fields unselected, instead of all selected.

[Bug rtl-optimization/47420] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread silver24k at gmail dot com

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

--- Comment #5 from Yu Simin  2011-01-24 02:42:34 
UTC ---
If I added the '-fno-exceptions' flag, the ICE disappearsed. My g++ is built
with SJLJ exception support. I think both Linux/x86 and arm-none-eabi are using
DW exception.

[Bug rtl-optimization/47420] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code

2011-01-23 Thread silver24k at gmail dot com

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

--- Comment #6 from Yu Simin  2011-01-24 03:11:24 
UTC ---
(In reply to comment #5)
> If I added the '-fno-exceptions' flag, the ICE disappearsed. My g++ is built
> with SJLJ exception support. I think both Linux/x86 and arm-none-eabi are 
> using
> DW exception.

I rebuilt a version with '--disable-sjlj-exceptions --with-dwarf2', but the ICE
still exists. Maybe it's mingw32 only?

[Bug c/47427] New: ICE in process_constraint, at tree-ssa-structalias.c:2901

2011-01-23 Thread regehr at cs dot utah.edu

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

   Summary: ICE in process_constraint, at
tree-ssa-structalias.c:2901
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


[regehr@gamow tmp443]$ current-gcc -c -O3 small.c

small.c: In function 'foo':
small.c:20:6: internal compiler error: in process_constraint, at
tree-ssa-structalias.c:2901
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[regehr@gamow tmp443]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r169143-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r169143-install
--program-prefix=r169143- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110123 (experimental) (GCC) 

[regehr@gamow tmp443]$ cat small.c


long g_128;
int *g;

int func_73 (unsigned char p_74, const int p_75)
{
 lbl_159:for (; g_128; g = (int *)g_128)
for (g = 0; g_128; g_128++)
  {
int l_144 = 1;
if (g_128)
  {
if (l_144)
  goto lbl_159;
return p_75;
  }
  }
  return p_74;
}

void foo (void)
{
  if (func_73 (0, 1))
func_73 (1, 0);
}

[Bug c/47428] New: ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986

2011-01-23 Thread regehr at cs dot utah.edu

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

   Summary: ICE: tree check: expected ssa_name, have integer_cst
in copy_phis_for_bb, at tree-inline.c:1986
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


[regehr@gamow tmp444]$ current-gcc -c -O3 small.c

small.c: In function 'foo':
small.c:22:12: internal compiler error: tree check: expected ssa_name, have
integer_cst in copy_phis_for_bb, at tree-inline.c:1986
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[regehr@gamow tmp444]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r169143-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r169143-install
--program-prefix=r169143- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110123 (experimental) (GCC) 

[regehr@gamow tmp444]$ cat small.c


struct S2
{
  int f6;
};

int g_65;

struct S2 g_180;

void func_121 (struct S2 p_122);

int func_56 (int p_58, int p_59)
{
  int i;
  for (i = 0; i < 1; i = 1)
for (p_59 = 0; p_59 < 1; p_59 = 1);
  return p_59;
}

void foo (void)
{
  func_106 (0);
}

int func_106 (const int p_107, int p_108)
{
  if (func_56 (func_56 (0, p_107), 0))
return 0;
  else
func_121 (g_180);
  return 0;
}

void func_121 (struct S2 p_122)
{
  for (0; 1; 0)
for (; p_122.f6;)
  g_65 = 0 ? : func_56 (0,0);
}

[Bug c++/47429] New: -Wfatal-errors hiding line number of offending caller

2011-01-23 Thread navin.kumar at gmail dot com

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

   Summary: -Wfatal-errors hiding line number of offending caller
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: navin.ku...@gmail.com


When compiling with -Wfatal-errors, the line number of the offending caller is
not visible.

Code:
class Blah {
  int test;
};

struct Evil : public Blah {
  int test() { return Blah::test; }
};


When compiling with g++ -c -Wall -Werror, the output is:
test.cc: In member function 'int Evil::test()':
test.cc:3:6: error: 'int Blah::test' is private
test.cc:8:28: error: within this context

When compiling with g++ -c -Wall -Werror -Wfatal-errors, the output is:
test.cc: In member function 'int Evil::test()':
test.cc:3:6: error: 'int Blah::test' is private

There is no mention of line 8 when "-Wfatal-errors" is used.

[Bug c++/47429] -Wfatal-errors hiding line number of offending caller

2011-01-23 Thread navin.kumar at gmail dot com

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

--- Comment #1 from Navin Kumar  2011-01-24 
04:50:18 UTC ---
(re-pasted error output):

When compiling with g++ -c -Wall -Werror, the output is:
test.cc: In member function ‘int Evil::test()’:
test.cc:2:6: error: ‘int Blah::test’ is private
test.cc:6:28: error: within this context

When compiling with g++ -c -Wall -Werror -Wfatal-errors, the output is:
test.cc: In member function ‘int Evil::test()’:
test.cc:2:6: error: ‘int Blah::test’ is private

There is no mention of line 6 when "-Wfatal-errors" is used.

[Bug tree-optimization/47426] [4.6 Regression] wrong code with -O2 -fipa-pta

2011-01-23 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.24 05:19:22
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2011-01-24 05:19:22 
UTC ---
It is caused by revision 158374:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00480.html

[Bug c/47427] [4.6 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2901

2011-01-23 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.24 05:29:08
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|ICE in process_constraint,  |[4.6 Regression] ICE in
   |at  |process_constraint, at
   |tree-ssa-structalias.c:2901 |tree-ssa-structalias.c:2901
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-01-24 05:29:08 
UTC ---
It is cause by revision 165641:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00826.html

[Bug c/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986

2011-01-23 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.24 05:32:15
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|ICE: tree check: expected   |[4.6 Regression] ICE: tree
   |ssa_name, have integer_cst  |check: expected ssa_name,
   |in copy_phis_for_bb, at |have integer_cst in
   |tree-inline.c:1986  |copy_phis_for_bb, at
   ||tree-inline.c:1986
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-01-24 05:32:15 
UTC ---
It is caused by revision 160124:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00036.html

61 matches

Mail list logo