[Bug c/48509] New: Fails to Vectorize loop involving doubles which was vectorized in 4.5

2011-04-07 Thread jeremysalwen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48509

   Summary: Fails to Vectorize loop involving doubles which was
vectorized in 4.5
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jeremysal...@gmail.com


The following program is vectorized by gcc-4.5 but not by gcc-4.6 with the
following options: -march=native -mtune=native -ftree-vectorizer-verbose=12 -O3
-std=c99 -ffast-math -funsafe-math-optimizations -lm

#include 
#include 
int main() {
  double g[1000];
  for(int i=0; i<1000; i++) {
g[i]=2*(g[i]);
  }
  for(int i=0; i<1000; i++) {
   printf("%f\n",g[i]);
  }
}


In 4.6 it instead outputs: 

main.c:5: note: not vectorized: no vectype for stmt: D.4271_4 = g[i_22];
 scalar_type: double


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2011-04-07 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #75 from Markus Trippelsdorf  
2011-04-08 06:52:34 UTC ---
(In reply to comment #74)
> Interesting. -O3 makes no difference for me.  I will look into your dumps if I
> can spot something useful.
> ...
> If GCC fail to link even such a simple program as elfhack is, something pretty
> fundamental must go wrong.  Perhaps it is linker bug. I had problems with 
> older
> versions of gold.

The failure only happens with -flto.
And the reason is that:

c++ -o host_elf.o -c -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual
-Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
-Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long
-march=native -fpermissive -flto=4 -fuse-linker-plugin -fno-strict-aliasing
-fshort-wchar -pthread -pipe -fexceptions -DNDEBUG -DTRIMMED -Os
-I/var/tmp/mozilla-central/build/unix/elfhack -I. -I../../../dist/include
-I../../../dist/include/nsprpub -I/usr/include/nspr -I/usr/include/nss
-I/usr/include/nspr /var/tmp/mozilla-central/build/unix/elfhack/elf.cpp

apparently only compiles correctly in the -Os case. All other optimization
switches (-O(0..3) or without -O) lead to the eventual link failure above.
And it happens with both gnu-ld and gold (2.21.51.20110402).


[Bug middle-end/45472] [4.5/4.6/4.7 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

2011-04-07 Thread abel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472

--- Comment #15 from Andrey Belevantsev  2011-04-08 
06:42:22 UTC ---
Just to remind the middle-end folks that stage 1 is a fine time for deciding on
middle-end volatile semantics, before we forget about this for another 6 months
:)


[Bug c++/48500] Regression: Failing to convert template argument to concrete type, in C++0x mode.

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48500

--- Comment #1 from Jason Merrill  2011-04-08 
06:08:37 UTC ---
Author: jason
Date: Fri Apr  8 06:08:31 2011
New Revision: 172165

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172165
Log:
PR c++/48500
* semantics.c (potential_constant_expression_1) [CALL_EXPR]: Check
arguments even if we don't know the function.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/regress/call1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


[Bug c++/48481] C++ overloading memory hog

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481

--- Comment #7 from Jason Merrill  2011-04-08 
06:08:27 UTC ---
Author: jason
Date: Fri Apr  8 06:08:21 2011
New Revision: 172164

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172164
Log:
PR c++/48481
* tree.c (build_overload): Allow an unwrapped FUNCTION_DECL
at the end of the chain.
* pt.c (dependent_template_p): Use OVL_CURRENT/NEXT.
(iterative_hash_template_arg): Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c


[Bug c++/48481] C++ overloading memory hog

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481

--- Comment #6 from Jason Merrill  2011-04-08 
06:08:16 UTC ---
Author: jason
Date: Fri Apr  8 06:08:13 2011
New Revision: 172163

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172163
Log:
PR c++/48481
* cp-tree.h (OVL_ARG_DEPENDENT): New.
* name-lookup.c (add_function): Set it.
* semantics.c (finish_call_expr): Free OVERLOADs if it's set.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/semantics.c


[Bug c++/48481] C++ overloading memory hog

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481

--- Comment #5 from Jason Merrill  2011-04-08 
06:08:09 UTC ---
Author: jason
Date: Fri Apr  8 06:08:04 2011
New Revision: 172162

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172162
Log:
PR c++/48481
* call.c (build_user_type_conversion_1): Use lookup_fnfields_slot.
Release unused vector.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c


[Bug fortran/48456] [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc

2011-04-07 Thread pault at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48456

Paul Thomas  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |pault at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Paul Thomas  2011-04-08 04:32:57 
UTC ---
Obviously mine.

It seems to go away with my fix for PR48360, although I will have to verify
that this weekend.

Paul


[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array

2011-04-07 Thread pault at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Paul Thomas  2011-04-08 04:23:05 
UTC ---
This should be easy. The only difference between default (failing) and
-fno-realloc-lhs is a chunk at the beginning of the assignment:

  {
void * D.1571;

D.1571 = (void *) a.data;
if (D.1571 != 0B)
  {
__builtin_free (D.1571);
  }
  }
  a.data = 0B;
  a.dtype = 538;

which sort of does a job on 'a'.  I say that it is easy because there are not
many sections in trans-xxx that hide behind the -frealloc-lhs condition.

It's obviously mine.

Paul


[Bug fortran/48360] [4.6/4.7 Regression] ICE on array assignment statement with allocatable LHS

2011-04-07 Thread pault at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48360

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.08 04:16:46
 Ever Confirmed|0   |1

--- Comment #5 from Paul Thomas  2011-04-08 04:16:46 
UTC ---
This is obviously mine :-)

This fixes it but I suspect that a few more conditions (no ARRAY_ELEMENT for
example) will be needed for it to be correct.

Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c(revision 171573)
--- gcc/fortran/trans-array.c(working copy)
*** get_std_lbound (gfc_expr *expr, tree des
*** 6707,6712 
--- 6707,6713 
tree stride;
tree cond, cond1, cond3, cond4;
tree tmp;
+   gfc_ref *ref;
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
  {
tmp = gfc_rank_cst[dim];
*** get_std_lbound (gfc_expr *expr, tree des
*** 6740,6745 
--- 6741,6752 
else if (expr->expr_type == EXPR_VARIABLE)
  {
tmp = TREE_TYPE (expr->symtree->n.sym->backend_decl);
+   for (ref = expr->ref; ref; ref = ref->next)
+ {
+   if (ref->type == REF_COMPONENT
+ && ref->u.c.component->as)
+ tmp = TREE_TYPE (ref->u.c.component->backend_decl);
+ }
return GFC_TYPE_ARRAY_LBOUND(tmp, dim);
  }
else if (expr->expr_type == EXPR_FUNCTION)

Paul


[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

2011-04-07 Thread gfunck at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403

--- Comment #47 from gfunck at gcc dot gnu.org 2011-04-08 02:39:06 UTC ---
Author: gfunck
Date: Fri Apr  8 02:38:59 2011
New Revision: 172160

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172160
Log:
2011-04-07  Gary Funck  

Merge trunk version 172158 into gupc branch.
to bring in the following fix.

2011-04-05  Bernd Schmidt  

PR bootstrap/48403
* haifa-sched.c (schedule_block): Increment cycle_issued_insns only
if old and new states differ.


Added:
branches/gupc/gcc/c-family/c-target-def.h
  - copied unchanged from r172158, trunk/gcc/c-family/c-target-def.h
branches/gupc/gcc/c-family/c-target.def
  - copied unchanged from r172158, trunk/gcc/c-family/c-target.def
branches/gupc/gcc/c-family/c-target.h
  - copied unchanged from r172158, trunk/gcc/c-family/c-target.h
branches/gupc/gcc/config/default-c.c
  - copied unchanged from r172158, trunk/gcc/config/default-c.c
branches/gupc/gcc/config/rx/rx-opts.h
  - copied unchanged from r172158, trunk/gcc/config/rx/rx-opts.h
branches/gupc/gcc/target-hooks-macros.h
  - copied unchanged from r172158, trunk/gcc/target-hooks-macros.h
branches/gupc/gcc/testsuite/c-c++-common/Wcast-qual-1.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/c-c++-common/Wcast-qual-1.c
branches/gupc/gcc/testsuite/g++.dg/cpp0x/enum9.C
  - copied unchanged from r172158, trunk/gcc/testsuite/g++.dg/cpp0x/enum9.C
branches/gupc/gcc/testsuite/g++.dg/cpp0x/sfinae10.C
  - copied unchanged from r172158,
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae10.C
branches/gupc/gcc/testsuite/g++.dg/cpp0x/sfinae11.C
  - copied unchanged from r172158,
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae11.C
branches/gupc/gcc/testsuite/g++.dg/cpp0x/sfinae7.C
  - copied unchanged from r172158,
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae7.C
branches/gupc/gcc/testsuite/g++.dg/cpp0x/sfinae8.C
  - copied unchanged from r172158,
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae8.C
branches/gupc/gcc/testsuite/g++.dg/cpp0x/sfinae9.C
  - copied unchanged from r172158,
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae9.C
branches/gupc/gcc/testsuite/gcc.dg/guality/pr36977.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/gcc.dg/guality/pr36977.c
branches/gupc/gcc/testsuite/gcc.dg/guality/pr48466.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/gcc.dg/guality/pr48466.c
branches/gupc/gcc/testsuite/gcc.dg/torture/pr48343.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/gcc.dg/torture/pr48343.c
branches/gupc/gcc/testsuite/gcc.dg/tree-ssa/inline-8.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/gcc.dg/tree-ssa/inline-8.c
branches/gupc/gcc/testsuite/gcc.target/arm/pr43920-1.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/gcc.target/arm/pr43920-1.c
branches/gupc/gcc/testsuite/gcc.target/arm/pr43920-2.c
  - copied unchanged from r172158,
trunk/gcc/testsuite/gcc.target/arm/pr43920-2.c
branches/gupc/gcc/testsuite/gfortran.dg/gomp/pr48117.f90
  - copied unchanged from r172158,
trunk/gcc/testsuite/gfortran.dg/gomp/pr48117.f90
branches/gupc/gcc/testsuite/gnat.dg/return3.adb
  - copied unchanged from r172158, trunk/gcc/testsuite/gnat.dg/return3.adb
branches/gupc/libgo/go/crypto/des/
  - copied from r172158, trunk/libgo/go/crypto/des/
branches/gupc/libgo/go/os/dir_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/dir_plan9.go
branches/gupc/libgo/go/os/dir_unix.go
  - copied unchanged from r172158, trunk/libgo/go/os/dir_unix.go
branches/gupc/libgo/go/os/env_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/env_plan9.go
branches/gupc/libgo/go/os/error_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/error_plan9.go
branches/gupc/libgo/go/os/error_posix.go
  - copied unchanged from r172158, trunk/libgo/go/os/error_posix.go
branches/gupc/libgo/go/os/exec_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/exec_plan9.go
branches/gupc/libgo/go/os/exec_posix.go
  - copied unchanged from r172158, trunk/libgo/go/os/exec_posix.go
branches/gupc/libgo/go/os/file_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/file_plan9.go
branches/gupc/libgo/go/os/file_posix.go
  - copied unchanged from r172158, trunk/libgo/go/os/file_posix.go
branches/gupc/libgo/go/os/stat_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/stat_plan9.go
branches/gupc/libgo/go/os/sys_plan9.go
  - copied unchanged from r172158, trunk/libgo/go/os/sys_plan9.go
branches/gupc/libgo/go/path/filepath/path_plan9.go
  - copied unchanged from r172158,
trunk/libgo/go/path/filepath/path_plan9.go
branches/gupc/libstdc++-v3/testsuite/ext/iota/
  - copied from r172158, trunk/libstdc++-v3/testsuite/ext/iota/
branches/gupc/libstdc++-v3/testsuite/ext/is_sorted/
  - 

[Bug c++/48451] [C++0x][SFINAE] Failures with n-ary initialization expressions (with template default argument)

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48451

--- Comment #1 from Jason Merrill  2011-04-08 
02:03:29 UTC ---
Author: jason
Date: Fri Apr  8 02:03:25 2011
New Revision: 172159

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172159
Log:
PR c++/48451
* pt.c (fn_type_unification): Don't clear incomplete pack flag.
(type_unification_real): Clear it here instead.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic107.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


[Bug middle-end/48440] [4.7 Regression] FAIL: gcc.c-torture/compile/labels-3.c

2011-04-07 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48440

--- Comment #5 from hjl at gcc dot gnu.org  2011-04-08 
00:23:05 UTC ---
Author: hjl
Date: Fri Apr  8 00:23:02 2011
New Revision: 172156

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172156
Log:
Properly get inner mode for constant op0.

2011-04-06  H.J. Lu  

PR middle-end/48440
* expr.c (expand_expr_real_2): Get inner mode from op0 instead
of treeop0 for constant op0.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/expr.c


[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

2011-04-07 Thread xunxun1982 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172

PcX  changed:

   What|Removed |Added

 CC||xunxun1982 at gmail dot com

--- Comment #6 from PcX  2011-04-08 00:15:36 UTC 
---
Using mingw gcc4.5.2, the situation is not the same.
I found that when I use -O3, the result is pass.
When I use -O3 -march=native, the result is "COMPILER BUG: array[1025] should
be 98177 but is 0".


[Bug lto/48508] ICE in output_die, at dwarf2out.c:11409

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48508

--- Comment #1 from Jan Hubicka  2011-04-07 
23:25:43 UTC ---
Created attachment 23922
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23922
testcase


[Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48508

   Summary: ICE in output_die, at dwarf2out.c:11409
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org


/abuild/jh/trunk-install/bin/g++ -flto=25   ~/jsatom.ii ~/jscntxt.ii ~/jsgc.ii
~/jsinterp.ii ~/jsinvoke.ii ~/jsiter.ii  -r -nostdlib  -g -O3

leads eventually to

lto1: internal compiler error: in output_die, at dwarf2out.c:11409
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

It seems that all the files are needed to reproduce the ICE.


[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

2011-04-07 Thread patrick at motec dot com.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #10 from Patrick Oppenlander  
2011-04-07 22:50:25 UTC ---
Ok, thanks for explaining that.

Another problem I've run into here is that I also need to pass through ecrtn.o
with -Wl,-plugin-opt=-pass-through to make sure it gets linked last, otherwise
it's symbols end up in the wrong place.


[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

2011-04-07 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #9 from Dave Korn  2011-04-07 22:22:51 
UTC ---
(In reply to comment #8)
> > The correct fix is going to be in the linker, not the compiler, by 
> > implementing
> > a second library scan pass and obsoleting the pass-through mechanism.  I've 
> > got
> > a revised version of that experimental patch that I'll attach to this PR for
> > reference.
> 
> How does this affect circular dependencies between user supplied libraries. ld
> used to resolve these ok, and from the outside it seems like a similar 
> problem.

It doesn't affect them at all.

This problem only arises because the LTRANS phase (when the plugin invokes
lto-wrapper to recompile all the IR files that it has claimed) sometimes
creates new undefined references that weren't in the LTO symbol tables in the
original IR.  However, it is guaranteed that these references are only ever
going to be to functions that the compiler knows about itself as builtins, so
will only ever result in references to the various compiler language runtimes
and the core system libraries; for user-supplied functions.

LTO creates symbol tables in the IR files that drive the linker's initial
symbol resolution process, and these symbol tables will contain explicit
references to any external functions that aren't part of the language and
compiler runtimes; it however deliberately omits references to compiler
builtins, since they may well be optimised out during LTRANS.

So, everything related to user-supplied functions should behave identically
regardless of LTO, either with or without this extra patch to cause GCC to
rescan the libraries.


[Bug rtl-optimization/48141] [4.4 Regression] DSE compile time hog

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48141

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jakub Jelinek  2011-04-07 
22:21:48 UTC ---
Fixed.


[Bug libstdc++/48507] Functor Declared In Templated Method Not Recognized By std::sort

2011-04-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48507

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2011-04-07 
22:21:42 UTC ---
This is invalid C++03 and C++98.  The reason is that sub_pred is a local class
which is not a valid template argument type.  C++0x allows this though.  So
compiling with -std=c++0x and it works.


[Bug debug/48466] [4.4 Regression] Wrong variable locations at -O0 on i686

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jakub Jelinek  2011-04-07 
22:21:19 UTC ---
Fixed.


[Bug libstdc++/48507] Functor Declared In Templated Method Not Recognized By std::sort

2011-04-07 Thread overseer55 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48507

--- Comment #1 from overseer55 at gmail dot com 2011-04-07 22:19:12 UTC ---
Comment on attachment 23921
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23921
Source code (19 lines long)

Ignore the 'private' in sub_pred...I originally had it as a class.


[Bug libstdc++/48507] New: Functor Declared In Templated Method Not Recognized By std::sort

2011-04-07 Thread overseer55 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48507

   Summary: Functor Declared In Templated Method Not Recognized By
std::sort
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oversee...@gmail.com


Created attachment 23921
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23921
Source code (19 lines long)

> g++ -v 

COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/tools/gcc/4.5.2/linux64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/tools/gcc/4.5.2/linux64
--with-gmp=/build/swbuild/tools/gmp/4.3.2/linux64
--with-mpfr=/build/swbuild/tools/mpfr/3.0.0/linux64
--with-mpc=/build/swbuild/tools/mpc/0.8.2/linux64 --enable-languages=c,c++
--with-binutils=/tools/binutils/2.18.50/linux64
Thread model: posix
gcc version 4.5.2 (GCC) 

> g++ test.cpp

test.cpp: In member function ‘void A::fn(const _Pr&) [with _Pr = LT]’:
test.cpp:18:51:   instantiated from here
test.cpp:15:4: error: no matching function for call to
‘sort(std::vector::iterator, std::vector::iterator, A::fn(const _Pr&)
[with _Pr = LT]::sub_pred)’

Although I'm not enough of an expert on the STL implementation to determine
whether this program is legal, I do know that this program compiles using the
MSVC implementation of STL.


[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

2011-04-07 Thread patrick at motec dot com.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #8 from Patrick Oppenlander  
2011-04-07 22:15:56 UTC ---
> The correct fix is going to be in the linker, not the compiler, by 
> implementing
> a second library scan pass and obsoleting the pass-through mechanism.  I've 
> got
> a revised version of that experimental patch that I'll attach to this PR for
> reference.

How does this affect circular dependencies between user supplied libraries. ld
used to resolve these ok, and from the outside it seems like a similar problem.


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #74 from Jan Hubicka  2011-04-07 
22:07:38 UTC ---
Interesting. -O3 makes no difference for me.  I will look into your dumps if I
can spot something useful.

The behavior I observe is that GCC optimize away all the strings that are
placed into test.so. I didn't look deeper into it (I am looking if i can
reproduce your dwarf2out ICE and get a testcase right now), but I think it is
what makes my elfhack test to fail. I am surprised it does not happen for
yours.

If GCC fail to link even such a simple program as elfhack is, something pretty
fundamental must go wrong.  Perhaps it is linker bug. I had problems with older
versions of gold.


[Bug lto/48505] LTO ICE lhd_set_decl_assembler_name, at langhooks.c:158

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48505

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jan Hubicka  2011-04-07 
21:56:25 UTC ---
indeed, backtrace seems similar and decl is TYPE_DECL. So seems the problem
that we kill DECL_ASSEMBLER_NAMES of types. Marking as duplicate and setting
that one as blocker for mozilla LTO.

Honza

#0  internal_error (gmsgid=0xc3842d "in %s, at %s:%d") at
../../gcc/diagnostic.c:833
#1  0x005fee34 in fancy_abort (file=Unhandled dwarf expression opcode
0xf3
) at ../../gcc/diagnostic.c:893
#2  0x006e79dd in lhd_set_decl_assembler_name (decl=0x7323aa10) at
../../gcc/langhooks.c:154
#3  0x008c25c9 in decl_assembler_name (decl=0x7323aa10) at
../../gcc/tree.c:570
#4  0x0061bad1 in add_linkage_attr (die=0x73087460, decl=Unhandled
dwarf expression opcode 0xf3
) at ../../gcc/dwarf2out.c:17795
#5  0x006281a9 in gen_typedef_die (decl=0x7323aa10,
context_die=0x7306aeb0) at ../../gcc/dwarf2out.c:20495
#6  0x0062ba4c in gen_typedef_die (decl=0x7323aa10,
origin=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/dwarf2out.c:20446
#7  gen_decl_die (decl=0x7323aa10, origin=Unhandled dwarf expression opcode
0xf3
) at ../../gcc/dwarf2out.c:21291
#8  0x00623216 in gen_type_die_with_usage (type=0x73067d20,
context_die=0x7306aeb0, usage=DINFO_USAGE_DIR_USE) at
../../gcc/dwarf2out.c:20641
#9  0x00622d68 in gen_formal_types_die
(function_or_method_type=0x73067e70, context_die=0x719a4370) at
../../gcc/dwarf2out.c:18790
#10 0x00629270 in gen_subprogram_die (decl=0x73065e00,
context_die=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/dwarf2out.c:19374
#11 0x0062ba09 in gen_decl_die (decl=0x73065e00, origin=, context_die=0x7306aeb0) at ../../gcc/dwarf2out.c:21265
#12 0x0062c6e5 in declare_in_namespace (thing=0x73065e00,
context_die=0x77e76000) at ../../gcc/dwarf2out.c:2
#13 declare_in_namespace (thing=0x73065e00, context_die=0x77e76000) at
../../gcc/dwarf2out.c:21091
#14 0x0062bf43 in gen_decl_die (decl=0x73065e00, origin=0x0,
context_die=0x77e76000) at ../../gcc/dwarf2out.c:21260
#15 0x0062276d in dwarf2out_abstract_function (decl=0x73065e00) at
../../gcc/dwarf2out.c:18890
#16 0x009568e1 in expand_call_inline (fn=0x73111c00) at
../../gcc/tree-inline.c:4010
#17 gimple_expand_calls_inline (fn=0x73111c00) at
../../gcc/tree-inline.c:4039
#18 optimize_inline_calls (fn=0x73111c00) at ../../gcc/tree-inline.c:4191
#19 0x0093afc1 in cgraph_early_inlining () at
../../gcc/ipa-inline.c:1760
#20 0x007208b9 in execute_one_pass (pass=0xf9aba0) at
../../gcc/passes.c:1555
#21 0x00720b55 in execute_pass_list (pass=0xf9aba0) at
../../gcc/passes.c:1610
#22 0x0071fe90 in do_per_function_toporder (callback=0x720b40
, data=0xf97dc0) at ../../gcc/passes.c:1141
#23 0x00720fb6 in execute_ipa_pass_list (pass=0xf97ee0) at
../../gcc/passes.c:1927
#24 0x00933b39 in ipa_passes () at ../../gcc/cgraphunit.c:1787
#25 cgraph_optimize () at ../../gcc/cgraphunit.c:1859
#26 0x00933cfa in cgraph_finalize_compilation_unit () at
../../gcc/cgraphunit.c:1100
#27 0x004e3423 in cp_write_global_declarations () at
../../gcc/cp/decl2.c:4000
#28 0x007b2a73 in compile_file (argc=16, argv=0x7fffe248) at
../../gcc/toplev.c:591
#29 do_compile (argc=16, argv=0x7fffe248) at ../../gcc/toplev.c:1900
#30 toplev_main (argc=16, argv=0x7fffe248) at ../../gcc/toplev.c:1963
#31 0x763f0bc6 in __libc_start_main () from /lib64/libc.so.6
#32 0x0048abe9 in _start () at ../sysdeps/x86_64/elf/start.S:113

*** This bug has been marked as a duplicate of bug 48207 ***


[Bug debug/48207] ICE in lhd_set_decl_assembler_name, at langhooks.c:158

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48207

--- Comment #5 from Jan Hubicka  2011-04-07 
21:56:25 UTC ---
*** Bug 48505 has been marked as a duplicate of this bug. ***


[Bug testsuite/48506] ssa-ccp-17.c = g.i fails

2011-04-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48506

--- Comment #3 from Andrew Pinski  2011-04-07 
21:53:33 UTC ---
(In reply to comment #2)
> I'd do the checkin, if you let me know if you prefer the one case removed, or
> volatile added.

Hmm, this testcase works for me in 4.6.x and on the trunk.


[Bug testsuite/48506] ssa-ccp-17.c = g.i fails

2011-04-07 Thread mrs at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48506

--- Comment #2 from mrs at gcc dot gnu.org  2011-04-07 
21:51:06 UTC ---
I'd do the checkin, if you let me know if you prefer the one case removed, or
volatile added.


[Bug testsuite/48506] ssa-ccp-17.c = g.i fails

2011-04-07 Thread mrs at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48506

m...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||rguenther at suse dot de
  Known to fail||4.6.0

--- Comment #1 from mrs at gcc dot gnu.org  2011-04-07 
21:50:13 UTC ---
This should be fixed in 4.6.x.


[Bug testsuite/48506] New: ssa-ccp-17.c = g.i fails

2011-04-07 Thread mrs at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48506

   Summary: ssa-ccp-17.c = g.i fails
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


I'm seeing a new failure in:

  FAIL: gcc.dg/tree-ssa/ssa-ccp-17.c scan-tree-dump ccp1 "= g.i;"

the optimizer is generating return 0; for code like:

const int i = 0;

int foo() { return i; }

but we are scanning the output looking for = g.i;, which it can't find.

You caneither put volatile on the data, your delete the check.


[Bug c++/48468] [C++0x][SFINAE] noexcept operator does not handle function templates well

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48468

--- Comment #1 from Jason Merrill  2011-04-07 
21:48:04 UTC ---
Author: jason
Date: Thu Apr  7 21:48:00 2011
New Revision: 172148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172148
Log:
PR c++/48468
* except.c (build_noexcept_spec): Propagate error_mark_node.
(finish_noexcept_expr): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/except.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept02.C


[Bug c++/48452] [C++0x][SFINAE] Failures with n-ary initialization expressions (in return type)

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48452

--- Comment #1 from Jason Merrill  2011-04-07 
21:47:55 UTC ---
Author: jason
Date: Thu Apr  7 21:47:53 2011
New Revision: 172147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172147
Log:
PR c++/48452
* typeck.c (build_x_compound_expr_from_list): Return error_mark_node
in SFINAE context.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


[Bug c++/48450] [C++0x][SFINAE] Hard errors with static_cast expressions

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48450

--- Comment #4 from Jason Merrill  2011-04-07 
21:47:48 UTC ---
Author: jason
Date: Thu Apr  7 21:47:45 2011
New Revision: 172146

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172146
Log:
PR c++/48450
* call.c (resolve_args): Take complain.
(build_new_function_call, build_operator_new_call): Pass it.
(build_op_call, build_new_op, build_new_method_call): Pass it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog


[Bug c++/48450] [C++0x][SFINAE] Hard errors with static_cast expressions

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48450

--- Comment #3 from Jason Merrill  2011-04-07 
21:47:41 UTC ---
Author: jason
Date: Thu Apr  7 21:47:38 2011
New Revision: 172145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172145
Log:
PR c++/48450
* typeck.c (check_for_casting_away_constness): Take complain.
(build_static_cast_1, build_reinterpret_cast_1): Pass it.
(build_const_cast_1): Pass it.  Take full complain parm.
(build_const_cast, cp_build_c_cast): Adjust.

Added:
trunk/gcc/testsuite/c-c++-common/Wcast-qual-1.c
  - copied, changed from r172144, trunk/gcc/testsuite/gcc.dg/cast-qual-3.c
Removed:
trunk/gcc/testsuite/g++.dg/warn/Wcast-qual2.C
trunk/gcc/testsuite/gcc.dg/cast-qual-3.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


[Bug c++/48450] [C++0x][SFINAE] Hard errors with static_cast expressions

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48450

--- Comment #2 from Jason Merrill  2011-04-07 
21:47:27 UTC ---
Author: jason
Date: Thu Apr  7 21:47:24 2011
New Revision: 172143

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172143
Log:
PR c++/48450
* tree.c (build_cplus_new, build_aggr_init_expr): Take complain.
(bot_manip): Adjust.
* cp-tree.h: Adjust.
* call.c (convert_like_real, build_cxx_call): Adjust.
(perform_direct_initialization_if_possible): Adjust.
* cvt.c (ocp_convert): Adjust.
* init.c (build_value_init): Adjust.
* semantics.c (maybe_add_lambda_conv_op): Adjust.
* typeck.c (unary_complex_lvalue, cp_build_modify_expr): Adjust.
* typeck2.c (build_functional_cast): Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/init.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c


[Bug c++/48449] [C++0x][SFINAE] Hard errors during value-initialization expressions

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48449

--- Comment #1 from Jason Merrill  2011-04-07 
21:47:14 UTC ---
Author: jason
Date: Thu Apr  7 21:47:10 2011
New Revision: 172141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172141
Log:
PR c++/48449
* typeck2.c (build_functional_cast): Check complain consistently.
Use build_value_init and abstract_virtuals_error_sfinae.
(abstract_virtuals_error_sfinae): Split out.
* cp-tree.h: Declare it.
* init.c (build_new_1): Use it.
(build_value_init_noctor): Handle FUNCTION_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog


[Bug c++/48450] [C++0x][SFINAE] Hard errors with static_cast expressions

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48450

--- Comment #1 from Jason Merrill  2011-04-07 
21:46:50 UTC ---
Author: jason
Date: Thu Apr  7 21:46:48 2011
New Revision: 172138

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172138
Log:
PR c++/48450
* c-family/c-common.c (c_common_truthvalue_conversion): Don't ignore
conversion from C++0x scoped enum.
* cp/cvt.c (ocp_convert): Handle converting scoped enum to bool.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum9.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog


[Bug lto/48505] LTO ICE lhd_set_decl_assembler_name, at langhooks.c:158

2011-04-07 Thread d.g.gorbachev at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48505

--- Comment #2 from Dmitry Gorbachev  
2011-04-07 21:35:10 UTC ---
Akin to bug 48207...


[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117

--- Comment #8 from Jakub Jelinek  2011-04-07 
21:28:56 UTC ---
Author: jakub
Date: Thu Apr  7 21:28:52 2011
New Revision: 172134

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172134
Log:
PR fortran/48117
* gfortran.dg/gomp/pr48117.f90: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr48117.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


[Bug debug/48466] [4.4 Regression] Wrong variable locations at -O0 on i686

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466

--- Comment #7 from Jakub Jelinek  2011-04-07 
21:28:02 UTC ---
Author: jakub
Date: Thu Apr  7 21:27:59 2011
New Revision: 172133

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172133
Log:
Backported from mainline
2011-04-06  Jakub Jelinek  

PR debug/48466
* dwarf2out.c (based_loc_descr): If drap_reg is INVALID_REGNUM, use
as base_reg whatever register reg has been eliminated to, instead
of hardcoding STACK_POINTER_REGNUM.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/dwarf2out.c


[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro

2011-04-07 Thread stevenb.gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389

--- Comment #9 from stevenb.gcc at gmail dot com  
2011-04-07 21:28:12 UTC ---
> --- Comment #7 from Michael Matz  2011-04-07 
> 15:38:38 UTC ---
> Hmpf, what doesn't work with just moving the rebuild_jump_labels call?
> The testcase works, but I haven't tried the testsuite.  Because it should
> theoretically work.

Yes, it should, but it does not. Why do you think I'm meddling with cfgbuild.c?

The EDGE_EXECUTABLE thing was needed to pass a verify_flow_info()
called from commit_edge_insertions() but it's probably not necessary
anymore now that I commit edge inserts manually (to work around other
verify_flow_info() errors).

FWIW the patch doesn't bootstrap, and I'm still trying to figure out
what the problem is now.


[Bug rtl-optimization/48141] [4.4 Regression] DSE compile time hog

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48141

--- Comment #9 from Jakub Jelinek  2011-04-07 
21:27:06 UTC ---
Author: jakub
Date: Thu Apr  7 21:27:02 2011
New Revision: 172132

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172132
Log:
Backported from mainline
2011-03-17  Jakub Jelinek  

PR rtl-optimization/48141
* dse.c (record_store): If no positions are needed in an insn
that cannot be deleted, at least unchain it from active_local_stores.

* gcc.dg/pr48141.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr48141.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/dse.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


[Bug tree-optimization/46491] [4.3/4.4 Regression] ipa-pure-const.c miscompilation

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46491

--- Comment #4 from Jakub Jelinek  2011-04-07 
21:25:51 UTC ---
Author: jakub
Date: Thu Apr  7 21:25:47 2011
New Revision: 172129

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172129
Log:
PR tree-optimization/46491
Backported from mainline
2010-05-14  Jan Hubicka  
* ipa-pure-const.c (check_stmt): Do not use memory_identifier_string.

2011-04-07  Jakub Jelinek  

Backported from mainline
2010-11-15  Jakub Jelinek  

PR tree-optimization/46491
* gcc.target/i386/pr46491.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr46491.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ipa-pure-const.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


[Bug rtl-optimization/48272] internal compiler error: in setup_insn_reg_pressure_info, at haifa-sched.c:1124

2011-04-07 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48272

--- Comment #3 from Vladimir Makarov  2011-04-07 
21:22:49 UTC ---
(In reply to comment #2)
> Confirmed (nice non-sensical set of options, btw.)
> 
> The problem is that register pressure code is not prepared for new insns
> created during scheduling (for ia64, this is speculation checks and recovery
> code).  The ICE happens because we do not initialize register pressure
> structures.  The below patch seems to fix it, but I am not sure it is 
> correct.  
> 
> The patch calls setup_insn_reg_pressure_info (renamed to
> init_insn_reg_pressure_info because there is the function with the same name 
> in
> haifa-sched.c) from within haifa_init_insn, where new instructions created
> during scheduling are initialized.  The patch does not call 
> setup_insn_reg_uses
> as sched_analyze_insn does, because there is no deps context at that point.  
> If
> some processing of this kind is desired, I guess we need to amend the 
> functions
> that copy/init dependencies for recovery code (that is, 
> create_check_block_twin
> and add_to_speculative_block).  Finally, better name for
> init_insn_reg_pressure_info should be devised.
> 
> Vlad, it would be great if you can advise me on how to improve the patch.
> 
>

It is good enough.  You can commit it of course with a proper changelog entry.

Thanks, Andrey.


[Bug c++/48481] C++ overloading memory hog

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481

--- Comment #4 from Jason Merrill  2011-04-07 
20:47:14 UTC ---
Created attachment 23920
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23920
additional patch

This ought to help with the OVERLOAD garbage.


[Bug lto/48505] LTO ICE lhd_set_decl_assembler_name, at langhooks.c:158

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48505

--- Comment #1 from Jan Hubicka  2011-04-07 
20:23:48 UTC ---
Created attachment 23919
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23919
testcase


[Bug lto/48505] New: LTO ICE lhd_set_decl_assembler_name, at langhooks.c:158

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48505

   Summary: LTO ICE lhd_set_decl_assembler_name, at
langhooks.c:158
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org


jh@evans:/abuild/jh/build-mozilla-new11-lto/js/src>
/abuild/jh/trunk-install/bin/g++ -flto=24 -o FrameState.o ~/FrameState.ii -g
-O2 -c
In file included from
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsatom.h:52:0,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/jscntxt.h:52,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.cpp:39:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsstr.h: In static member
function ?static void JSShortString::staticAsserts()?:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsstr.h:526:95: warning:
invalid access to non-static data member ?JSString::d?  of NULL object
[-Winvalid-offsetof]
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsstr.h:526:95: warning:
(perhaps the ?offsetof? macro was used incorrectly) [-Winvalid-offsetof]
In file included from
/abuild/jh/mozilla-central2/mozilla-central/js/src/jscntxt.h:55:0,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.cpp:39:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsfun.h: In static member
function ?static uintN JSFunction::offsetOfNativeOrScript()?:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsfun.h:230:48: warning:
invalid access to non-static data member ?JSFunction::u?  of NULL object
[-Winvalid-offsetof]
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsfun.h:230:48: warning:
(perhaps the ?offsetof? macro was used incorrectly) [-Winvalid-offsetof]
In file included from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.cpp:39:0:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jscntxt.h: In function
?JSContext* js_ContextFromLinkField(JSCList*)?:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jscntxt.h:2929:75: warning:
invalid access to non-static data member ?JSContext::link?  of NULL object
[-Winvalid-offsetof]
/abuild/jh/mozilla-central2/mozilla-central/js/src/jscntxt.h:2929:75: warning:
(perhaps the ?offsetof? macro was used incorrectly) [-Winvalid-offsetof]
In file included from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/BaseAssembler.h:53:0,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/CodeGenIncludes.h:63,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.h:46,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.cpp:40:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsobjinlines.h: In member
function ?void JSObject::setArrayLength(uint32)?:
/abuild/jh/mozilla-central2/mozilla-central/js/src/jsobjinlines.h:364:24:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
In file included from
/abuild/jh/mozilla-central2/mozilla-central/js/src/assembler/assembler/MacroAssemblerX86Common.h:37:0,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/assembler/assembler/MacroAssemblerX86_64.h:37,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/assembler/assembler/MacroAssembler.h:54,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/MachineRegs.h:44,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.h:44,
 from
/abuild/jh/mozilla-central2/mozilla-central/js/src/methodjit/FrameState.cpp:40:
/abuild/jh/mozilla-central2/mozilla-central/js/src/assembler/assembler/X86Assembler.h:
In function ?JSC::X86Registers::nameFPReg(JSC::X86Registers::XMMRegisterID)?:
/abuild/jh/mozilla-central2/mozilla-central/js/src/assembler/assembler/X86Assembler.h:2130:61:
internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2011-04-07 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #73 from Markus Trippelsdorf  
2011-04-07 19:59:30 UTC ---
Jan,
elfhack only fails to build if I use:
ac_add_options --enable-optimize=-O3
in my .mozconfig.
When I delete the =-O3 part everything builds fine.


[Bug bootstrap/48474] gcc fails to bootstrap

2011-04-07 Thread mikestump at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474

--- Comment #2 from Mike Stump  2011-04-07 
19:41:04 UTC ---
I'd expect that I could change the target to make things compile.  The point of
the bug report was to report a rough edge where if one doesn't define a pattern
for eh_return, then things don't compile.


[Bug c/48504] New: Add Variable Length Array (VLA) support for -fstack-protector(-all)

2011-04-07 Thread joe.bassis at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48504

   Summary: Add Variable Length Array (VLA) support for
-fstack-protector(-all)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joe.bas...@gmail.com


Currently, -fstack-protector(-all) is only available for normal arrays. Please
add support for VLAs as well.

Currently:
char str[13] = "Hello World!";

Wishlist:
char str[variablelength];


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2011-04-07 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #72 from Markus Trippelsdorf  
2011-04-07 19:39:29 UTC ---
Created attachment 23918
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23918
elfhack.wpa.000i.cgraph


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2011-04-07 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #71 from Markus Trippelsdorf  
2011-04-07 19:38:17 UTC ---
Created attachment 23917
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23917
-lm.res


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2011-04-07 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #70 from Jan Hubicka  2011-04-07 
19:15:19 UTC ---
I can not reproduce the aforementioned elfhack failure. For me build fails
later at
/abuild/jh/trunk-install/bin/g++ -flto=24 -fuse-linker-plugin -fno-rtti -Wall
-Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros
-Werror=return-type -Wno-long-long -fno-strict-aliasing -fshort-wchar -pthread
-pipe -fexceptions  -DNDEBUG -DTRIMMED -g -Os -freorder-blocks
-fomit-frame-pointer  -fPIC -shared -Wl,-z,defs -Wl,-h,test.so -o test.so
test.o
===
=== If you get failures below, please file a bug describing the error
=== and your environment (compiler and linker versions), and use
=== --disable-elf-hack until this is fixed.
===
/abuild/jh/build-mozilla-new11-lto-elfhack/build/unix/elfhack/elfhack -b
test.so
test.so: terminate called after throwing an instance of 'std::runtime_error'
  what():  Section index out of bounds
make[5]: *** [test.so] Aborted (core dumped)

I tend to believe that this is elfhack problem.  Only way for me to get similar
linker error is to disable the linker plugin and use -fwhole-program.
Can you, please, try to build with -save-temps -fdump-ipa-cgraph and attach the
produced *.res and *wpa*cgraph files?


[Bug target/47779] Problem cross-compiling trunk for bfin

2011-04-07 Thread jsm28 at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779

--- Comment #5 from Joseph S. Myers  2011-04-07 
18:54:14 UTC ---
The real problem is that a large pile of logically host-only definitions are
included in tm.h for the target, and the real (but hard) fix would be to stop
target code from including tm.h (instead including a much more limited
libgcc-tm.h with only target-required definitions from libgcc/config/).

http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration


[Bug c++/48500] Regression: Failing to convert template argument to concrete type, in C++0x mode.

2011-04-07 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48500

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.07 18:52:35
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1


[Bug debug/48204] [4.5 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48204

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-04-07 
18:43:04 UTC ---
Fixed.


[Bug rtl-optimization/48141] [4.4 Regression] DSE compile time hog

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48141

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.5.3
Summary|[4.4/4.5 Regression] DSE|[4.4 Regression] DSE
   |compile time hog|compile time hog

--- Comment #8 from Jakub Jelinek  2011-04-07 
18:42:00 UTC ---
Fixed also for 4.5.3.


[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro

2011-04-07 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389

--- Comment #8 from Jeffrey A. Law  2011-04-07 18:41:14 
UTC ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/11 09:38, matz at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
> 
> Michael Matz  changed:
> 
>What|Removed |Added
> 
>  CC||matz at gcc dot gnu.org
> 
> --- Comment #7 from Michael Matz  2011-04-07 
> 15:38:38 UTC ---
> Hmpf, what doesn't work with just moving the rebuild_jump_labels call?
> The testcase works, but I haven't tried the testsuite.  Because it should
> theoretically work.  The insertion of barrier inside BBs is fixed up in
> cfgexpand at some places, we possibly merely need to extend them.  See
> maybe_cleanup_end_of_block.
You won't even get an x86 bootstrap due to complaints in the verifiers.
 I agree, it should theoretically work :-)  In practice it doesn't.

jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNngU9AAoJEBRtltQi2kC7T3UH/017oZD3gx+/5jsNwcIsIiuc
vjcenPjnNbR2gVFx2n65epQVfV7AC3nkBmJVYOCvpNCj9YHjLCURKp5Quy+uddsj
V63r+HjRBoQO0goTgUG+1fXdehvFSeHSIIGvds//NtioNhdBC8N82l4FQfDwkD5f
zBpddByDONoRfuHrcsfBHmNZDm9ymdeHEac4Lr8QBYBRnTN5j+fNfG7gBAqifEsf
TaxNhK4kRN5nufASRJID1YOlZulrU0sQMgHnPkRKHajpDA8zAuYtdsTn7wFqaY7Y
kDY3rrVL8Q25Cqvi+IGjYuhicdBM+e7LH4Y2/NnzKc4m7DApm8EZdaW8IM9PZBg=
=YyHc
-END PGP SIGNATURE-


[Bug c/47963] [4.5 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47963

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2011-04-07 
18:40:58 UTC ---
Fixed.


[Bug c/47809] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:7291

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47809

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2011-04-07 
18:40:31 UTC ---
Fixed.


[Bug c/47473] [4.5 Regression] Incorrect computation with complex numbers when using -std=c99

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jakub Jelinek  2011-04-07 
18:40:04 UTC ---
Fixed.


[Bug tree-optimization/47391] [4.5 Regression] read from const volatile incorrectly eliminated

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47391

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Jakub Jelinek  2011-04-07 
18:39:38 UTC ---
Fixed.


[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-04-07 
18:39:03 UTC ---
Fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172111
Testcase committed to 4.5/4.6/4.7.


[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117

--- Comment #6 from Jakub Jelinek  2011-04-07 
18:34:18 UTC ---
Author: jakub
Date: Thu Apr  7 18:34:14 2011
New Revision: 172121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172121
Log:
PR fortran/48117
* gfortran.dg/gomp/pr48117.f90: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr48117.f90
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117

--- Comment #5 from Jakub Jelinek  2011-04-07 
18:33:36 UTC ---
Author: jakub
Date: Thu Apr  7 18:33:34 2011
New Revision: 172120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172120
Log:
PR fortran/48117
* gfortran.dg/gomp/pr48117.f90: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/gomp/pr48117.f90
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog


[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117

--- Comment #4 from Jakub Jelinek  2011-04-07 
18:31:45 UTC ---
Author: jakub
Date: Thu Apr  7 18:31:43 2011
New Revision: 172119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172119
Log:
PR fortran/48117
* gfortran.dg/gomp/pr48117.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr48117.f90
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug debug/48466] [4.4/4.5 Regression] Wrong variable locations at -O0 on i686

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466

--- Comment #6 from Jakub Jelinek  2011-04-07 
18:30:39 UTC ---
Author: jakub
Date: Thu Apr  7 18:30:36 2011
New Revision: 172118

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172118
Log:
Backported from mainline
2011-04-06  Jakub Jelinek  

PR debug/48466
* dwarf2out.c (based_loc_descr): If drap_reg is INVALID_REGNUM, use
as base_reg whatever register reg has been eliminated to, instead
of hardcoding STACK_POINTER_REGNUM.

* gcc.dg/guality/pr36977.c: New test.
* gcc.dg/guality/pr48466.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/guality/pr36977.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/guality/pr48466.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dwarf2out.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug debug/48204] [4.5 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48204

--- Comment #6 from Jakub Jelinek  2011-04-07 
18:29:31 UTC ---
Author: jakub
Date: Thu Apr  7 18:29:28 2011
New Revision: 172117

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172117
Log:
Backported from mainline
2011-03-24  Jakub Jelinek  

PR debug/48204
* simplify-rtx.c (simplify_const_unary_operation): Call
real_convert when changing mode class with FLOAT_EXTEND.

* gcc.dg/dfp/pr48204.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/dfp/pr48204.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/simplify-rtx.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug rtl-optimization/48141] [4.4/4.5 Regression] DSE compile time hog

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48141

--- Comment #7 from Jakub Jelinek  2011-04-07 
18:28:33 UTC ---
Author: jakub
Date: Thu Apr  7 18:28:29 2011
New Revision: 172116

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172116
Log:
Backported from mainline
2011-03-17  Jakub Jelinek  

PR rtl-optimization/48141
* dse.c (record_store): If no positions are needed in an insn
that cannot be deleted, at least unchain it from active_local_stores.

* gcc.dg/pr48141.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr48141.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dse.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug c/47963] [4.5 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47963

--- Comment #4 from Jakub Jelinek  2011-04-07 
18:27:24 UTC ---
Author: jakub
Date: Thu Apr  7 18:27:20 2011
New Revision: 172115

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172115
Log:
Backported from mainline
2011-03-03  Jakub Jelinek  

PR c/47963
* gimplify.c (omp_add_variable): Only call omp_notice_variable
on TYPE_SIZE_UNIT if it is a DECL.

* gcc.dg/gomp/pr47963.c: New test.
* g++.dg/gomp/pr47963.C: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/gomp/pr47963.C
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/gomp/pr47963.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/gimplify.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug c/47809] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:7291

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47809

--- Comment #5 from Jakub Jelinek  2011-04-07 
18:25:53 UTC ---
Author: jakub
Date: Thu Apr  7 18:25:50 2011
New Revision: 172114

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172114
Log:
Backported from mainline
2011-02-19  Jakub Jelinek  

PR c/47809
* c-common.c (c_fully_fold_internal): Handle VIEW_CONVERT_EXPR.

* gcc.target/i386/pr47809.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr47809.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/c-common.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug c/47473] [4.5 Regression] Incorrect computation with complex numbers when using -std=c99

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473

--- Comment #9 from Jakub Jelinek  2011-04-07 
18:24:45 UTC ---
Author: jakub
Date: Thu Apr  7 18:24:43 2011
New Revision: 172113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172113
Log:
Backported from mainline
2011-01-26  Jakub Jelinek  

PR c/47473
* c-lex.c (interpret_float): If CPP_N_IMAGINARY, ensure
EXCESS_PRECISION_EXPR is created with COMPLEX_TYPE instead of
REAL_TYPE.

* gcc.dg/torture/pr47473.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47473.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/c-lex.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


[Bug tree-optimization/47391] [4.5 Regression] read from const volatile incorrectly eliminated

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47391

--- Comment #8 from Jakub Jelinek  2011-04-07 
18:22:54 UTC ---
Author: jakub
Date: Thu Apr  7 18:22:50 2011
New Revision: 172112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172112
Log:
PR tree-optimization/47391
* tree-ssa-ccp.c (get_symbol_constant_value): Don't optimize
if sym is volatile.

Backport from mainline
2011-01-21  Jakub Jelinek  

PR tree-optimization/47391
* gcc.dg/pr47391.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr47391.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-ssa-ccp.c


[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

2011-04-07 Thread d.g.gorbachev at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #7 from Dmitry Gorbachev  
2011-04-07 18:18:00 UTC ---
LD with patch from comment 6 fails on testcase from PR ld/12277.


[Bug debug/48343] [4.6/4.7 Regression] ICE compiling i586 linux-2.6.38/drivers/staging/wlan-ng/p80211wep.c: in form_sum, at reload.c:5338

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48343

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Jakub Jelinek  2011-04-07 
18:06:50 UTC ---
Fixed.


[Bug debug/48343] [4.6/4.7 Regression] ICE compiling i586 linux-2.6.38/drivers/staging/wlan-ng/p80211wep.c: in form_sum, at reload.c:5338

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48343

--- Comment #11 from Jakub Jelinek  2011-04-07 
18:05:11 UTC ---
Author: jakub
Date: Thu Apr  7 18:05:08 2011
New Revision: 172110

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172110
Log:
PR debug/48343
* combine.c (combine_instructions): Add last_combined_insn,
update it if insn is after it, pass it to all try_combine
calls.
(try_combine): Add last_combined_insn parameter, pass it instead of
i3 to propagate_for_debug.

* gcc.dg/torture/pr48343.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48343.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/combine.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog


[Bug go/48503] New: http/cgi FAILs if libgcc_s.so.1 isn't in default ld.so.1 search path

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48503

   Summary: http/cgi FAILs if libgcc_s.so.1 isn't in default
ld.so.1 search path
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: r...@gcc.gnu.org
  Host: *-*-solaris2.*
Target: *-*-solaris2.*
 Build: *-*-solaris2.*


As I'd mentioned before, the libgo http/cgi test fails on Solaris 2:

ld.so.1: a.out: fatal: libgcc_s.so.1: open failed: No such file or directory
--- FAIL: cgi.TestHostingOurselves (0.06 seconds)
for key "env-SCRIPT_NAME" got ""; expected "/test.go"
for key "env-SCRIPT_FILENAME" got ""; expected "./a.out"
for key "env-REMOTE_ADDR" got ""; expected "1.2.3.4"
for key "env-SERVER_NAME" got ""; expected "example.com"
for key "env-REQUEST_URI" got ""; expected "/test.go?foo=bar&a=b"
for key "env-REQUEST_METHOD" got ""; expected "GET"
for key "env-REMOTE_HOST" got ""; expected "1.2.3.4"
for key "param-a" got ""; expected "b"
for key "test" got ""; expected "Hello CGI-in-CGI"
for key "env-SERVER_PORT" got ""; expected "80"
for key "env-QUERY_STRING" got ""; expected "foo=bar&a=b"
for key "param-foo" got ""; expected "bar"
for key "env-HTTP_HOST" got ""; expected "example.com"
for key "env-SERVER_SOFTWARE" got ""; expected "go"
for key "env-GATEWAY_INTERFACE" got ""; expected "CGI/1.1"
got a Content-Type of ""; expected "text/html; charset=utf-8"
got a X-Test-Header of ""; expected "X-Test-Value"
FAIL
FAIL: http/cgi

I don't have libgcc_s.so.1 in the runtime linker's default search patch, and
LD_LIBRARY_PATH (and all the rest of the environment) is cleared when this test
is executed, as can be seen with truss:

28130:  execve("a.out", 0xDE20ED80, 0xDE21AA80)  argc = 2
28130:   argv: ./a.out -test.run=TestBeChildCGIProcess
28130:   envp: SERVER_SOFTWARE=go SERVER_NAME=example.com
28130:HTTP_HOST=example.com GATEWAY_INTERFACE=CGI/1.1
28130:REQUEST_METHOD=GET QUERY_STRING=foo=bar&a=b
28130:REQUEST_URI=/test.go?foo=bar&a=b PATH_INFO=
28130:SCRIPT_NAME=/test.go SCRIPT_FILENAME=./a.out
28130:REMOTE_ADDR=1.2.3.4 REMOTE_HOST=1.2.3.4 SERVER_PORT=80


[Bug go/48502] New: os_test.TestStartProcess FAILs on Solaris 2

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48502

   Summary: os_test.TestStartProcess FAILs on Solaris 2
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: r...@gcc.gnu.org
  Host: *-*-solaris2.*
Target: *-*-solaris2.*
 Build: *-*-solaris2.*


The libgo os test recently started failing again on Solaris 2:

--- FAIL: os_test.TestStartProcess (0.03 seconds)
exec "pwd pwd" returned "/usr/bin\n" wanted "/bin\n"
FAIL
FAIL: os
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[384]: gotest-timeout: cannot
create [No such file or directory]

This is no wonder since /bin is a symlink to /usr/bin on all releases of
Solaris 2.


[Bug debug/48343] [4.6/4.7 Regression] ICE compiling i586 linux-2.6.38/drivers/staging/wlan-ng/p80211wep.c: in form_sum, at reload.c:5338

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48343

--- Comment #10 from Jakub Jelinek  2011-04-07 
17:58:07 UTC ---
Author: jakub
Date: Thu Apr  7 17:58:05 2011
New Revision: 172109

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172109
Log:
PR debug/48343
* combine.c (combine_instructions): Add last_combined_insn,
update it if insn is after it, pass it to all try_combine
calls.
(try_combine): Add last_combined_insn parameter, pass it instead of
i3 to propagate_for_debug.

* gcc.dg/torture/pr48343.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr48343.c


[Bug debug/48343] [4.6/4.7 Regression] ICE compiling i586 linux-2.6.38/drivers/staging/wlan-ng/p80211wep.c: in form_sum, at reload.c:5338

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48343

--- Comment #9 from Jakub Jelinek  2011-04-07 
17:57:29 UTC ---
Author: jakub
Date: Thu Apr  7 17:57:26 2011
New Revision: 172108

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172108
Log:
PR debug/48343
* combine.c (combine_instructions): Add last_combined_insn,
update it if insn is after it, pass it to all try_combine
calls.
(try_combine): Add last_combined_insn parameter, pass it instead of
i3 to propagate_for_debug.

* gcc.dg/torture/pr48343.c: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


[Bug go/48501] New: 64bit-out.go, select5-out.go, tmp.go compilation times out

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48501

   Summary: 64bit-out.go, select5-out.go, tmp.go compilation times
out
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: r...@gcc.gnu.org
  Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
 Build: sparc-sun-solaris2.*


3 go testcases time out while compiling on Solaris 2/SPARC:

FAIL: ./64bit-out.go compilation,  -O2 -g 
FAIL: ./select5-out.go compilation,  -O2 -g 
FAIL: ./tmp.go compilation,  -O2 -g 

E.g., compiling 64bit-out.go (an 1.3 MB source file) on an unloaded 1.35 GHz
UltraSPARC IV+ takes

real4:13.59
user4:12.51
sys0.84

which is dangerously close to the default 300 s timeout.

It's way worse on a 250 MHz MIPS R10k:

real17:17.42
user17:12.24
sys 1.21

I thing such a test (haven't looked in more detail into the others) is way
over the top.


[Bug tree-optimization/48499] [4.7 regression] ICE compiling 64-bit gcc.dg/vect/{slp-21.c, no-vfa-pr29145.c} on SPARC

2011-04-07 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48499

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.07 17:52:14
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-04-07 
17:52:14 UTC ---
Vector support is quite damaged on the SPARC because of the recent IRA changes.


[Bug c++/48500] New: Regression: Failing to convert template argument to concrete type, in C++0x mode.

2011-04-07 Thread jyasskin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48500

   Summary: Regression: Failing to convert template argument to
concrete type, in C++0x mode.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
CC: ja...@gcc.gnu.org


This shows up in template functions that try to pass a value whose type is a
template argument to a function that expects one or more concrete types. The
code compiles in gcc-4.5, produces an error in 4.6.0 and gcc-4_6-branch, and
produces an ICE in trunk. All of them succeed in C++98 mode.

$ cat test.cc
struct linked_ptr {
};
template  linked_ptr make_linked_ptr(T* ptr);
struct Concrete;
struct NewedClass {
  NewedClass(const Concrete& req){}
};
template void AddObjToChange(const ArgT& req) {
  linked_ptr p = make_linked_ptr(new NewedClass(req));
}
$ g++-mp-4.5 -c test.cc -std=gnu++0x
$ g++-mp-4.6 -c test.cc -std=gnu++0x # Or gcc-4_6-branch at r172074
test.cc: In function 'void AddObjToChange(const ArgT&)':
test.cc:9:53: error: no matching function for call to
'NewedClass::NewedClass(const ArgT&)'
test.cc:9:53: note: candidates are:
test.cc:6:3: note: NewedClass::NewedClass(const Concrete&)
test.cc:6:3: note:   no known conversion for argument 1 from 'const ArgT' to
'const Concrete&'
test.cc:5:8: note: constexpr NewedClass::NewedClass(const NewedClass&)
test.cc:5:8: note:   no known conversion for argument 1 from 'const ArgT' to
'const NewedClass&'
test.cc:5:8: note: constexpr NewedClass::NewedClass(NewedClass&&)
test.cc:5:8: note:   no known conversion for argument 1 from 'const ArgT' to
'NewedClass&&'
$ trunk-r172073/g++  -std=gnu++0x -c test.cc
test.cc: In function ‘void AddObjToChange(const ArgT&)’:
test.cc:9:53: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$

An error in similar code went away with the fix to PR48319.


[Bug tree-optimization/48499] New: [4.7 regression] ICE compiling 64-bit gcc.dg/vect/{slp-21.c, no-vfa-pr29145.c} on SPARC

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48499

   Summary: [4.7 regression] ICE compiling 64-bit
gcc.dg/vect/{slp-21.c, no-vfa-pr29145.c} on SPARC
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: sparc*-*-*
Target: sparc*-*-*
 Build: sparc*-*-*


Since at least 20110331, two 64-bit gcc.dg/vect tests FAIL with an ICE:

$ /var/gcc/regression/trunk/11-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/11-gcc/build/gcc/
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-21.c -mcpu=ultrasparc
-mvis -ftree-vectorize -fno-vect-cost-model -O2 -fdump-tree-vect-details -lm
-m64 -o ./slp-21.exe
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-21.c: In function
'main1':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-21.c:191:1: error:
unrecognizable insn:
(insn 637 123 634 2 (set (reg:V4HI 4 %g4)
(mem/u/c/i:V4HI (symbol_ref/u:DI ("*.LLC0") [flags 0x2]) [2 S8 A64]))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-21.c:9 -1
 (nil))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-21.c:191:1: internal
compiler error: in extract_insn, at recog.c:2109

$ /var/gcc/regression/trunk/11-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/11-gcc/build/gcc/
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c
-mcpu=ultrasparc -mvis -ftree-vectorize -fno-vect-cost-model -O2
-fdump-tree-vect-details --param vect-max-version-for-alias-checks=0 -lm -m64
-o ./no-vfa-pr29145.exe
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c: In
function 'main':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c:49:1:
error: unrecognizable insn:
(insn 135 45 132 2 (set (reg:V2SI 3 %g3)
(mem/u/c/i:V2SI (symbol_ref/u:DI ("*.LLC0") [flags 0x2]) [2 S8 A64]))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c:35 -1
 (nil))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c:49:1:
internal compiler error: in extract_insn, at recog.c:2109

This is a regression from 4.6.


[Bug tree-optimization/48498] Several gcc.dg/vect tests XPASS on SPARC

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48498

--- Comment #1 from Rainer Orth  2011-04-07 17:38:05 UTC 
---
Created attachment 23916
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23916
no-vfa-pr29145.c -fdump-tree-vect-details output


[Bug tree-optimization/48498] New: Several gcc.dg/vect tests XPASS on SPARC

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48498

   Summary: Several gcc.dg/vect tests XPASS on SPARC
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: sparc*-*-*
Target: sparc*-*-*
 Build: sparc*-*-*


Created attachment 23915
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23915
slp-3.c -fdump-tree-vect-details  output

Several gcc.dg/vect tests started to XPASS on SPARC since around 20110331:

XPASS: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorized 3 loops" 1
XPASS: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 3
XPASS: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 0
loops" 2
XPASS: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 1
loops" 1

I'm attaching the vect dumps.


[Bug tree-optimization/48497] New: gfortran.dg/graphite/vect-pr40979.f90 FAILs without -march=pentium4

2011-04-07 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48497

   Summary: gfortran.dg/graphite/vect-pr40979.f90 FAILs without
-march=pentium4
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: s...@gcc.gnu.org
  Host: i386-pc-solaris2.[89]
Target: i386-pc-solaris2.[89]
 Build: i386-pc-solaris2.[89]


I noticed that the gfortran.dg/graphite/vect-pr40979.f90 FAILs on Solaris 8 and
9/x86:

FAIL: gfortran.dg/graphite/vect-pr40979.f90  -O  scan-tree-dump-times vect
"vectorized 1 loops" 1

If one adds -march=pentium4, the test passes, but the i386-pc-solaris2.[89]
configurations default to pentiumpro.


[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

2011-04-07 Thread david.kirkby at onetel dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072

--- Comment #20 from Dr. David Kirkby  
2011-04-07 17:15:07 UTC ---
(In reply to comment #18)
> > IBM is aware of the issue (via me and others).  The last tidbit I have is 
> > that
> > it appears as if it is another assembler bug but that is not confirmed yet. 
> >  I
> > don't have a fix nor do I have an APAR number yet.
> 
> Looks like this one is it:
> https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134


Yes, that looks like it. The title is just right. "IZ98134: ASSEMBLER GENERATES
INVALID OBJECT FILE WITH GCC-PRODUCED FILES"

But what does

APAR status

*
  Closed as program error.

Problem conclusion

*

  Fix logic handling debugging pseudo-ops.

=

mean? Does this mean IBM consider it a GCC bug? I don't find the explanations
on the page too useful. 



Dave


[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3

2011-04-07 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #34 from Jakub Jelinek  2011-04-07 
16:36:04 UTC ---
While for 4.7 we can certainly do bigger changes, for 4.6 I think a safe fix
would be:

--- gcc/tree-vect-data-refs.c2011-03-31 08:51:03.0 +0200
+++ gcc/tree-vect-data-refs.c2011-04-07 18:32:37.379420938 +0200
@@ -1110,6 +1110,9 @@ vector_alignment_reachable_p (struct dat
   if (ba)
 is_packed = contains_packed_reference (ba);

+  if (compare_tree_int (TYPE_SIZE (type), TYPE_ALIGN (type)) > 0)
+is_packed = true;
+
   if (vect_print_dump_info (REPORT_DETAILS))
 fprintf (vect_dump, "Unknown misalignment, is_packed = %d",is_packed);
   if (targetm.vectorize.vector_alignment_reachable (type, is_packed))

For scalars GCC ignores packed attribute, so aligned(1) is the only way to
express unaligned accesses.


[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations

2011-04-07 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455

--- Comment #4 from Richard Earnshaw  2011-04-07 
16:00:04 UTC ---
Created attachment 23914
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23914
first testcase

Compile with -Os -mcpu=arm7tdmi -marm -fno-short-enums -fno-builtin


[Bug c++/43601] Enormous increase in DLL object files size in 4.5

2011-04-07 Thread dongsheng.song at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601

--- Comment #57 from Dongsheng Song  
2011-04-07 15:53:38 UTC ---
(In reply to comment #56)
> What works for me on Cygwin, and so may well also work for anyone using MSYS,
> is setting the heap_chunk_in_mb registry parameter to some value in the range
> 1024 - 1536.  I use 1024 myself and that gives me sufficient headroom to link
> libgcj dll, which is huge; if it works for that, it's likely to help with wx
> dll as well.
> 
> http://cygwin.com/cygwin-ug-net/setup-maxmem.html

I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx
monolithic library require use more memory than 32 bit OS limit. For cross
compile under Linux, link wx can use near 3G memory, it still failed.

Then link wx require 4G or more memory, maybe someone can try use 64bit linker
to build single huge monolithic library, tell us the max memory ld used.


[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

2011-04-07 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #6 from Dave Korn  2011-04-07 15:51:30 
UTC ---
Created attachment 23913
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23913
WIP patch

Work in progress: see comment at start of do_rescan_work() re DT_NEEDED libs,
but should be worth trying.


[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

2011-04-07 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #5 from Dave Korn  2011-04-07 15:49:29 
UTC ---
Well, this is basically a weakness in the pass-through solution implemented for
PR 42690; it only knows about the compilers stdlibs, and doesn't process any
user-specified libs on the command line.  In the general case that's how things
ought to be: LTRANS only generates new references to builtins/libcalls, not any
of the user's code.  However when you use -nostdlib and pass libgcc as if it
were a user library, as in case 3, the pass-through mechanism doesn't know that
it's actually a compiler runtime rather than user library and doesn't pass it
through.

The correct fix is going to be in the linker, not the compiler, by implementing
a second library scan pass and obsoleting the pass-through mechanism.  I've got
a revised version of that experimental patch that I'll attach to this PR for
reference.


[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

2011-04-07 Thread joel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612

--- Comment #15 from Joel Sherrill  2011-04-07 
15:44:16 UTC ---
(In reply to comment #14)
> From the test results you posted, it appears to have been
> 
> +WARNING: program timed out.
> +FAIL: gcc.dg/torture/fp-int-convert-double.c  -O2 -flto  execution test
> 
> Probably unrelated.

When I compiled it by hand and ran it, it passed.  I think that makes the test
results the same.  Strangely, none of the gcc.dg/torture tests that failed
appear to have left executables. :(


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

2011-04-07 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0


[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro

2011-04-07 Thread matz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #7 from Michael Matz  2011-04-07 15:38:38 
UTC ---
Hmpf, what doesn't work with just moving the rebuild_jump_labels call?
The testcase works, but I haven't tried the testsuite.  Because it should
theoretically work.  The insertion of barrier inside BBs is fixed up in
cfgexpand at some places, we possibly merely need to extend them.  See
maybe_cleanup_end_of_block.


[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

2011-04-07 Thread bernds at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612

--- Comment #14 from Bernd Schmidt  2011-04-07 
15:35:34 UTC ---
>From the test results you posted, it appears to have been

+WARNING: program timed out.
+FAIL: gcc.dg/torture/fp-int-convert-double.c  -O2 -flto  execution test

Probably unrelated.


[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

2011-04-07 Thread joel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612

--- Comment #13 from Joel Sherrill  2011-04-07 
15:28:39 UTC ---
Not a problem to redo.. just CPU time and if you don't use it, you lose it. :-D
I am repeating some information so it is all in one post.

In both cases, I built gcc + newlib multilib + rtems multilib to ensure the
entire software base was built with and without the patch.

$ m68k-rtems4.11-gcc --version
m68k-rtems4.11-gcc (GCC) 4.6.1 20110329 (prerelease)

Without patch.. results are at:

http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000516.html
http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00525.html

=== gcc Summary ===

# of expected passes67228
# of unexpected failures386
# of expected failures121
# of unresolved testcases77
# of unsupported tests1095

=== g++ Summary ===

# of expected passes24705
# of unexpected failures720
# of expected failures162
# of unsupported tests449

With the patch ... results are at:

http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000518.html
http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00577.html

=== gcc Summary ===

# of expected passes67230
# of unexpected failures384
# of expected failures121
# of unresolved testcases77
# of unsupported tests1095

=== g++ Summary ===

# of expected passes24705
# of unexpected failures720
# of expected failures162
# of unsupported tests449

Only an increase of two passes.  I don't know what was the 3rd test that passed
with the previous patch and not with this one.


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

2011-04-07 Thread amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496

   Summary: [4.7 Regression] 'asm' operand requires impossible
reload in libffi/src/ia64/ffi.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amona...@gcc.gnu.org
CC: s...@cup.hp.com
Target: ia64-linux-gnu


Created attachment 23912
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23912
Test case

Trunk fails to complete bootstrap on ia64 when building target libffi (if
configured with java enabled).  A reduced test case is attached.

$ ../../stage1-gcc/cc1 -O2 -fexceptions -quiet tt.i
tt.i: In function 'ffi_call':
tt.i:15:3: error: 'asm' operand requires impossible reload


  1   2   >