[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression

2009-11-30 Thread irar at il dot ibm dot com


--- Comment #20 from irar at il dot ibm dot com  2009-11-30 08:52 ---
Actually, PAREN_EXPRs are vectorizable (the support was added by you, Richard,
in your original PAREN_EXPR patch
http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=132515 )).

The problem here is that vectorizable_assignment does not support multiple
types. The attached patch adds this support, but I don't know if the patch is
suitable for the current stage...

Ira


-- 


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



[Bug c++/38600] Trouble mangling template_id_expr

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #6 from paolo dot carlini at oracle dot com  2009-11-30 08:53 
---
Jason, can we close this one as duplicate of PR38712 ?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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



[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression

2009-11-30 Thread irar at il dot ibm dot com


--- Comment #21 from irar at il dot ibm dot com  2009-11-30 08:54 ---
Created an attachment (id=19183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19183&action=view)
Multiple types support patch


-- 


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



[Bug rtl-optimization/42226] New: [missed optimization] inefficient byte access when -Os is specified

2009-11-30 Thread carrot at google dot com
Compile the attached test case with options -Os -mthumb, gcc generates:

add r1, r1, #40
mov r3, r0
ldrbr2, [r1]
add r3, r3, #40
strbr2, [r3]
@ sp needed for prologue
bx  lr

When change the options to -O2 -mthumb, gcc generates:

mov r3, #40
ldrbr2, [r1, r3]
strbr2, [r0, r3]
@ sp needed for prologue
bx  lr

It is both smaller and faster.

Compare the dumped IL with different options, all TREE expressions are
identical. The first difference occurs after rtl expanding.


-- 
   Summary: [missed optimization]  inefficient byte access when -Os
is specified
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-eabi


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



[Bug rtl-optimization/42226] [missed optimization] inefficient byte access when -Os is specified

2009-11-30 Thread carrot at google dot com


--- Comment #1 from carrot at google dot com  2009-11-30 08:56 ---
Created an attachment (id=19184)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19184&action=view)
test case


-- 


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



[Bug c++/42194] performance degradation with STL complex convolution operation

2009-11-30 Thread jagjeet dot nain at gmail dot com


--- Comment #2 from jagjeet dot nain at gmail dot com  2009-11-30 09:57 
---
Will -fcx-limited-range or -fcx-fortran-rules change the results compared to
compiled with 4.0.2 without these flags ?

Or in otherwords, A complex division program compiled with and without
-fcx-limited-range flag of gcc 4.3.3, will results differ ?

with regards
J. S. Nain


-- 


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



[Bug tree-optimization/42216] [4.5 Regression] 464.h264ref peak regressed 20%

2009-11-30 Thread rguenther at suse dot de


--- Comment #2 from rguenther at suse dot de  2009-11-30 09:58 ---
Subject: Re:  [4.5 Regression] 464.h265ref peak
 regressed 20%

On Sun, 29 Nov 2009, rth at gcc dot gnu dot org wrote:

> --- Comment #1 from rth at gcc dot gnu dot org  2009-11-29 17:58 ---
> The vec_interleave_*_optab should still be populated.  It's just
> that what was once "sse2_punpcklwd" is now "vec_interleave_lowv8hi"
> directly.  If this patch *is* attributable to a regression, then
> perhaps there's a typo somewhere in the substitutions...

Indeed it wasn't your patch.  Checking with Bernds patch reverted now.

Richard.


-- 


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



[Bug c/42227] New: fr30-gcc-4.4.2 generate Illigal 32bit immediate data

2009-11-30 Thread t_yokota at monami-software dot com
s->__sglue._niobs = 3;
  s->__sglue._iobs = &s->__sf[0];
# 209 "../../../.././newlib/libc/stdio/findfp.c"
  std (s->_stdin, 0x0004, 0, s);
# 220 "../../../.././newlib/libc/stdio/findfp.c"
  std (s->_stdout, 0x0008 | 0x0001, 1, s);

this C language (newlib/stdio/findfp.c) code generate following the assembler
code.

.LM45:
ldi:8   #1, r2
st  r2, @r1
.LM46:
ldi:20  #736, r1
addnr4, r1
st  r6, @r1
.LM47:
ldi:20  #740, r1
addnr4, r1
ldi:8   #3, r3
st  r3, @r1
.LM48:
ldi:20  #744, r1
addnr4, r1
ldi:20  #748, r2
addnr4, r2
st  r2, @r1
.LM49:
ldi:32  #-740, r1   <-- illigal immidiate code
addnr1, r1
ldi:32  std, r9
ld  @r1, r4
.LVL14:

 gcc-4.3.4 (fr30-unknown-elf) generate following code. It can  execute
correctly.

14690:   c0 12   ldi:8 0x1,r2
   14692:   14 12   st r2,@r1
   14694:   cf c1   ldi:8 0xfc,r1
   14696:   97 81   extsb r1
   14698:   a2 e1   addn r14,r1
   1469a:   04 12   ld @r1,r2
   1469c:   9b 01 02 e0 ldi:20 0x2e0,r1
   146a0:   a2 21   addn r2,r1
   146a2:   c0 02   ldi:8 0x0,r2
   146a4:   14 12   st r2,@r1
   146a6:   cf c1   ldi:8 0xfc,r1
   146a8:   97 81   extsb r1
   146aa:   a2 e1   addn r14,r1
   146ac:   04 12   ld @r1,r2
   146ae:   9b 01 02 e4 ldi:20 0x2e4,r1
   146b2:   a2 21   addn r2,r1
   146b4:   c0 32   ldi:8 0x3,r2
   146b6:   14 12   st r2,@r1
   146b8:   cf c1   ldi:8 0xfc,r1
   146ba:   97 81   extsb r1
   146bc:   a2 e1   addn r14,r1
   146be:   04 11   ld @r1,r1
   146c0:   9b 02 02 ec ldi:20 0x2ec,r2
   146c4:   a2 12   addn r1,r2
   146c6:   cf c1   ldi:8 0xfc,r1
   146c8:   97 81   extsb r1
   146ca:   a2 e1   addn r14,r1
   146cc:   04 13   ld @r1,r3
   146ce:   9b 01 02 e8 ldi:20 0x2e8,r1
   146d2:   a2 31   addn r3,r1
   146d4:   14 12   st r2,@r1
   146d6:   cf c1   ldi:8 0xfc,r1
   146d8:   97 81   extsb r1
   146da:   a2 e1   addn r14,r1
   146dc:   04 11   ld @r1,r1
   146de:   a0 41   addn 0x4,r1
   146e0:   04 12   ld @r1,r2
   146e2:   cf c1   ldi:8 0xfc,r1
   146e4:   97 81   extsb r1
   146e6:   a2 e1   addn r14,r1
   146e8:   8b 24   mov r2,r4
   146ea:   c0 45   ldi:8 0x4,r5
   146ec:   c0 06   ldi:8 0x0,r6
   146ee:   04 17   ld @r1,r7
   146f0:   9f 81 00 01 ldi:32 0x141dc,r1
   146f4:   41 dc 
   146f6:   97 11   call @r1
   146f8:   cf c1   ldi:8 0xfc,r1


-- 
   Summary: fr30-gcc-4.4.2 generate Illigal 32bit immediate data
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t_yokota at monami-software dot com
 GCC build triplet: i386-apple-darwin10.2.0
  GCC host triplet: i386-apple-darwin10.2.0
GCC target triplet: fr30-unknown-elf


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



[Bug c++/42069] [4.5 Regression] ICE on class template specialization

2009-11-30 Thread dodji at gcc dot gnu dot org


--- Comment #5 from dodji at gcc dot gnu dot org  2009-11-30 09:58 ---
Subject: Bug 42069

Author: dodji
Date: Mon Nov 30 09:58:20 2009
New Revision: 154768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154768
Log:
Fix PR c++/42069

gcc/cp/ChangeLog:
PR c++/42069
* pt.c (convert_template_argument): Strip typedefs from SCOPE_REFs.

gcc/testsuite/ChangeLog:
PR c++/42069
* g++.dg/template/typedef23.C: New test.

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


-- 


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



[Bug tree-optimization/42209] missed optimization leads to several times slower code

2009-11-30 Thread hubicka at ucw dot cz


--- Comment #6 from hubicka at ucw dot cz  2009-11-30 09:59 ---
Subject: Re:  missed optimization leads to several times slower code

> Digression: this suggests an attribute such as "inline_if_reduces" which
> inlines if the inlined (callee) code is simplified, but otherwise keeps it out
> of line.  In other words, code growth is okay, but not when the savings is 
> only
> call/return reduction.  For "switch_case()", "inline_if_reduces_50" (inline if
> the inlined callee is under 50% of the out-of-line version) would be good:
> here, inlining reduces the dynamic code path by about 80% and the inlined code
> size (at each caller) is under 5% of the size before inline simplification. 

Implementing this is not really doable: the compiler never know how much
the function will simplify before it actually inlines the function (and
other functions called by the function inlined into) and optimizes,
since the effectivity of optimizations really depends on the whole
function body after inlining.  This is of course main problem of inliner
heuristics - it is one of most important heuristics in compiler but it
is also one operating on very few information.

We have little estimates of simplifications already in 4.5 and will have
more in next release, but doing 100% correct decisions here is not
possible.

Honza


-- 


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



[Bug c/42227] fr30-gcc-4.4.2 generate Illigal 32bit immediate data

2009-11-30 Thread t_yokota at monami-software dot com


--- Comment #1 from t_yokota at monami-software dot com  2009-11-30 10:00 
---
Created an attachment (id=19185)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19185&action=view)
i, S and rtl output files


-- 


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



[Bug c++/42219] [4.5 Regression] ICE with "const void" as parameter type

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-30 10:02 ---
Err - well.  I can certainly paper over the problem by ignoring
error_mark_node,
but ... why does the bogus type survive until gimplification?

Thus,

 >
QI
size  constant 8>
unit size  constant 1>
align 8 symtab 0 alias set -1 structural equality
arg-types 
chain >>
pointer_to_this >

as the type for foo in

  pf = (void (*) (void)) foo

?


-- 


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



[Bug c++/42228] New: verify_cgraph_node failed:node has wrong clone_of

2009-11-30 Thread dcb314 at hotmail dot com
I just tried to compile package libcrypto++ with the GNU C++ compiler
version 4.5 snapshot 20091126 and the compiler said

validat2.cpp: At global scope:
validat2.cpp:764:1: error: node has wrong clone_of
validat2.cpp:764:1: error: double linked list of clones corrupted
CryptoPP::DL_FixedBasePrecomputationImpl::DL_FixedBasePrecomputationImpl()
[with T = CryptoPP::ECPPoint]/4286(-1) @0x2affd636b110 (clone of
CryptoPP::DL_FixedBasePrecomputationImpl::DL_FixedBasePrecomputationImpl()
[with T = CryptoPP::ECPPoint]/5234) availability:available 30 time, 19 benefit
(41 after inlining) 17 size, 11 benefit (23 after inlining) body finalized
inlinable
  called by:
  calls: CryptoPP::Integer::Integer()/7921 (1.00 per call)
CryptoPP::ECPPoint::~ECPPoint()/1510
validat2.cpp:764:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O3 required.


-- 
   Summary: verify_cgraph_node failed:node has wrong clone_of
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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



[Bug c++/42228] verify_cgraph_node failed:node has wrong clone_of

2009-11-30 Thread dcb314 at hotmail dot com


--- Comment #1 from dcb314 at hotmail dot com  2009-11-30 10:06 ---
Created an attachment (id=19186)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19186&action=view)
gzipped C++ source code


-- 


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



[Bug fortran/42131] Weird translation of DO loops

2009-11-30 Thread rguenther at suse dot de


--- Comment #21 from rguenther at suse dot de  2009-11-30 10:10 ---
Subject: Re:  Weird translation of DO loops

On Mon, 30 Nov 2009, tkoenig at gcc dot gnu dot org wrote:

> --- Comment #20 from tkoenig at gcc dot gnu dot org  2009-11-30 07:31 
> ---
> Created an attachment (id=19182)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182&action=view)
> Patch that works for unrolling
> 
> It also passes do_3.F90.
> 
> I'll submit just in time for meeting the phase 4 deadline tonight (hopefully).

If it works for unrolling it must be indeed better.  Though:

+  /* Calculate SIGN (1,step) */
+
+  tmp = fold_build2 (RSHIFT_EXPR, type, step,
+build_int_cst (type,
+   TYPE_PRECISION (type) - 1));
+
+  tmp = fold_build2 (MULT_EXPR, type, tmp,
+build_int_cst (type, 2));
+
+  step_sign = fold_build2 (PLUS_EXPR, type, tmp,
+  fold_convert (type, integer_one_node));

the "sign" for unsigned steps is always 1, you don't seem to account
for unsignedness?  Note that I believe generating

  step_sign = fold_build3 (fold_build2 (LT_EXPR, boolean_type_node,
  step, build_int_cst (TREE_TYPE (step), 
0)),
 build_int_cst (type, -1), build_int_cst (type, 1));

is better as that allows more freedom for fold and efficient expansion
for the target.  Just double-check that it also works for the
unrolling ;)

Thanks,
Richard.


-- 


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



[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression

2009-11-30 Thread rguenther at suse dot de


--- Comment #22 from rguenther at suse dot de  2009-11-30 10:13 ---
Subject: Re:  [4.4/4.5 Regression] Vectorizer
 cannot deal with PAREN_EXPR gracefully, 50% performance regression

On Mon, 30 Nov 2009, irar at il dot ibm dot com wrote:

> --- Comment #20 from irar at il dot ibm dot com  2009-11-30 08:52 ---
> Actually, PAREN_EXPRs are vectorizable (the support was added by you, Richard,
> in your original PAREN_EXPR patch
> http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=132515 )).

Oh, indeed ;)

> The problem here is that vectorizable_assignment does not support multiple
> types. The attached patch adds this support, but I don't know if the patch is
> suitable for the current stage...

Probably not (though it looks small).  If you feel confident about it
you may well apply it still though.

Thanks,
Richard.


-- 


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



[Bug c++/42069] [4.5 Regression] ICE on class template specialization

2009-11-30 Thread dodji at gcc dot gnu dot org


--- Comment #6 from dodji at gcc dot gnu dot org  2009-11-30 10:15 ---
Fixed in 4.5.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/42229] New: cancel_loop_tree: bad read causes ice

2009-11-30 Thread dcb314 at hotmail dot com
I just tried to compile package libgeos_c1-3.1.1 with the GNU C++ compiler
version 4.5 snapshot 20091126 and the compiler said

AbstractSTRtree.cpp: In member function 'geos::index::strtree::ItemsList*
geos::index::strtree::AbstractSTRtree::itemsTree(geos::index::strtree::AbstractNode*)':
AbstractSTRtree.cpp:365:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -O2 -funroll-loops required.

Here is valgrind helping out with a stack backtrace

==896== Invalid read of size 8
==896==at 0x6A2309: cancel_loop_tree (cfgloop.c:1307)
==896==by 0x6A231C: cancel_loop_tree (cfgloop.c:1308)
==896==by 0x6A51DE: remove_path (cfgloopmanip.c:352)
==896==by 0x81A1C3: unroll_and_peel_loops (loop-unroll.c:513)
==896==by 0x80F416: rtl_unroll_and_peel_loops (loop-init.c:338)
==896==by 0x84A51B: execute_one_pass (passes.c:1522)
==896==by 0x84A7C4: execute_pass_list (passes.c:1577)
==896==by 0x84A7D6: execute_pass_list (passes.c:1578)
==896==by 0x84A7D6: execute_pass_list (passes.c:1578)
==896==by 0x943460: tree_rest_of_compilation (tree-optimize.c:411)
==896==by 0xAC61FB: cgraph_expand_function (cgraphunit.c:1178)
==896==by 0xAC80A4: cgraph_optimize (cgraphunit.c:1245)
==896==  Address 0xa5a5a5a5a5a5a5d5 is not stack'd, malloc'd or (recently)
free'd
==896==


-- 
   Summary: cancel_loop_tree: bad read causes ice
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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



[Bug c++/42229] cancel_loop_tree: bad read causes ice

2009-11-30 Thread dcb314 at hotmail dot com


--- Comment #1 from dcb314 at hotmail dot com  2009-11-30 10:23 ---
Created an attachment (id=19187)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19187&action=view)
C++ source code


-- 


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



[Bug middle-end/42224] [4.5 Regression] 32bit pointers to 32bit pointers abort on 64bit VMS and S390X

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-30 10:26 ---
Uli, this is your code.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu dot
   ||org
   Keywords||ice-checking, ice-on-valid-
   ||code
   Priority|P3  |P2
Summary|32bit pointers to 32bit |[4.5 Regression] 32bit
   |pointers abort on 64bit VMS |pointers to 32bit pointers
   |and S390X   |abort on 64bit VMS and S390X
   Target Milestone|--- |4.5.0


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



[Bug tree-optimization/42209] missed optimization leads to several times slower code

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #7 from rguenth at gcc dot gnu dot org  2009-11-30 10:26 ---
THus fixed in 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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



[Bug c++/42057] [4.5 Regression] ICE with invalid parameter of virtual function

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-11-30 10:27 
---
Today (r154772), I can't reproduce the issue anymore. Volker, can you double
check?


-- 


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



[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-30 10:32 ---
With checking enabled I get

> g++-4.5 -S -o /dev/null product_small.ii -B /abuild/rguenther/trunk-g/gcc
In file included from /home/bjacob/eigen/test/product_small.cpp:26:0:
/home/bjacob/eigen/test/product.h: In function 'void product(const MatrixType&)
[with MatrixType = Eigen::Matrix]':
/home/bjacob/eigen/test/product_small.cpp:31:97:   instantiated from here
/home/bjacob/eigen/test/product.h:45:60: internal compiler error: tree check:
accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9823
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

works with 4.4.2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to work||4.4.2
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2009-11-30 10:32:44
   date||
Summary|GCC 4.5 ICE (segfault) on   |[4.5 Regression] GCC 4.5 ICE
   |C++ templated code  |(segfault) on C++ templated
   ||code
   Target Milestone|--- |4.5.0


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



[Bug rtl-optimization/42226] [missed optimization] inefficient byte access when -Os is specified

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-30 10:33 ---
I suspect it's rtx costs messed up if asked for speed vs. size metrics.


-- 


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



[Bug middle-end/42206] ipa-prop.c: use of uninitialised local data

2009-11-30 Thread jamborm at gcc dot gnu dot org


--- Comment #2 from jamborm at gcc dot gnu dot org  2009-11-30 10:36 ---
What a stupid oversight, I'll prepare a patch straight away.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-28 16:31:16 |2009-11-30 10:36:59
   date||


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



[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

2009-11-30 Thread redi at gcc dot gnu dot org


--- Comment #3 from redi at gcc dot gnu dot org  2009-11-30 10:38 ---
(In reply to comment #2)
> The issue is pretty simple, actually: std::unique_future (which, by the way,
> will be renamed just std::future), is missing move assignment operator. Note,
> in N2914 it does *not* exist, has been added only in N3000, I guess we can as
> well add it right now, before the rename. But again, consider that these
> facilities are still experimental, the working draft is changing rather
> quickly...

I've already done most of the changes to update  to n3000, including
adding move assignment, I just need to adjust the tests because lots of the old
behaviour that was tested has changed (e.g. no default construction)


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||redi at gcc dot gnu dot org


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



[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-30 10:39 ---
Subject: Bug 42119

Author: rguenth
Date: Mon Nov 30 10:39:36 2009
New Revision: 154778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154778
Log:
2009-11-30  Richard Guenther  

PR middle-end/42119
PR fortran/38530
* expr.c (expand_expr_addr_expr_1): Properly expand the initializer
of CONST_DECLs.

* gfortran.dg/pr42119.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr42119.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/38530] ICE with the example for c_funloc

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-11-30 10:39 ---
Subject: Bug 38530

Author: rguenth
Date: Mon Nov 30 10:39:36 2009
New Revision: 154778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154778
Log:
2009-11-30  Richard Guenther  

PR middle-end/42119
PR fortran/38530
* expr.c (expand_expr_addr_expr_1): Properly expand the initializer
of CONST_DECLs.

* gfortran.dg/pr42119.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr42119.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/38530] ICE with the example for c_funloc

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2009-11-30 10:40 ---
Fixed for 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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



[Bug middle-end/42228] [4.5 Regression] verify_cgraph_node failed:node has wrong clone_of

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-30 10:41 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
   Keywords||ice-checking, ice-on-valid-
   ||code
  Known to work||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2009-11-30 10:41:11
   date||
Summary|verify_cgraph_node  |[4.5 Regression]
   |failed:node has wrong   |verify_cgraph_node
   |clone_of|failed:node has wrong
   ||clone_of
   Target Milestone|--- |4.5.0


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



[Bug tree-optimization/42216] [4.5 Regression] 464.h264ref peak regressed 20%

2009-11-30 Thread hjl dot tools at gmail dot com


--- Comment #3 from hjl dot tools at gmail dot com  2009-11-30 10:54 ---
This may be related to revision 154688, which has caused PR 42202.


-- 


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



[Bug c++/42217] [4.5 Regression] ICE with zero-length bit-field

2009-11-30 Thread dodji at gcc dot gnu dot org


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-29 15:45:15 |2009-11-30 11:12:00
   date||


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



[Bug c/18624] GCC does not detect local variable set but never used

2009-11-30 Thread dcb314 at hotmail dot com


--- Comment #21 from dcb314 at hotmail dot com  2009-11-30 11:30 ---
(In reply to comment #18)
> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01392.html

I tried out your patch on a recent Linux kernel and got
some possibly false positives

Code like

static inline pud_t __pud(pudval_t val)
{
pudval_t ret;

if (sizeof(pudval_t) > sizeof(long))
ret = PVOP_CALLEE2(pudval_t, pv_mmu_ops.make_pud,
   val, (u64)val >> 32);
else
ret = PVOP_CALLEE1(pudval_t, pv_mmu_ops.make_pud,
   val);

return (pud_t) { ret };
}

produces

arch/x86/include/asm/paravirt.h:613:11: warning: variable 'ret' set but not
used

The return statement looks like unusual C syntax to me.
Some refinement of your patch may be possible.


-- 


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



[Bug middle-end/42229] cancel_loop_tree: bad read causes ice

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-30 11:32 ---
Confirmed.  remove_path doesn't honor the fact that cancel_loop_tree removes
all sub-loops, so the work list may contain already removed loops.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-11-30 11:32:44
   date||


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



[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression

2009-11-30 Thread irar at il dot ibm dot com


--- Comment #23 from irar at il dot ibm dot com  2009-11-30 12:20 ---
Applied:
http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=154794

Thanks,
Ira


-- 


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



[Bug c++/37352] thunks for virtual function should work on lto

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2009-11-30 12:36 
---
Fixed by Honza.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #7 from rguenth at gcc dot gnu dot org  2009-11-30 13:11 ---
I believe this was fixed with

2009-07-22  Michael Matz  

PR tree-optimization/35229
PR tree-optimization/39300

* tree-ssa-pre.c (includes): Include tree-scalar-evolution.h.
(inhibit_phi_insertion): New function.
(insert_into_preds_of_block): Call it for REFERENCEs.
(init_pre): Initialize and finalize scalar evolutions.
* Makefile.in (tree-ssa-pre.o): Depend on tree-scalar-evolution.h .


which avoids the PRE and enables predictive commoning again (on x86_64
only the tail loop of the vectorized variant is).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #24 from rguenth at gcc dot gnu dot org  2009-11-30 13:14 
---
ppc folks, can you re-confirm this bug?


-- 


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



[Bug c/18624] GCC does not detect local variable set but never used

2009-11-30 Thread jakub at gcc dot gnu dot org


--- Comment #22 from jakub at gcc dot gnu dot org  2009-11-30 13:56 ---
In that case you weren't using the latest version of the patch.
Please try http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01582.html
instead, it should fix several important bugs and initializers of compound
literals are certainly one of those.


-- 


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



[Bug c++/42062] [4.3/4.4/4.5 Regression] Trouble with invalid template specialization

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-11-30 14:02 
---
The ICE part is fixed by my patch for PR34272.


-- 


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



[Bug libstdc++/42230] New: abi::__cxa_demangle fails to return the length of the decoded name

2009-11-30 Thread gcc at magfr dot user dot lysator dot liu dot se
When calling abi::__cxa_demangle("e", 0, &length, &cc) length is not updated
but the documentation indicates that it should be set to the length of the
demangled name.

It seems that this change was introduced after 3.4.6


-- 
   Summary: abi::__cxa_demangle fails to return the length of the
decoded name
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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



[Bug c++/42062] [4.3/4.4/4.5 Regression] Trouble with invalid template specialization

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #3 from paolo dot carlini at oracle dot com  2009-11-30 14:07 
---
The second part seems to me essentially a duplicate of PR28300.


-- 


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



[Bug c/42231] New: [4.4.x Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread roche+gccbugs at exalead dot com
Bug reproduced with GCC 4.4.2 and GCC 4.4.1, on x86_64.

The following simple test program should succeed (EXIT_SUCCESS return code from
main()), but fails with GCC 4.4.2 when compiling with -O3.

The program succeed with "-O2", _AND_ "-O2 -finline-functions -funswitch-loops
-fpredictive-commoning -fgcse-after-reload -ftree-vectorize" (which is supposed
to be the same as -O3, according to the manual, but there must be some
additional optimization out there)

The problem might be related to some inlining magic of the callback function,
because
* if you remove the "&& !fun(0);" in the CallFunction() function, the program
works again.
* if you change the function arguments "int depth" into "const int depth", the
program works again
* when the program works (for example, by adding "const" to the function
arguments), the callback function "callback" is NOT inlined


-- 
   Summary: [4.4.x Regression] Wrong generated code when using a
callback function (possible callback function inlining
bug ?)
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roche+gccbugs at exalead dot com
GCC target triplet: x86_64-unknown-linux-gnu


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



[Bug c/42231] [4.4.x Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread roche+gccbugs at exalead dot com


--- Comment #1 from roche+gccbugs at exalead dot com  2009-11-30 14:29 
---
Created an attachment (id=19188)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19188&action=view)
The test program (exit code is meaningful)


-- 


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



[Bug c/42231] [4.4.x Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread roche+gccbugs at exalead dot com


--- Comment #2 from roche+gccbugs at exalead dot com  2009-11-30 14:38 
---
Created an attachment (id=19189)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19189&action=view)
The preprocessor version


-- 


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



[Bug c/42231] [4.4.x Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread roche+gccbugs at exalead dot com


--- Comment #3 from roche+gccbugs at exalead dot com  2009-11-30 14:38 
---
Created an attachment (id=19190)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19190&action=view)
The assembly source version


-- 


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



[Bug tree-optimization/39806] incorrect pointer hashing in ipa-struct-reorg.c

2009-11-30 Thread olga at gcc dot gnu dot org


--- Comment #4 from olga at gcc dot gnu dot org  2009-11-30 14:43 ---
Subject: Bug 39806

Author: olga
Date: Mon Nov 30 14:42:54 2009
New Revision: 154811

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154811
Log:
2009-11-30  Olga Golovanevsky  

PR middle-end/39806
* ipa-struct-reorg.c (new_var_eq): Use DECL_UID to hash new variables.
(new_var_hash): Likewise.
(is_in_new_vars_htab): Likewise.
(add_to_new_vars_htab): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-struct-reorg.c


-- 


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



[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-30 14:46 ---
Confirmed.  Works with 4.5 and with -fno-ipa-cp.

IPA lattices after propagation:

Lattice:
  Node: main:
  Node: callback:
param [0]: type is CONST 0

which is obviously wrong.  On trunk the same propagation result is achived
but somehow we do not miscompile there.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.4.3
  Known to work||4.3.4 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-11-30 14:46:30
   date||
Summary|[4.4.x Regression] Wrong|[4.4 Regression] Wrong
   |generated code when using a |generated code when using a
   |callback function (possible |callback function (possible
   |callback function inlining  |callback function inlining
   |bug ?)  |bug ?)
   Target Milestone|--- |4.4.3


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



[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.3   |4.4.0 4.4.3
   Priority|P3  |P2


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



[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #15 from rguenth at gcc dot gnu dot org  2009-11-30 15:05 
---
The issue with the boolean_type_node is that the middle-end does not have
a type for a comparison result but implicitly assumes boolean_type_node.

So for

  D._16 = (boolean) D._6;
  if (D._16 != 0)

with a re-set boolean_type_node we fold this to D._6 != 0, with
the original Ada boolean_type_node we do not.  The C frontend for
decaying to bool always produces a comparison btw, not the truncation
we see above (and it only truncates to 8 bits).

In the end we want to unconditionally use a canonical boolean_type_node
in the middle-end, but this forces us to mangle all decls early (as
the mangler looks for boolean_type_node trees).

While the patch in comment #14 now bootstraps ok it has testsuite fails.

FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison

I think for 4.5 we should admit defeat and disable free-lang-data
unconditionally if not using LTO.


-- 


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



[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread roche+gccbugs at exalead dot com


--- Comment #5 from roche+gccbugs at exalead dot com  2009-11-30 15:06 
---
Just a small note: also work with "just" -fno-ipa-cp-clone in O3 mode,
actually. Therefore the issue is probably related to the "Perform function
cloning to make interprocedural constant propagation stronger" feature
introduced in -O3 optimization.


-- 


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



[Bug middle-end/42224] [4.5 Regression] 32bit pointers to 32bit pointers abort on 64bit VMS and S390X

2009-11-30 Thread uweigand at gcc dot gnu dot org


--- Comment #3 from uweigand at gcc dot gnu dot org  2009-11-30 15:17 
---
OK, I've reproduced the problem.  It seems int_or_pointer_precision
is fundamentally wrong for pointers using a non-standard size
(i.e. pointer variables defined using a mode attribute).

The history of this is that there used to be code e.g. in
fold-const.c:fit_double_type that hard-coded a precision
of POINTER_SIZE for pointer types:

  if (POINTER_TYPE_P (type)
  || TREE_CODE (type) == OFFSET_TYPE)
prec = POINTER_SIZE;
  else
prec = TYPE_PRECISION (type);

This showed up as a bug in the presence of named-address-space
pointers of a different size than POINTER_SIZE.  The initial
thought to fix this as to just always use TYPE_PRECISION.

This turned out to break C++, as OFFSET_TYPEs were generated that
did not correctly set TYPE_PRECISION.   Mike fixed this, and added
the int_or_pointer_precision routine to verify that TYPE_PRECISION
of pointer and offset types is set correctly.

However, this now breaks on targets that allow pointers of different
size even for the same address space, because the verification in
int_or_pointer_precision fails.  I think we need to relax the check
to allow any "valid_pointer_mode" for the given address space as
mode of the pointer, as long as the precision matches the mode size
of that mode.

I'm testing a patch to that effect.


-- 

uweigand at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |uweigand at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-30 15:17:10
   date||


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



[Bug target/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding

2009-11-30 Thread vlad at demoninsight dot com


--- Comment #10 from vlad at demoninsight dot com  2009-11-30 15:19 ---
So, using 4.5 trunk works around this issue... But ouch: 4.5 is almost 2x
slower than 4.4...


-- 


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



[Bug target/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2009-11-30 15:27 
---
Slower in runtime or in compile-time?


-- 


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



[Bug libstdc++/42230] abi::__cxa_demangle fails to return the length of the decoded name

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #1 from paolo dot carlini at oracle dot com  2009-11-30 15:29 
---
Ian, can you have a look to this issue? Thanks in advance.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||iant at google dot com


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



[Bug middle-end/42206] ipa-prop.c: use of uninitialised local data

2009-11-30 Thread jamborm at gcc dot gnu dot org


--- Comment #3 from jamborm at gcc dot gnu dot org  2009-11-30 15:46 ---
Subject: Bug 42206

Author: jamborm
Date: Mon Nov 30 15:46:00 2009
New Revision: 154820

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154820
Log:
2009-11-30  Martin Jambor  

PR middle-end/42206
* ipa-prop.c (ipa_write_node_info): Initialize note_count to zero.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c


-- 


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



[Bug middle-end/42206] ipa-prop.c: use of uninitialised local data

2009-11-30 Thread jamborm at gcc dot gnu dot org


--- Comment #4 from jamborm at gcc dot gnu dot org  2009-11-30 15:58 ---
The variable is initialized now.  Thanks for pointing it out.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug target/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding

2009-11-30 Thread vlad at demoninsight dot com


--- Comment #12 from vlad at demoninsight dot com  2009-11-30 16:07 ---
(In reply to comment #11)
> Slower in runtime or in compile-time?
> 

Compile-time.


-- 


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



[Bug c++/42232] New: [4.4 Regression] ICE in cleanup_omp_return

2009-11-30 Thread rguenth at gcc dot gnu dot org
> g++-4.4 -S -m32 bug-559091_solver_main_pre_omp.3.cpp -fopenmp
bug-559091_solver_main_pre_omp.3.cpp: In member function ‘void
LbmFsgrSolver::mainLoop(int)Â’:
bug-559091_solver_main_pre_omp.3.cpp:121: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.4 Regression] ICE in cleanup_omp_return
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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



[Bug c++/42232] [4.4 Regression] ICE in cleanup_omp_return

2009-11-30 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-30 16:26 ---
Created an attachment (id=19191)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19191&action=view)
reduced testcase

Reduced testcase from https://bugzilla.novell.com/show_bug.cgi?id=559091.

(gdb) bt
#0  0x00b128c7 in gimple_code (g=0x0)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/gimple.h:1031
#1  0x00b13ab4 in cleanup_omp_return (bb=0x72cb53c0)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/tree-cfgcleanup.c:520
#2  0x00b13bf6 in cleanup_tree_cfg_bb (bb=0x72cb53c0)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/tree-cfgcleanup.c:542
#3  0x00b13d31 in cleanup_tree_cfg_1 ()
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/tree-cfgcleanup.c:594
#4  0x00b13e5c in cleanup_tree_cfg_noloop ()
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/tree-cfgcleanup.c:650
#5  0x00b13fb6 in cleanup_tree_cfg ()
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/tree-cfgcleanup.c:696
#6  0x009faf36 in execute_function_todo (data=0x31)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/passes.c:921
#7  0x009fac49 in do_per_function (
callback=0x9faee0 , data=0x31)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/passes.c:839
#8  0x009fb235 in execute_todo (flags=49)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/passes.c:1023
#9  0x009fbcb0 in execute_one_pass (pass=0x16cc7c0)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/passes.c:1300
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x11f92e0 "cfg", gate = 0, 
  execute = 0xaf7ce3 , sub = 0x0, next = 0x16ccb60, 
  static_pass_number = 17, tv_id = 37, properties_required = 4, 
  properties_provided = 8, properties_destroyed = 0, 
  todo_flags_start = 524288, todo_flags_finish = 49}


-- 


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



[Bug c++/42232] [4.4 Regression] ICE in cleanup_omp_return

2009-11-30 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.3
  Known to work||4.3.4 4.5.0
   Target Milestone|--- |4.4.3


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



[Bug c++/42233] New: c++ builtin_expect code generation regression

2009-11-30 Thread gmorin1 at bloomberg dot net
The following c/++ code generates assembly that favors the unlikely case with
gcc 4.3 and 4.4:
extern void likely();
extern void unlikely();
void test_expect(char * a, char *b, char *c, char *d) {
if (__builtin_expect(!!(a == b && c == d), 1)) {
likely();
}
else {
unlikely();
}
}
Compiled with g++44 -O2 -S -fverbose-asm -m32. (or -m64).

A few notes: gcc 4.1 seems to generate better assembly.  If this code is code
is compiled as c code and not C++ with gcc 4.4, the likely case is properly
favored.

Changing the if statement into "if (__builtin_expect(!!(a == b),1) &&
__builtin_expect(!!(c == d), 1))" fixes the problem as well.  With this code,
gcc generates better code for the likely case.


-- 
   Summary: c++ builtin_expect code generation regression
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmorin1 at bloomberg dot net


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



[Bug target/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding

2009-11-30 Thread redi at gcc dot gnu dot org


--- Comment #13 from redi at gcc dot gnu dot org  2009-11-30 16:46 ---
(In reply to comment #12)
> Compile-time.

configure with --enable-checking=release to turn off checks that are enabled by
default in pre-release builds, that will give a better comparison between the
4.4.2 release and 4.5 snapshot


-- 


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



[Bug middle-end/42130] [graphite-branch] dealII fails

2009-11-30 Thread spop at gcc dot gnu dot org


--- Comment #5 from spop at gcc dot gnu dot org  2009-11-30 16:59 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug bootstrap/41401] VTA breaks bootstrap with graphite enabled

2009-11-30 Thread spop at gcc dot gnu dot org


--- Comment #4 from spop at gcc dot gnu dot org  2009-11-30 17:00 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug c++/42233] c++ builtin_expect code generation regression

2009-11-30 Thread gmorin1 at bloomberg dot net


--- Comment #1 from gmorin1 at bloomberg dot net  2009-11-30 17:00 ---
I can see this problem with 4.3.2 (Debian 4.3.2-1.1), 4.2.4 (Debian 4.2.4-6),
4.4.0 20090514 (Red Hat 4.4.0-6).  I do not see it with 4.1.2 20080704 (Red Hat
4.1.2-46) and 4.1.3 20080704 (prerelease) (Debian 4.1.2-25).


-- 


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



[Bug c++/40371] ICE with template operator

2009-11-30 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED


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



[Bug c++/42233] c++ builtin_expect code generation regression

2009-11-30 Thread hubicka at gcc dot gnu dot org


--- Comment #2 from hubicka at gcc dot gnu dot org  2009-11-30 17:29 ---
With 4.5 we seem to be all fine here:
j...@gcc17:~/trunk/build/gcc$ ./g++ -B ./ -O2 tt.c -fdump-tree-all-details -S
-fdump-rtl-all-details-blocks
j...@gcc17:~/trunk/build/gcc$ more tt.s
.file   "tt.c"
.text
.p2align 4,,15
.globl _Z11test_expectPcS_S_S_
.type   _Z11test_expectPcS_S_S_, @function
_Z11test_expectPcS_S_S_:
.LFB0:
cmpq%rcx, %rdx
sete%dl
cmpq%rsi, %rdi
sete%al
testb   %al, %dl
je  .L2
jmp _Z6likelyv
.L2:
jmp _Z8unlikelyv
.LFE0:

and the conditional jump is predicted in the proper direction in greg dumps as
having 1% probability to reach unlikely.
Of course we miss here the conditional tailcall case.

Honza


-- 


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



[Bug middle-end/42196] ICE when SRAing partial assigments to complex number

2009-11-30 Thread jamborm at gcc dot gnu dot org


--- Comment #2 from jamborm at gcc dot gnu dot org  2009-11-30 18:00 ---
Subject: Bug 42196

Author: jamborm
Date: Mon Nov 30 17:59:57 2009
New Revision: 154834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154834
Log:
2009-11-30  Martin Jambor  

PR middle-end/42196
* tree-sra.c (struct access): New field grp_different_types.
(dump_access): Dump grp_different_types.
(compare_access_positions): Prefer scalars and vectors over other
scalar types.
(sort_and_splice_var_accesses): Set grp_different_types if appropriate.
(sra_modify_expr): Use the original also when dealing with a complex
 or vector group accessed as multiple types.

* testsuite/gcc.c-torture/compile/pr42196-1.c: New test.
* testsuite/gcc.c-torture/compile/pr42196-2.c: New test.
* testsuite/gcc.c-torture/compile/pr42196-3.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr42196-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr42196-2.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr42196-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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



[Bug middle-end/42196] ICE when SRAing partial assigments to complex number

2009-11-30 Thread jamborm at gcc dot gnu dot org


--- Comment #3 from jamborm at gcc dot gnu dot org  2009-11-30 18:16 ---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug c++/40371] ICE with template operator

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-11-30 18:41 
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01729.html


-- 


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



[Bug testsuite/42212] [4.5 Regression] ERROR: tcl error sourcing /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp.

2009-11-30 Thread janis at gcc dot gnu dot org


--- Comment #2 from janis at gcc dot gnu dot org  2009-11-30 19:15 ---
Subject: Bug 42212

Author: janis
Date: Mon Nov 30 19:14:58 2009
New Revision: 154837

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154837
Log:
PR testsuite/42212
* gcc.target/powerpc/regnames-1.c: Add missing brace dg-do.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/regnames-1.c


-- 


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



[Bug fortran/42131] Weird translation of DO loops

2009-11-30 Thread tkoenig at gcc dot gnu dot org


--- Comment #22 from tkoenig at gcc dot gnu dot org  2009-11-30 19:15 
---
(In reply to comment #21)

> the "sign" for unsigned steps is always 1, you don't seem to account
> for unsignedness?

(Un)fortunately, there are no unsigned varaibles in Fortran.

> Note that I believe generating
> 
>   step_sign = fold_build3 (fold_build2 (LT_EXPR, boolean_type_node,
>   step, build_int_cst (TREE_TYPE (step), 
> 0)),
>  build_int_cst (type, -1), build_int_cst (type, 1));
> 
> is better as that allows more freedom for fold and efficient expansion
> for the target.  Just double-check that it also works for the
> unrolling ;)

That doesn't work (something about fold_build3 needing five arguments
instead of three), so think I'll submit my patch "as is".

Thanks for your comments! 
> Thanks,
> Richard.
> 


-- 


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



[Bug fortran/42131] Weird translation of DO loops

2009-11-30 Thread jvdelisle at gcc dot gnu dot org


--- Comment #23 from jvdelisle at gcc dot gnu dot org  2009-11-30 20:19 
---
Thomas, Ido not have email access at the moment.

I reviewed your patch and it is approved for trunk.

Thanks for the work.


-- 


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



[Bug fortran/42131] Weird translation of DO loops

2009-11-30 Thread tkoenig at gcc dot gnu dot org


--- Comment #24 from tkoenig at gcc dot gnu dot org  2009-11-30 20:35 
---
Subject: Bug 42131

Author: tkoenig
Date: Mon Nov 30 20:35:41 2009
New Revision: 154839

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154839
Log:
2009-11-30  Thomas Koenig  

PR fortran/42131
* trans-stmt.c (gfc_trans_do):  Calculate loop count
without if statements.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c


-- 


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



[Bug fortran/42053] [OOP] SELECT TYPE: reject duplicate CLASS IS blocks

2009-11-30 Thread janus at gcc dot gnu dot org


--- Comment #4 from janus at gcc dot gnu dot org  2009-11-30 20:43 ---
Subject: Bug 42053

Author: janus
Date: Mon Nov 30 20:43:06 2009
New Revision: 154840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154840
Log:
merge from fortran-dev branch:


gcc/fortran/

2009-11-30  Janus Weil  

PR fortran/42053
* resolve.c (resolve_select_type): Check for duplicate CLASS IS blocks.

2009-11-30  Janus Weil  

PR fortran/41631
* decl.c (gfc_match_derived_decl): Set extension level.
* gfortran.h (symbol_attribute): Expand 'extension' bit field to 8 bit.
* iresolve.c (gfc_resolve_extends_type_of): Return value of
'is_extension_of' has kind=4.
* match.c (select_type_set_tmp,gfc_match_class_is): Create temporary
for CLASS IS blocks.
* module.c (MOD_VERSION): Bump module version.
(ab_attribute,attr_bits): Remove AB_EXTENSION.
(mio_symbol_attribute): Handle expanded 'extension' field.
* resolve.c (resolve_select_type): Implement CLASS IS blocks.
(resolve_fl_variable_derived): Show correct type name.
* symbol.c (gfc_build_class_symbol): Set extension level.

2009-11-30  Janus Weil  

* intrinsic.h (gfc_resolve_extends_type_of): Add prototype.
* intrinsic.c (add_functions): Use 'gfc_resolve_extends_type_of'.
* iresolve.c (gfc_resolve_extends_type_of): New function, which
replaces the call to EXTENDS_TYPE_OF by the library function
'is_extension_of' and modifies the arguments.
* trans-intrinsic.c (gfc_conv_extends_type_of): Removed.
(gfc_conv_intrinsic_function): FOR EXTENDS_TYPE_OF, don't call
gfc_conv_extends_type_of but gfc_conv_intrinsic_funcall.

2009-11-30  Paul Thomas  
Janus Weil  

* decl.c (encapsulate_class_symbol): Replaced by
'gfc_build_class_symbol'.
(build_sym,build_struct): Call 'gfc_build_class_symbol'.
(gfc_match_derived_decl): Replace vindex by hash_value.
* dump-parse-tree.c (show_symbol): Replace vindex by hash_value.
* gfortran.h (symbol_attribute): Add field 'vtab'.
(gfc_symbol): Replace vindex by hash_value.
(gfc_class_esym_list): Ditto.
(gfc_get_derived_type,gfc_build_class_symbol,gfc_find_derived_vtab):
New prototypes.
* module.c (mio_symbol): Replace vindex by hash_value.
* resolve.c (vindex_expr): Rename to 'hash_value_expr'.
(resolve_class_compcall,resolve_class_typebound_call): Renamed
'vindex_expr'.
(resolve_select_type): Replace $vindex by $vptr->$hash.
* symbol.c (gfc_add_save): Handle vtab symbols.
(gfc_type_compatible): Rewrite.
(gfc_build_class_symbol): New function which replaces
'encapsulate_class_symbol'.
(gfc_find_derived_vtab): New function to set up a vtab symbol for a
derived type.
* trans-decl.c (gfc_create_module_variable): Handle vtab symbols.
* trans-expr.c (select_class_proc): Replace vindex by hash_value.
(gfc_conv_derived_to_class): New function to construct a temporary
CLASS variable from a derived type expression.
(gfc_conv_procedure_call): Call 'gfc_conv_derived_to_class'.
(gfc_conv_structure): Initialize the $extends and $size fields of
vtab symbols.
(gfc_trans_class_assign): Replace $vindex by $vptr. Remove the $size
assignment.
* trans-intrinsic.c (gfc_conv_same_type_as): Replace $vindex by
$vptr->$hash, and replace vindex by hash_value.
* trans-stmt.c (gfc_trans_allocate): Insert $vptr references, replace
$vindex by $vptr. Remove the $size assignment.
* trans-types.c (gfc_get_derived_type): Make it non-static.


gcc/testsuite/

2009-11-30  Janus Weil  

PR fortran/42053
* gfortran.dg/select_type_9.f03: New.

2009-11-30  Janus Weil  

PR fortran/41631
* gfortran.dg/extends_type_of_1.f03: Fix invalid test case.
* gfortran.dg/module_md5_1.f90: Adjusted MD5 sum.
* gfortran.dg/select_type_1.f03: Remove FIXMEs.
* gfortran.dg/select_type_2.f03: Ditto.
* gfortran.dg/select_type_8.f03: New test.

2009-11-30  Janus Weil  

* gfortran.dg/extends_type_of_1.f03: New test.
* gfortran.dg/same_type_as_1.f03: Extended.

2009-11-30  Paul Thomas  

* gfortran.dg/class_4c.f03: Add dg-additional-sources.
* gfortran.dg/class_4d.f03: Rename module. Cleanup modules.


libgfortran/

2009-11-30  Janus Weil  

* gfortran.map: Add _gfortran_is_extension_of.
* Makefile.am: Add intrinsics/extends_type_of.c.
* Makefile.in: Regenerated.
* intrinsics/extends_type_of.c: New file. 

Added:
trunk/gcc/testsuite/gfortran.dg/extends_type_of_1.f03
trunk/gcc/testsuite/gfortran.dg/select_type_8.f03
trunk/gcc/testsuite/gfortran.dg/select_type_9.f03
trunk/libgfortran/intrinsics/extends

[Bug fortran/41631] [OOP] Support CLASS IS () in SELECT TYPE

2009-11-30 Thread janus at gcc dot gnu dot org


--- Comment #2 from janus at gcc dot gnu dot org  2009-11-30 20:43 ---
Subject: Bug 41631

Author: janus
Date: Mon Nov 30 20:43:06 2009
New Revision: 154840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154840
Log:
merge from fortran-dev branch:


gcc/fortran/

2009-11-30  Janus Weil  

PR fortran/42053
* resolve.c (resolve_select_type): Check for duplicate CLASS IS blocks.

2009-11-30  Janus Weil  

PR fortran/41631
* decl.c (gfc_match_derived_decl): Set extension level.
* gfortran.h (symbol_attribute): Expand 'extension' bit field to 8 bit.
* iresolve.c (gfc_resolve_extends_type_of): Return value of
'is_extension_of' has kind=4.
* match.c (select_type_set_tmp,gfc_match_class_is): Create temporary
for CLASS IS blocks.
* module.c (MOD_VERSION): Bump module version.
(ab_attribute,attr_bits): Remove AB_EXTENSION.
(mio_symbol_attribute): Handle expanded 'extension' field.
* resolve.c (resolve_select_type): Implement CLASS IS blocks.
(resolve_fl_variable_derived): Show correct type name.
* symbol.c (gfc_build_class_symbol): Set extension level.

2009-11-30  Janus Weil  

* intrinsic.h (gfc_resolve_extends_type_of): Add prototype.
* intrinsic.c (add_functions): Use 'gfc_resolve_extends_type_of'.
* iresolve.c (gfc_resolve_extends_type_of): New function, which
replaces the call to EXTENDS_TYPE_OF by the library function
'is_extension_of' and modifies the arguments.
* trans-intrinsic.c (gfc_conv_extends_type_of): Removed.
(gfc_conv_intrinsic_function): FOR EXTENDS_TYPE_OF, don't call
gfc_conv_extends_type_of but gfc_conv_intrinsic_funcall.

2009-11-30  Paul Thomas  
Janus Weil  

* decl.c (encapsulate_class_symbol): Replaced by
'gfc_build_class_symbol'.
(build_sym,build_struct): Call 'gfc_build_class_symbol'.
(gfc_match_derived_decl): Replace vindex by hash_value.
* dump-parse-tree.c (show_symbol): Replace vindex by hash_value.
* gfortran.h (symbol_attribute): Add field 'vtab'.
(gfc_symbol): Replace vindex by hash_value.
(gfc_class_esym_list): Ditto.
(gfc_get_derived_type,gfc_build_class_symbol,gfc_find_derived_vtab):
New prototypes.
* module.c (mio_symbol): Replace vindex by hash_value.
* resolve.c (vindex_expr): Rename to 'hash_value_expr'.
(resolve_class_compcall,resolve_class_typebound_call): Renamed
'vindex_expr'.
(resolve_select_type): Replace $vindex by $vptr->$hash.
* symbol.c (gfc_add_save): Handle vtab symbols.
(gfc_type_compatible): Rewrite.
(gfc_build_class_symbol): New function which replaces
'encapsulate_class_symbol'.
(gfc_find_derived_vtab): New function to set up a vtab symbol for a
derived type.
* trans-decl.c (gfc_create_module_variable): Handle vtab symbols.
* trans-expr.c (select_class_proc): Replace vindex by hash_value.
(gfc_conv_derived_to_class): New function to construct a temporary
CLASS variable from a derived type expression.
(gfc_conv_procedure_call): Call 'gfc_conv_derived_to_class'.
(gfc_conv_structure): Initialize the $extends and $size fields of
vtab symbols.
(gfc_trans_class_assign): Replace $vindex by $vptr. Remove the $size
assignment.
* trans-intrinsic.c (gfc_conv_same_type_as): Replace $vindex by
$vptr->$hash, and replace vindex by hash_value.
* trans-stmt.c (gfc_trans_allocate): Insert $vptr references, replace
$vindex by $vptr. Remove the $size assignment.
* trans-types.c (gfc_get_derived_type): Make it non-static.


gcc/testsuite/

2009-11-30  Janus Weil  

PR fortran/42053
* gfortran.dg/select_type_9.f03: New.

2009-11-30  Janus Weil  

PR fortran/41631
* gfortran.dg/extends_type_of_1.f03: Fix invalid test case.
* gfortran.dg/module_md5_1.f90: Adjusted MD5 sum.
* gfortran.dg/select_type_1.f03: Remove FIXMEs.
* gfortran.dg/select_type_2.f03: Ditto.
* gfortran.dg/select_type_8.f03: New test.

2009-11-30  Janus Weil  

* gfortran.dg/extends_type_of_1.f03: New test.
* gfortran.dg/same_type_as_1.f03: Extended.

2009-11-30  Paul Thomas  

* gfortran.dg/class_4c.f03: Add dg-additional-sources.
* gfortran.dg/class_4d.f03: Rename module. Cleanup modules.


libgfortran/

2009-11-30  Janus Weil  

* gfortran.map: Add _gfortran_is_extension_of.
* Makefile.am: Add intrinsics/extends_type_of.c.
* Makefile.in: Regenerated.
* intrinsics/extends_type_of.c: New file. 

Added:
trunk/gcc/testsuite/gfortran.dg/extends_type_of_1.f03
trunk/gcc/testsuite/gfortran.dg/select_type_8.f03
trunk/gcc/testsuite/gfortran.dg/select_type_9.f03
trunk/libgfortran/intrinsics/extends

[Bug c++/38600] Trouble mangling template_id_expr

2009-11-30 Thread jason at gcc dot gnu dot org


--- Comment #7 from jason at gcc dot gnu dot org  2009-11-30 20:46 ---
Or vice versa, I like this testcase better :)


-- 


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



[Bug fortran/42131] Weird translation of DO loops

2009-11-30 Thread tkoenig at gcc dot gnu dot org


--- Comment #25 from tkoenig at gcc dot gnu dot org  2009-11-30 21:01 
---
Fixed on trunk. Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug fortran/42053] [OOP] SELECT TYPE: reject duplicate CLASS IS blocks

2009-11-30 Thread janus at gcc dot gnu dot org


--- Comment #5 from janus at gcc dot gnu dot org  2009-11-30 21:24 ---
Fixed on trunk with r154840.


-- 


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



[Bug fortran/41631] [OOP] Support CLASS IS () in SELECT TYPE

2009-11-30 Thread janus at gcc dot gnu dot org


--- Comment #3 from janus at gcc dot gnu dot org  2009-11-30 21:25 ---
Fixed on trunk with r154840.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

2009-11-30 Thread pthaugen at gcc dot gnu dot org


--- Comment #25 from pthaugen at gcc dot gnu dot org  2009-11-30 21:29 
---
I am still seeing the 2-block loop using revision 154838, both 32 and 64 bit,
compile options -O3 -mcpu=power6 -funroll-loops.


-- 


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



[Bug c++/42233] c++ builtin_expect code generation regression

2009-11-30 Thread gmorin1 at bloomberg dot net


--- Comment #3 from gmorin1 at bloomberg dot net  2009-11-30 22:06 ---
The trunk g++ output looks good.  As I said, there is a simple workaround.  But
since this is a regression from 4.1, a fix in 4.4 would be nice.
Additionally, it would be great if you could document the full scope of the bug
(like if all conditions can trigger this etc) and if there is any simpler
workaround.


-- 


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



[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors

2009-11-30 Thread ebotcazou at gcc dot gnu dot org


--- Comment #16 from ebotcazou at gcc dot gnu dot org  2009-11-30 22:08 
---
> The issue with the boolean_type_node is that the middle-end does not have
> a type for a comparison result but implicitly assumes boolean_type_node.
> 
> So for
> 
>   D._16 = (boolean) D._6;
>   if (D._16 != 0)
> 
> with a re-set boolean_type_node we fold this to D._6 != 0, with
> the original Ada boolean_type_node we do not.  The C frontend for
> decaying to bool always produces a comparison btw, not the truncation
> we see above (and it only truncates to 8 bits).

There is no decaying to bool in Ada, all boolean values come from truth values
or other boolean values.  However, gigi first generates all the truth values in
integer_type_node before converting them to a boolean type.

> I think for 4.5 we should admit defeat and disable free-lang-data
> unconditionally if not using LTO.

That seems sensible to me.  I plan on revisiting this boolean stuff for 4.6 (as
well as the sizetype thing, but this looks like much trickier).


-- 


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



[Bug middle-end/42130] [graphite-branch] dealII fails

2009-11-30 Thread grosser at gcc dot gnu dot org


--- Comment #6 from grosser at gcc dot gnu dot org  2009-11-30 22:08 ---
Subject: Bug 42130

Author: grosser
Date: Mon Nov 30 22:07:59 2009
New Revision: 154849

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154849
Log:
Protect loops that might be executed zero times.

2009-11-23  Tobias Grosser  

PR middle-end/42130
* graphite-clast-to-gimple.c (graphite_create_new_loop_guard,
translate_clast_for_loop): New.
(translate_clast_for): Add a condition around the loop, to do not
execute loops with zero iterations.
* testsuite/g++.dg/graphite/pr42130.C: New.
* testsuite/gcc.dg/graphite/pr35356-2.c: Adapt.

Added:
trunk/gcc/testsuite/g++.dg/graphite/pr42130.C
Modified:
trunk/gcc/ChangeLog.graphite
trunk/gcc/graphite-clast-to-gimple.c
trunk/gcc/testsuite/gcc.dg/graphite/pr35356-2.c


-- 


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



[Bug middle-end/41551] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

2009-11-30 Thread sje at cup dot hp dot com


--- Comment #3 from sje at cup dot hp dot com  2009-11-30 22:10 ---
Fixed in r154843, test case added in gcc.dg/pr41551.c.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug middle-end/42193] [4.5 Regression] 454.calculix in SPEC CPU 2006 failed to compile at -O3

2009-11-30 Thread hjl dot tools at gmail dot com


--- Comment #5 from hjl dot tools at gmail dot com  2009-11-30 22:21 ---
Fixed


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

2009-11-30 Thread jamborm at gcc dot gnu dot org


--- Comment #6 from jamborm at gcc dot gnu dot org  2009-11-30 22:22 ---
The lattices are OK per se.  Lattices really only represent arguments
of calls that are represented in the call graph.  When there might be
other calls that are not represented in the graph, the function body
is cloned and the original should be used for those.  But it appears
it isn't.  (In fact it is always cloned because that's how replacement
with constants works.)

Specifically, the problem is that the wrong version of callback is
_inlined_ into CallFunctionRec.  Since indirect inlining is not
involved, I'm surprised that this indirect call is inlined.  So it all
comes down to the fact that we have a wrong edge in the call graph
after ipa-cp.

This happens in the following way:

1. CallFunctionRec is cloned because fun is constant.  fun is replaced
   by callback in the call statement.  It then calls rebuild
   cgraph_edges so that a call graph edge is created for the statement
   (among other things, I believe cgraph verifier mandates this).

2. callback is cloned.  IPA-CP does a rather nasty trick when
   redirecting callers:  It redirects all of them and then figures out
   later when it was wrong.  However a clone calling a clone is
   considered always safe.  That would be so, however, only if the
   edge we created in the previous cloning was also part of the
   call graph when we did our analysis.  But we added it later.

We do not have this issue in trunk at least since may because the
clone is now virtual, has no body and so we do not rebuild outgoing
call graph edges in this way.  (In fact, for the sake of indirect
inlining, we should be creating these edges too.)

Anyway, my proposed fix would be to replace the call
rebuild_cgraph_edges in ipcp_update_cloned_node with something that
just adds new call graph edges and also marks the new ones as
indirect.  Then it would be enough to tell ipcp_update_callgraph to
redirect these edges back to (hm, actually from) the original nodes as
well.

If there are no objections, I'll prepare a patch along these lines in
the next few days.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jh at suse dot cz


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



[Bug c++/42217] [4.5 Regression] ICE with zero-length bit-field

2009-11-30 Thread dodji at gcc dot gnu dot org


--- Comment #2 from dodji at gcc dot gnu dot org  2009-11-30 22:39 ---
Submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01767.html


-- 


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



[Bug c++/38712] can't mangle template-id g(t)

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #5 from paolo dot carlini at oracle dot com  2009-11-30 22:41 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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



[Bug c++/38600] Trouble mangling template_id_expr

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #8 from paolo dot carlini at oracle dot com  2009-11-30 22:41 
---
*** Bug 38712 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||cfairles at gcc dot gnu dot
   ||org


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



[Bug testsuite/42086] FAIL: gcc.target/ia64/fptr-1.c execution test

2009-11-30 Thread sje at cup dot hp dot com


--- Comment #3 from sje at cup dot hp dot com  2009-11-30 22:41 ---
Fixed.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug c++/38600] Trouble mangling template_id_expr

2009-11-30 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|jason at gcc dot gnu dot org|
 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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



[Bug c++/40371] ICE with template operator

2009-11-30 Thread paolo at gcc dot gnu dot org


--- Comment #3 from paolo at gcc dot gnu dot org  2009-11-30 22:45 ---
Subject: Bug 40371

Author: paolo
Date: Mon Nov 30 22:45:06 2009
New Revision: 154852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154852
Log:
cp/
2009-11-30  Paolo Carlini  

PR c++/40371
* call.c (add_template_candidate_real): Early return NULL if
the arglist length is smaller than skip_without_in_chrg; tidy.

testsuite/
2009-11-30  Paolo Carlini  

PR c++/40371
* g++.dg/template/crash93.C: New.

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


-- 


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



[Bug c++/40371] ICE with template operator

2009-11-30 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2009-11-30 22:46 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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



[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code

2009-11-30 Thread dodji at gcc dot gnu dot org


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|dodji at gcc dot gnu dot org|
 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-30 10:32:44 |2009-11-30 23:01:09
   date||


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



[Bug fortran/42144] [OOP] deferred TBPs do not work

2009-11-30 Thread janus at gcc dot gnu dot org


--- Comment #2 from janus at gcc dot gnu dot org  2009-11-30 23:03 ---
(In reply to comment #0)
> This gives
> 
> undefined reference to `create_interface_'
> 
> when linking. 'create_interface' is the abstract interface of the deferred 
> TBP.
> Instead of calling this, one should do the same as for other TBPs.

One correctly runs into 'select_class_proc' also for deferred TBPs. We just
need to suppress the call for the basetype (check for abstract type).


-- 


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



[Bug libffi/35484] libffi doesn't support AIX 64bit

2009-11-30 Thread dje at gcc dot gnu dot org


--- Comment #5 from dje at gcc dot gnu dot org  2009-11-30 23:34 ---
Subject: Bug 35484

Author: dje
Date: Mon Nov 30 23:34:33 2009
New Revision: 154855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154855
Log:
2009-11-30  David Edelsohn  

PR target/35484
* src/powerpc/ffitarget.h (POWERPC64): Define for PPC64 Linux and
AIX64.
* src/powerpc/aix.S: Implement AIX64 version.
* src/powerpc/aix_closure.S: Implement AIX64 version.
(ffi_closure_ASM): Use extsb, lha and displament addresses.
* src/powerpc/ffi_darwin.c (ffi_prep_args): Implement AIX64
support.
(ffi_prep_cif_machdep): Same.
(ffi_call): Same.
(ffi_closure_helper_DARWIN): Same.

Modified:
trunk/libffi/ChangeLog
trunk/libffi/src/powerpc/aix.S
trunk/libffi/src/powerpc/aix_closure.S
trunk/libffi/src/powerpc/ffi_darwin.c
trunk/libffi/src/powerpc/ffitarget.h


-- 


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



[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code

2009-11-30 Thread dodji at gcc dot gnu dot org


--- Comment #3 from dodji at gcc dot gnu dot org  2009-12-01 00:26 ---
A reduced test case seems to be:

~=~
template
struct A
{
typedef T I;
};

template
struct B
{   
typedef T TT;
typedef typename TT::I TT_I;
typedef A TA;
};  

template
void  
foo() 
{
typedef T TT;
typedef typename TT::I TT_I;
typedef A TA;
}

int
main ()
{
foo >();
}
~=~

It ICEs with:
test.cc:27:18:   instantiated from here
test.cc:21:21: internal compiler error: tree check: accessed elt 2 of tree_vec
with 1 elts in tsubst, at cp/pt.c:9823


-- 


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



[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code

2009-11-30 Thread hjl dot tools at gmail dot com


--- Comment #4 from hjl dot tools at gmail dot com  2009-12-01 00:27 ---
It is caused by revision 145440:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html


-- 


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



  1   2   >