[Bug c/44517] improve diagnostic for mispelled typename in function declaration

[pzhao at gcc dot gnu dot org]

--- Comment #2 from pzhao at gcc dot gnu dot org  2010-06-25 07:32 ---
Subject: Bug 44517

Author: pzhao
Date: Fri Jun 25 07:31:49 2010
New Revision: 161363

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161363
Log:
gcc/
2010-06-25  Shujing Zhao  

PR c/44517
* c-parser.c (c_parser_parms_list_declarator): Return NULL if one of
parameters are not good.
(c_parser_parameter_declaration): Error unknown type name if the type
name can't start declaration specifiers.

gcc/testsuite/
2010-06-25  Shujing Zhao  

PR c/44517
* gcc.dg/noncompile/pr44517.c: New.
* gcc.dg/noncompile/990416-1.c: Adjust expected error.


Added:
trunk/gcc/testsuite/gcc.dg/noncompile/pr44517.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/noncompile/990416-1.c


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2010-06-25 08:13 ---
Created an attachment (id=21000)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21000&action=view)
gcc46-pr43866.patch

Here is a complete fix.

This includes what the earlier two patches did, plus for nested
tree_unswitch_single_loop call in the first pass optimizes all conditions using
entry tests, then if there are some possible unswitching condition candidates
does a still reachable loop bb discovery and only considers bbs in still
unreachable bbs.

Not copying the unreachable blocks would be IMHO harder.  The current pass was
trying to be very simple, not modify the original loop, just duplicate it and
add a guard condition in front of the two loops, then in the nested call just
simplify conditions using the entry checks and leave all the cleanups to cfg
cleanup after the pass (e.g. to avoid redoing loop discovery etc.).

With the patch pr43866.s is actually smaller, eventhough more loops are
unswitched (previously some of the 15 unswitched loops were on 0 != 0 or 1 != 0
conditions and thus thrown away immediately).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20997|0   |1
is obsolete||
  Attachment #20998|0   |1
is obsolete||
 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[bernds at gcc dot gnu dot org]

--- Comment #13 from bernds at gcc dot gnu dot org  2010-06-25 08:56 ---
Subject: Bug 43902

Author: bernds
Date: Fri Jun 25 08:56:24 2010
New Revision: 161366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161366
Log:
With large parts from Jim Wilson:
PR target/43902
* tree-pretty-print.c (dump_generic_node, op_code_prio): Add
WIDEN_MULT_PLUS_EXPR and WIDEN_MULT_MINUS_EXPR.
* optabs.c (optab_for_tree_code): Likewise.
(expand_widen_pattern_expr): Likewise.
* tree-ssa-math-opts.c (convert_mult_to_widen): New function, broken
out of execute_optimize_widening_mul.
(convert_plusminus_to_widen): New function.
(execute_optimize_widening_mul): Use the two new functions.
* expr.c (expand_expr_real_2): Add support for GIMPLE_TERNARY_RHS.
Remove code to generate widening multiply-accumulate.  Add support
for WIDEN_MULT_PLUS_EXPR and WIDEN_MULT_MINUS_EXPR.
* gimple-pretty-print.c (dump_ternary_rhs): New function.
(dump_gimple_assign): Call it when appropriate.
* tree.def (WIDEN_MULT_PLUS_EXPR, WIDEN_MULT_MINUS_EXPR): New codes.
* cfgexpand.c (gimple_assign_rhs_to_tree): Likewise.
(expand_gimple_stmt_1): Likewise.
(expand_debug_expr): Support WIDEN_MULT_PLUS_EXPR and
WIDEN_MULT_MINUS_EXPR.
* tree-ssa-operands.c (get_expr_operands): Likewise.
* tree-inline.c (estimate_operator_cost): Likewise.
* gimple.c (extract_ops_from_tree_1): Renamed from
extract_ops_from_tree.  Add new arg for a third operand; fill it.
(gimple_build_assign_stat): Support operations with three operands.
(gimple_build_assign_with_ops_stat): Likewise.
(gimple_assign_set_rhs_from_tree): Likewise.
(gimple_assign_set_rhs_with_ops_1): Renamed from
gimple_assign_set_rhs_with_ops.  Add new arg for a third operand.
(get_gimple_rhs_num_ops): Support GIMPLE_TERNARY_RHS.
(get_gimple_rhs_num_ops): Handle WIDEN_MULT_PLUS_EXPR and
WIDEN_MULT_MINUS_EXPR.
* gimple.h (enum gimple_rhs_class): Add GIMPLE_TERNARY_RHS.
(extract_ops_from_tree_1): Adjust declaration.
(gimple_assign_set_rhs_with_ops_1): Likewise.
(gimple_build_assign_with_ops): Pass NULL for last operand.
(gimple_build_assign_with_ops3): New macro.
(gimple_assign_rhs3, gimple_assign_rhs3_ptr, gimple_assign_set_rhs3,
gimple_assign_set_rhs_with_ops, extract_ops_from_tree): New inline
functions.
* tree-cfg.c (verify_gimple_assign_ternary): New static function.
(verify_gimple_assign): Call it.
* doc/gimple.texi (Manipulating operands): Document GIMPLE_TERNARY_RHS.
(Tuple specific accessors, subsection GIMPLE_ASSIGN): Document new
functions for dealing with three-operand statements.
* tree.c (commutative_ternary_tree_code): New function.
* tree.h (commutative_ternary_tree_code): Declare it.
* tree-vrp.c (gimple_assign_nonnegative_warnv_p): Return false for
ternary
statements.
(gimple_assign_nonzero_warnv_p): Likewise.
* tree-ssa-sccvn.c (stmt_has_constants): Handle GIMPLE_TERNARY_RHS.
* tree-ssa-ccp.c (get_rhs_assign_op_for_ccp): New static function.
(ccp_fold): Use it.  Handle GIMPLE_TERNARY_RHS.
* tree-ssa-dom.c (enum expr_kind): Add EXPR_TERNARY.
(struct hashtable_expr): New member ternary in the union.
(initialize_hash_element): Handle GIMPLE_TERNARY_RHS.
(hashable_expr_equal_p): Fix indentation.  Handle EXPR_TERNARY.
(iterative_hash_hashable_expr): Likewise.
(print_expr_hash_elt): Handle EXPR_TERNARY.
* gimple-fold.c (fold_gimple_assign): Handle GIMPLE_TERNARY_RHS.
* tree-ssa-threadedge.c (fold_assignment_stmt): Remove useless break
statements.  Handle GIMPLE_TERNARY_RHS.

testsuite/
PR target/43902
* gcc.target/mips/madd-9.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/mips/madd-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/doc/gimple.texi
trunk/gcc/expr.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/gimple.c
trunk/gcc/gimple.h
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-math-opts.c
trunk/gcc/tree-ssa-operands.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-threadedge.c
trunk/gcc/tree-vrp.c
trunk/gcc/tree.c
trunk/gcc/tree.def
trunk/gcc/tree.h


-- 


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

[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling

[borntraeger at de dot ibm dot com]

--- Comment #3 from borntraeger at de dot ibm dot com  2010-06-25 09:02 
---
Created an attachment (id=21001)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001&action=view)
Potential fix for compile time regression

Here is a potential fix. We just limit prefetching to loops with a "low" amount
of memory references and bail out if the amount of references is too large.


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[rakdver at gcc dot gnu dot org]

--- Comment #16 from rakdver at gcc dot gnu dot org  2010-06-25 09:04 
---
> Now, in the first loop if we decide to unswitch on cond3, it transforms this
> into:
...
> If cond3 tests some variable that is initialized only if cond1 is false, this
> unswitching (besides not being very useful because cond3 is never tested when
> cond1 is false in the original program) results in jumps on uninitialized
> values comparison.

while unswitching on cond3 indeed does not make sense, I don't think it can
result in a jump on uninitialized value comparison.  Unswitching only works if
the arguments of the comparison are ssa names whose values are computed outside
of the loop (it does not do invariant motion by itself).  So, the computations
based on uninitialized values would have to be introduced by some other pass
(possibly invariant motion).


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[rakdver at gcc dot gnu dot org]

--- Comment #17 from rakdver at gcc dot gnu dot org  2010-06-25 09:12 
---
(In reply to comment #16)
> > Now, in the first loop if we decide to unswitch on cond3, it transforms this
> > into:
> ...
> > If cond3 tests some variable that is initialized only if cond1 is false, 
> > this
> > unswitching (besides not being very useful because cond3 is never tested 
> > when
> > cond1 is false in the original program) results in jumps on uninitialized
> > values comparison.
> 
> while unswitching on cond3 indeed does not make sense, I don't think it can
> result in a jump on uninitialized value comparison.  Unswitching only works if
> the arguments of the comparison are ssa names whose values are computed 
> outside
> of the loop (it does not do invariant motion by itself).  So, the computations
> based on uninitialized values would have to be introduced by some other pass
> (possibly invariant motion).

unless the arguments of the comparison are completely uninitialized (their
values are not defined in the function and are not parameters of the function),
of course -- is that the case here?  We should avoid unswitching on such
conditions (in addition to the proposed patch), since the comparison could be
unreachable due to some reason that cannot be detected in compile-time.


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jakub at gcc dot gnu dot org]

--- Comment #18 from jakub at gcc dot gnu dot org  2010-06-25 09:14 ---
That part comes from the questionable testcase, which does
a_sp => matrix%local_data_sp
before the loop unconditionally, eventhough matrix%local_data_sp is
uninitialized unless use_sp is .true.
Without the unswitching the values from the uninitialized struct
matrix%local_data_sp are read, but not tested when use_sp is .false.


-- 


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

[Bug fortran/44662] New: unitialized memory on testcases abstract_type_6.f03 and typebound_call_4.f03

[mikael at gcc dot gnu dot org]

I think this was not reported yet, and both refer to the same problem.


-- 
   Summary: unitialized memory on testcases abstract_type_6.f03 and
typebound_call_4.f03
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael at gcc dot gnu dot org


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

[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-06-25 09:17 ---
(In reply to comment #10)
> What language is GAMESS written in? 

Fortran, of course. See: http://www.spec.org/cpu2006/Docs/416.gamess.html
and http://www.msg.ameslab.gov/GAMESS/GAMESS.html

> The above simply is not Fortran.  EQUIVALENCE is a specification-statement.
> It cannot appear after an executable-statement.

Well, it is invalid code - based on a valid Fortran code. If you use Delta to
reduce a test case (cf. http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
it simply removes lines of the source code using a constraint. I think
Sebastian's constraint was that it segfaults. This seemingly happens for the
unmodified gamess due to a Graphite bug - but also due to a buggy error
recovery in gfortran.

Thus, this PR is about an ice-on-INVALID-code and error-recovery bug, thus, it
has a lower priority than wrong-code bugs; nevertheless, it is a regression.

 * * *

Regarding the PR: For the test case in comment 0, one finds in gdb:

(gdb) p eq->expr->symtree->n.sym
$1 = (gfc_symbol *) 0x13fae6d
(gdb) p eq->expr->symtree->n.sym->name
$2 = 0x0
(gdb) p eq->expr->symtree->n.sym->ts
$3 = {type = 0, kind = 0, u = {derived = 0x0, cl = 0x0}, interface = 0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = 0}

That means that the symbol is only half present, i.e. it exists in the symtree,
but seemingly, the values have not been set.


The next item in the list is eq->eq, for which
  (gdb) p eq->eq->expr
  $8 = (gfc_expr *) 0x1395700
  (gdb) p eq->eq->expr->symtree
  $9 = (gfc_symtree *) 0x13a3110
but
  (gdb) p eq->eq->expr->symtree->n.sym
  $10 = (gfc_symbol *) 0x0

Thus, for the case, adding a patch like in comment 1 and in comment 5 works.
Even with both checks added, it will fail later (for comment 0's test case)
because of
  12642 if (sym->ns->proc_name
as sym->ns == NULL.

One can, of course, put more checks in, e.g., whether
eq->expr->symtree->n.sym->name == NULL or whether sym->ns == NULL, but the
question is whether one should not fix it earlier.

Currently, the program is walked like this:

  parse_progunit -> parse_executable -> next_statement

if the next_statement is not an executable statement (which ST_EQUIVALENCE is
not), parse_executable returns - and parse_progunit calls:
  unexpected_statement (st);
  reject_statement ();

Thus, seemingly, reject_statement leaves the symtree in a half-existing state.
It calls:  gfc_undo_symbols () and undo_new_statement (). I think the former
one only does a partial cleanup.


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jakub at gcc dot gnu dot org]

--- Comment #19 from jakub at gcc dot gnu dot org  2010-06-25 09:19 ---
The compiler doesn't know that matrix%local_data_sp is uninitialized (at least
unless it would propagate that info in some IPA pass), matrix%local_data_sp is
a field in what an arguments points at (and the argument is known to be
non-NULL).


-- 


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

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu dot org]

--- Comment #12 from mikael at gcc dot gnu dot org  2010-06-25 09:27 ---
(In reply to comment #11)
> However, regressions are now on transpose :
>  - alloc_comp_transformational_1.f90 : double free on function exit. I will
> have to investigate.
Fixed

>  - char_length_8.f90 : reshape doesn't like being passed a transposed array as
> target argument because the shape doesn't match then. I will look if i can fix
> reshape without recursing into some other regression.
Fixed.

>  - transpose_2.f90 : I will have to see if it is a real regression or if only
> the error message has changed. 
The error message has changed, no real regression. 

> 
> There is also this strange one.
>  - pr43984.f90 : memory allocation error at compile time (???!!)
It was a double free, fixed.  


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jv244 at cam dot ac dot uk]

--- Comment #20 from jv244 at cam dot ac dot uk  2010-06-25 09:28 ---
(In reply to comment #18)
> That part comes from the questionable testcase, which does
> a_sp => matrix%local_data_sp
> before the loop unconditionally, eventhough matrix%local_data_sp is
> uninitialized unless use_sp is .true.

thanks for looking into the bug report. Actually the testcase can be turned in
'unquestionable' by adding a 'NULLIFY(a%local_data_sp)' in the main program. At
that point the pointer assignment (a_sp => matrix%local_data_sp) makes a_sp
defined, but valgrind still yields an error.


-- 


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

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu dot org]

--- Comment #13 from mikael at gcc dot gnu dot org  2010-06-25 09:34 ---
Created an attachment (id=21002)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21002&action=view)
Updated patch

As I was having memory corruption regressions, I started to run valgrind on
some testcases, whose fixes brought new memory problems, and so on.
Now the patch contains a non negligible part of completely unrelated memory
fixes, and also random other things (dead code removal, if-blocks turned into
asserts, ...).


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20726|0   |1
is obsolete||


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

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu dot org]

--- Comment #14 from mikael at gcc dot gnu dot org  2010-06-25 09:36 ---
TODO:
 * testcases to check anything that might be impacted by the patch
 * split the patch for review & commit


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2010-06-25 09:38 ---
True.  Most of the fields of the pointer are still uninitialized (NULLIFY only
clears the data field).
I'm afraid when NULLIFY doesn't clear the whole struct there will be always a
possibility valgrind might complain, the tree optimizers see the comparison as
not having any side-effects, not possibly trapping etc., so some pass might
exchange the two comparisons somewhere.  But worse case it would be just a
valgrind warning, conditional jump based on uninitialized values which in the
end wouldn't have any runtime visible effect.

This patch doesn't try to do anything about that, just improve unswitching such
that it chooses conditions that it can usefully unswitch on (and not unswitch
on always false/true conditions).


-- 


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

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu dot org]

--- Comment #15 from mikael at gcc dot gnu dot org  2010-06-25 09:42 ---
Isn't there a problem with the size of the patch ?
pr43829_3.diff  46.78 KB

I get here:
% du -h pr43829_3.diff  
240Kpr43829_3.diff
%

At least it is not truncated (I have just checked).


-- 


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

[Bug fortran/44662] unitialized memory on testcases abstract_type_6.f03 and typebound_call_4.f03

[mikael at gcc dot gnu dot org]

--- Comment #1 from mikael at gcc dot gnu dot org  2010-06-25 09:45 ---
It is fixed by the patch at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13


-- 


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

[Bug fortran/43829] Scalarization of reductions

[rguenther at suse dot de]

--- Comment #16 from rguenther at suse dot de  2010-06-25 09:45 ---
Subject: Re:  Scalarization of reductions

On Fri, 25 Jun 2010, mikael at gcc dot gnu dot org wrote:

> --- Comment #15 from mikael at gcc dot gnu dot org  2010-06-25 09:42 
> ---
> Isn't there a problem with the size of the patch ?
> pr43829_3.diff  46.78 KB
> 
> I get here:
> % du -h pr43829_3.diff  
> 240Kpr43829_3.diff
> %
> 
> At least it is not truncated (I have just checked).

Downloading it shows

/tmp> du -h attachment.cgi?id=21002
220Kattachment.cgi?id=21002

so I guess bugzilla reports compressed size (it stores compresses 
plaintext)

Richard.


-- 


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

[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()

[mikael at gcc dot gnu dot org]

--- Comment #12 from mikael at gcc dot gnu dot org  2010-06-25 10:32 ---
(In reply to comment #11)
> Thus, seemingly, reject_statement leaves the symtree in a half-existing state.
> It calls:  gfc_undo_symbols () and undo_new_statement (). I think the former
> one only does a partial cleanup.
> 

My understanding is that gfc_undo_symbols indeed cleans the symbol, but the old
symbol pointer escapes through the equivalence list.


-- 


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

[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()

[mikael at gcc dot gnu dot org]

--- Comment #13 from mikael at gcc dot gnu dot org  2010-06-25 10:33 ---
Created an attachment (id=21003)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003&action=view)
patch against my (diry) tree

patch restoring the old equivalence list on reject_statement ()


-- 


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

[Bug c/44555] [4.3/4.4/4.5 Regression] Pointer evalutions, is that expected ?

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-06-25 10:35 
---
Subject: Bug 44555

Author: rguenth
Date: Fri Jun 25 10:35:40 2010
New Revision: 161370

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161370
Log:
2010-06-25  Richard Guenther  

Backport from mainline
2010-06-16  Richard Guenther  

PR c/44555
* c-common.c (c_common_truthvalue_conversion): Remove
premature and wrong optimization concering ADDR_EXPRs.

* gcc.c-torture/execute/pr44555.c: New testcase.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr44555.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


-- 


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

[Bug libstdc++/44663] New: missed GXX_EXPERIMENTAL guards in ?

[pluto at agmk dot net]

hi,

the latest llvm/clang++ reports an error during parsing 
included from :

In file included from t00.cpp:1:
In file included from /usr/include/c++/4.5.0/tr1/functional:39:
/usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates are only
allowed in C++0x
  template

afaics there's no #ifdef __GXX_EXPERIMENTAL... guards but...

http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.html#manual.intro.status.standard.200x

(...)
In this implementation -std=gnu++0x or -std=c++0x flags must be used
to enable language and library features. The pre-defined symbol
__GXX_EXPERIMENTAL_CXX0X__ is used to check for the presence of
the required flag.
(...)


-- 
   Summary: missed GXX_EXPERIMENTAL guards in ?
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
  GCC host triplet: x86_64-gnu-linux


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

[Bug libstdc++/44663] missed GXX_EXPERIMENTAL guards in ?

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-06-25 11:08 ---
(In reply to comment #0)
> the latest llvm/clang++ reports an error during parsing 
> included from :
> 
> In file included from t00.cpp:1:
> In file included from /usr/include/c++/4.5.0/tr1/functional:39:
> /usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates are only
> allowed in C++0x

That's Clang's problem, not GCC's :-)

They are supported as an extension in g++, so we can use them to implement
components like tr1::tuple.  (I think the original implementation of variadic
templates was done by Douglas Gregor, who's now working on Clang.)

See also Bug 43824


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/44592] [4.5/4.6 Regression] wrong code at -O3

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-25 11:26 ---
This goes wrong with -O2 -funroll-loops already during tree opts.  In vrp2 we
have:
  b[2][1]{lb: 1 sz: 1} = D.1599_148;
  b[3][1]{lb: 1 sz: 1} = D.1599_154;
  D.1635_152 = 2;
  D.1636_151 = &b[2][1]{lb: 1 sz: 1};
  D.1637_146 = 3;
  D.1638_145 = &b[3][1]{lb: 1 sz: 1};
  __builtin_memcpy (D.1638_145, D.1636_151, 1);
...
  D.1647_84 = b[3][1]{lb: 1 sz: 1};
  D.1648_85 = A.5[3];
  D.1649_86 = (*D.1648_85)[1]{lb: 1 sz: 1};
  if (D.1647_84 != D.1649_86)

but in dom2:
  b[2][1]{lb: 1 sz: 1} = D.1599_148;
  b[3][1]{lb: 1 sz: 1} = D.1599_154;
  D.1635_152 = 2;
  D.1636_151 = &b[2][1]{lb: 1 sz: 1};
  D.1637_146 = 3;
  D.1638_145 = &b[3][1]{lb: 1 sz: 1};
  D.1680_170 = b[2][1]{lb: 1 sz: 1};
  b[3][1]{lb: 1 sz: 1} = D.1680_170;
...
  D.1647_84 = D.1599_154;
  D.1648_85 = A.5[3];
  D.1649_86 = (*D.1648_85)[1]{lb: 1 sz: 1};
  if (D.1649_86 != D.1599_154)

b[3] at that point isn't D.1599_154 though, but D.1599_148 (== D.1680_170).


-- 


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

[Bug fortran/44662] unitialized memory on testcases abstract_type_6.f03 and typebound_call_4.f03

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2010-06-25 11:29 ---
(In reply to comment #1)
> It is fixed by the patch at:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
> 

relevant hunk:

diff --git a/decl.c b/decl.c
index aa7a266..840c32c 100644
--- a/decl.c
+++ b/decl.c
@@ -7622,8 +7630,8 @@ match_procedure_in_type (void)
 }

   /* Construct the data structure.  */
+  memset (&tb, 0, sizeof (tb));
   tb.where = gfc_current_locus;
-  tb.is_generic = 0;

   /* Match binding attributes.  */
   m = match_binding_attributes (&tb, false, false);


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug c/44517] improve diagnostic for mispelled typename in function declaration

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-06-25 11:49 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug libstdc++/44663] missed GXX_EXPERIMENTAL guards in ?

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-06-25 11:55 ---
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.other_compilers

If the guards were there as you suggest, tr1::tuple would only be usable in
C++0x mode, where it's redundant because you have std::tuple anyway.

g++ is the only compiler officially supported by libstdc++, so personally I'm
opposed to disabling functionality to support other compilers.  I'm not opposed
to changes that don't affect functionality for g++ users e.g. if non-standard
features are used unnecessarily and could be replaced with equivalent standard
features.  That doesn't apply here, as the advantages of variadic templates are
huge.


-- 


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

[Bug libstdc++/44663] missed GXX_EXPERIMENTAL guards in ?

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-06-25 11:59 
---
Totally agree.


-- 


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

[Bug tree-optimization/44539] [4.6 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-06-25 12:07 ---
Subject: Bug 44539

Author: jakub
Date: Fri Jun 25 12:07:00 2010
New Revision: 161374

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161374
Log:
PR tree-optimization/44539
* tree-cfgcleanup.c (fixup_noreturn_call): Call update_stmt even when
the call doesn't have LHS, but has VDEF.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr44539.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfgcleanup.c


-- 


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jakub at gcc dot gnu dot org]

--- Comment #22 from jakub at gcc dot gnu dot org  2010-06-25 12:11 ---
Subject: Bug 43866

Author: jakub
Date: Fri Jun 25 12:10:42 2010
New Revision: 161375

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161375
Log:
PR middle-end/43866
* tree-ssa-loop-unswitch.c (tree_may_unswitch_on): If stmt is always
true or always false, return NULL_TREE.
(tree_unswitch_single_loop): Optimize conditions even when reaching
max-unswitch-level parameter.  If num > 0, optimize first all
conditions
using entry checks, then do still reachable block discovery and
consider
only conditions in still reachable basic blocks in the loop.

* gfortran.dg/pr43866.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr43866.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-unswitch.c


-- 


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

[Bug debug/44664] New: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[jan dot kratochvil at redhat dot com]

Unaware of any current (GDB) problems from it.

echo 'class C { public: C () {} }; int main() { C c; }' | g++ -Wall -g -x c++ -

FAIL g++ (GCC) 4.4.5 20100625 (prerelease)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
FAIL g++ (GCC) 4.6.0 20100625 (experimental) [under the test below]

  Compilation Unit @ offset 0x0:
   Version:   2
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c>   DW_AT_producer: (indirect string, offset: 0x16): GNU C++ 4.6.0
20100625 (experimental)
<10>   DW_AT_language: 4(C++)
<15>   DW_AT_low_pc  : 0x0
DW_AT_low_pc   DW_FORM_addr
<1d>   DW_AT_entry_pc: 0x0
DW_AT_entry_pc DW_FORM_addr
<25>   DW_AT_ranges  : 0x0
DW_AT_ranges   DW_FORM_data4
<29>   DW_AT_stmt_list   : 0x0

Contents of the .debug_ranges section:
Offset   BeginEnd
 004004b4 004004cf
 004004d0 004004da
 

  4004ce:   c3  retq
  4004cf:   90  nop
004004d0 <_ZN1CC1Ev>:
  4004d0:   55  push   %rbp

(a) DW_AT_low_pc and DW_AT_entry_pc are set to 0, this is incorrect.
 - this BZ
 DWARF4 does not define DW_TAG_compile_unit->DW_AT_entry_pc
 DWARF4 2.17 does not IMO define DW_AT_low_pc when DW_AT_ranges is present.

minor ones:
(b) DW_AT_ranges (which is DWARF3+) is used with DWARF version 2.  Consumer
capable of only DWARF2 will most probably fail on such program.
(c) inter-function padding is excluded from DW_AT_ranges, does not it only
needlessly increase the debug info size?
(d) In some cases there the .debug_info ranges are not merged (suboptimal
size).
 0040063c 0040066a
 0040066a 00400690


-- 
   Summary: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/44665] New: typo in comment, incorrect/out-of-date comment

[jay dot krell at cornell dot edu]

in gcc-4.5 and trunk:


gimplify.c:


/* Return true if T is a CALL_EXPR or an expression that can be

-  assignmed to a temporary.  Note that this predicate should only be
+  assigned to a temporary.  Note that this predicate should only be

   used during gimplification.  See the rationale for this in
   gimplify_modify_expr.  */

static bool
is_gimple_reg_rhs_or_call (tree t)


 
-  caller.  The GIMPLE predicates are in tree-gimple.c.
+  caller.  The GIMPLE predicates are in gimple.c.
 


There is no tree-gimple.c file.


I also saw a ChangeLog entry where function foo_bar was
written foo-bar or file foo-bar.c was written foo_bar.c
but I can't find it now.
You know..like..I had mistyped a function that way, grepped
for it, found it only in the ChangeLog. Hard to find from
this information alone..

 - Jay


-- 
   Summary: typo in comment, incorrect/out-of-date comment
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu


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

[Bug tree-optimization/44539] [4.6 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-06-25 12:30 ---
Should be fixed now.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops

[jakub at gcc dot gnu dot org]

--- Comment #23 from jakub at gcc dot gnu dot org  2010-06-25 12:30 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.1 4.4.0 4.5.0 4.6.0 |4.3.1 4.4.0 4.5.0
  Known to work|4.1.2   |4.1.2 4.6.0


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

[Bug middle-end/44665] typo in comment, incorrect/out-of-date comment

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2010-06-25 13:09 ---
Subject: Bug 44665

Author: manu
Date: Fri Jun 25 13:09:28 2010
New Revision: 161380

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161380
Log:
2010-06-25  Manuel López-Ibáñez  

   PR 44665
   * tree-inline.c (gimple_expand_calls_inline): Fix typo in comment.
   * gimplify.c (is_gimple_reg_rhs_or_call): Likewise.
   (gimplify_expr): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/tree-inline.c


-- 


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

[Bug debug/44664] CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-25 13:10 ---
For DW_AT_low_pc, we do this because of (DWARF4, 3.1.1:
"A DW_AT_low_pc attribute may also be specified in combination with
DW_AT_ranges to specify the default base address for use in location lists (see
Section 2.6.2) and range lists (see Section 2.17.3)."

When the base address for use in location lists is 0, we can use absolute
addresses.  This is used when not all code is in .text section.

  /* We need to give .debug_loc and .debug_ranges an appropriate
 "base address".  Use zero so that these addresses become
 absolute.  Historically, we've emitted the unexpected
 DW_AT_entry_pc instead of DW_AT_low_pc for this purpose.
 Emit both to give time for other tools to adapt.  */
  add_AT_addr (comp_unit_die, DW_AT_low_pc, const0_rtx);
  add_AT_addr (comp_unit_die, DW_AT_entry_pc, const0_rtx);

Perhaps for dwarf_version >= 4 or even just dwarf_version >= 3 we could avoid
emitting DW_AT_entry_pc.
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01709.html

So, from (a) IMHO only the point about DW_AT_entry_pc not allowed on CU is
valid.

(b) We emit DW_AT_ranges unless -gdwarf-2 -gstrict-dwarf, and that's IMHO the
right thing to do.  If the prehistoric reader doesn't handle DW_AT_ranges, it
will ignore it, but not emitting ranges by default (remember upstream gcc still
defaults to -gdwarf-2) is a bad idea.

(c) The CU ranges are ranges of sections used.  The padding is added there by
the linker, something the compiler has no control on.

(d) Again, the compiler can't guess that two different sections will be placed
consecutively.  A post-linking (or during linking) DWARF compressor could
optimize this, sure.


-- 


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

[Bug middle-end/44665] typo in comment, incorrect/out-of-date comment

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2010-06-25 13:14 ---
FIXED in trunk.

Such fixes are considered obvious, so feel free to commit patches to fix them.
Fixing changelogs and svn logs for typos falls also into the obvious category.
If you do not have write access, just send a patch to gcc-patches and ask for
someone to commit it.

I am not going to fix it in GCC 4.5, but anyone should feel free to backport my
patch.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-25 13:14:05
   date||


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

[Bug java/43962] gcj fails to compile with LANG=ja_JP.eucJP

[turutani at scphys dot kyoto-u dot ac dot jp]

--- Comment #1 from turutani at scphys dot kyoto-u dot ac dot jp  
2010-06-25 13:54 ---
Created an attachment (id=21004)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21004&action=view)
sample code

This is a test code to generate error.
gcc-4.2.5 20090325 generates no error.
gcc-4.5.1 20100617 generates error with LANG=ja_JP.eucJP, but no error with
LANG=C.
Here are errors:
localetest.java:3: error: Syntax error on token "test", ; expected
String str = "ÿÿtest";

localetest.java:3: error: Syntax error, insert ")" to complete MethodInvocation
if (str.startsWith("ÿÿ"))
   ^^^
localetest.java:3: error: Syntax error, insert ") Statement" to complete
IfStatement
if (str.startsWith("ÿÿ"))
   ^^^
localetest.java:3: error: Syntax error, insert ")" to complete MethodInvocation
System.out.println("start with ÿÿ");
   ^^
localetest.java:3: error: Syntax error, insert ";" to complete Statement
System.out.println("start with ÿÿ");
   ^^
5 problems (5 errors)


-- 


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

[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation

[hjl dot tools at gmail dot com]

--- Comment #18 from hjl dot tools at gmail dot com  2010-06-25 14:09 
---
(In reply to comment #17)
> Subject: Re:  [4.4/4.5/4.6 Regression] Performance
> degradation for simple fibonacci numbers calculation
> 
> This is not correct, when profile is guessed we should look into the
> frequencies.
> I guess profile is wrong after tail recursion elimination or horked by
> recursive inlining,
> I will take a look.
> 

Any updates?


-- 


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

Re: [Bug libstdc++/44663] New: missed GXX_EXPERIMENTAL guards in ?

[Andrew Pinski]

On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net" > wrote:



hi,

the latest llvm/clang++ reports an error during parsing 
included from :


Both of these are c++0x only headers and really are only supported  
when compiling in c++0x mode.





In file included from t00.cpp:1:
In file included from /usr/include/c++/4.5.0/tr1/functional:39:
/usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates  
are only

allowed in C++0x
 template

afaics there's no #ifdef __GXX_EXPERIMENTAL... guards but...

http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.html#manual.intro.status.standard.200x

(...)
In this implementation -std=gnu++0x or -std=c++0x flags must be used
to enable language and library features. The pre-defined symbol
__GXX_EXPERIMENTAL_CXX0X__ is used to check for the presence of
the required flag.
(...)


--
  Summary: missed GXX_EXPERIMENTAL guards in ?
  Product: gcc
  Version: 4.5.1
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: libstdc++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: pluto at agmk dot net
 GCC host triplet: x86_64-gnu-linux


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

[Bug libstdc++/44663] missed GXX_EXPERIMENTAL guards in ?

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2010-06-25 14:18 ---
Subject: Re:   New: missed GXX_EXPERIMENTAL guards in ?



On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net"  wrote:

> hi,
>
> the latest llvm/clang++ reports an error during parsing 
> included from :

Both of these are c++0x only headers and really are only supported  
when compiling in c++0x mode.


>
> In file included from t00.cpp:1:
> In file included from /usr/include/c++/4.5.0/tr1/functional:39:
> /usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates  
> are only
> allowed in C++0x
>  template
>
> afaics there's no #ifdef __GXX_EXPERIMENTAL... guards but...
>
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.html#manual.intro.status.standard.200x
>
> (...)
> In this implementation -std=gnu++0x or -std=c++0x flags must be used
> to enable language and library features. The pre-defined symbol
> __GXX_EXPERIMENTAL_CXX0X__ is used to check for the presence of
> the required flag.
> (...)
>
>
> -- 
>   Summary: missed GXX_EXPERIMENTAL guards in ?
>   Product: gcc
>   Version: 4.5.1
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: libstdc++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: pluto at agmk dot net
>  GCC host triplet: x86_64-gnu-linux
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
>


-- 


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

[Bug libstdc++/44663] missed GXX_EXPERIMENTAL guards in ?

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-06-25 14:23 
---
Wrong Andrew.


-- 


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

[Bug fortran/44666] New: [F2008] Passing NULL pointer or unallocated allocatable to OPTIONAL dummy

[burnus at gcc dot gnu dot org]

"12.5.2.12 Argument presence and restrictions on arguments not present

A dummy argument or an entity that is host associated with a dummy argument is
not present if the dummy argument
[...]
* does not have the ALLOCATABLE or POINTER attribute, and corresponds to an
  actual argument that
  - has the ALLOCATABLE attribute and is not allocated, or
  - has the POINTER attribute and is disassociated."

That probably means:

a) NULL(mold) as actual argument is allowed
b) For scalars, it should just work
c) For arguments with descriptors, one needs to add:
   (actual.data == NULL) ? NULL : actual


-- 
   Summary: [F2008] Passing NULL pointer or unallocated allocatable
to OPTIONAL dummy
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/44667] New: [4.5/4.6 Regression] ICE: verify_stmts failed: non-trivial conversion at assignment with -fprofile-generate

[zsojka at seznam dot cz]

Command line:
$ gfortran -O2 -fprofile-generate
or
$ gfortran -O1 -finline-small-functions -fprofile-generate

Compiler output:
$ gfortran -O1 -finline-small-functions -fprofile-generate
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90: In
function 'ptr':
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90:14:0:
error: non-trivial conversion at assignment
character(kind=1)[2][1:10] *
character(kind=1)[2][1:_s] *
s.0 = s;

/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90:14:0:
internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r161170 - crash
4.5 r158978 - crash (with checking)
4.4 r158133 - OK (with checking)

The testcase is from testsuite, gfortran.dg/char_pointer_assign_5.f90


-- 
   Summary: [4.5/4.6 Regression] ICE: verify_stmts failed: non-
trivial conversion at assignment with -fprofile-generate
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/44667] [4.5/4.6 Regression] ICE: verify_stmts failed: non-trivial conversion at assignment with -fprofile-generate

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-checking
   Target Milestone|--- |4.5.1


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[sfilippone at uniroma2 dot it]

--- Comment #22 from sfilippone at uniroma2 dot it  2010-06-25 15:31 ---
(In reply to comment #21)
Ok, I bit the bullet, and fooled around with the internals to see what was
happening. I did a very naive thing of adding warnings in
resolve.c:resolve_typebound_generic_call, and I think I have found at least one
thing differentiating generic_23 from test_coo above (this is the static
example, not the allocatable one). The "fixed name" thing comes from the
snippet of code
 success:
  /* Make sure that we have the right specific instance for the name.  */
  genname = e->value.compcall.tbp->u.specific->name;

---
[sfili...@donald bug15]$ gfortran -c  test_coo.f03 
Warning: Matched Name: '---' genname 'allocate' 
Warning: Fixed Name: '---' genname 'base_allocate_mnnz' 
-
As you can see, the name is resolved to the specific procedure. The declaration
was 
 type  :: base_sparse_mat
integer, private :: m, n
integer, private :: state, duplicate 
logical, private :: triangle, unitd, upper, sorted
  contains 

procedure, pass(a) :: get_fmt => base_get_fmt
procedure, pass(a) :: set_null => base_set_null
procedure, pass(a) :: allocate_mnnz => base_allocate_mnnz
generic,   public  :: allocate => allocate_mnnz
  end type base_sparse_mat

So the generics resolution is homing in to the procedure name. 
However my copy of the Fortran 2003 handbook says (at pages 95-97):
1. Specifinc bindings: 
PROCEDURE [ [,NON-OVERRIDABLE] [, binding-attribute-list] ::] binding-name [ =>
procedure-name ]
2. Generic bindings: 
GENERIC [ , access-spec ] :: generic-spec => binding-name-list

Looks to me the existing mechanism is NOT doing the correct thing, as it should
home on the BINDING-NAME (allocate_mnnz) and not on the procedure name
(base_allocate_mnnz) 

Hope this will help in fixing this thing; as of now, I have no idea if this is
related to the allocatable case (see my attachment generic_23_1) 

Salvatore 


-- 


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

[Bug target/44326] NONDEBUG_INSN_P should be used in implicit-zee.c

[hjl at gcc dot gnu dot org]

--- Comment #1 from hjl at gcc dot gnu dot org  2010-06-25 15:33 ---
Subject: Bug 44326

Author: hjl
Date: Fri Jun 25 15:33:21 2010
New Revision: 161389

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161389
Log:
Don't search DEBUG_INSNs for removable zero extends.

2010-06-25  H.J. Lu  

PR rtl-optimization/44326
* implicit-zee.c (find_removable_zero_extends): Replace
INSN_P with NONDEBUG_INSN_P.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/implicit-zee.c


-- 


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

[Bug target/44326] NONDEBUG_INSN_P should be used in implicit-zee.c

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-06-25 15:34 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/44592] [4.5/4.6 Regression] wrong code at -O3

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-06-25 15:34 ---
Indeed.  Mine.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-24 21:58:27 |2010-06-25 15:34:24
   date||


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[sfilippone at uniroma2 dot it]

--- Comment #23 from sfilippone at uniroma2 dot it  2010-06-25 15:34 ---
(In reply to comment #22)
> 
generic_23.f03 obviously works becase the binding name DOIT and the procedure
name are one and the same 


-- 


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

[Bug testsuite/43283] ld: Unsatisfied symbol "start" in file c_lto_20091216-1_0.o

[sje at cup dot hp dot com]

--- Comment #8 from sje at cup dot hp dot com  2010-06-25 16:10 ---
Resolved with code change to test case.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug debug/44668] New: class->DW_TAG_typedef is missing DW_AT_accessibility

[jan dot kratochvil at redhat dot com]

echo 'class C { protected: typedef int t; t v; } c;' | g++ -Wall -c -g -x c++ -

 <2><33>: Abbrev Number: 3 (DW_TAG_typedef)
<34>   DW_AT_name: t
<38>   DW_AT_type: <0x4a>   
 <2><3c>: Abbrev Number: 4 (DW_TAG_member)
<3d>   DW_AT_name: v
<41>   DW_AT_type: <0x33>   
<45>   DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst:
0)
<48>   DW_AT_accessibility: 2   (protected)

DIE <0x33> should have DW_AT_accessibility.

FAIL g++ (GCC) 4.6.0 20100625 (experimental)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
SKIP g++ (GCC) 4.4.5 20100625 (prerelease) - C::t is missing there.
FAIL gcc-c++-4.4.4-8.fc14.x86_64

G++ properly respects the access control:
.C:3: error: ‘typedef int C::t’ is protected
.C:11: error: within this context

But GDB cannot display the access control during `ptype C'.
GDB does not and probably should not respect the access control, though.


-- 
   Summary: class->DW_TAG_typedef is missing DW_AT_accessibility
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/44669] New: ccp or similar passes aren't run after cunroll

[jakub at gcc dot gnu dot org]

! { dg-options "-O2 -funroll-loops" }
function foo (b)
  character (len=1) :: b(4)
  logical :: foo
  foo = any (b .ne. (/"1","2","3","4"/))
end

results in horrible code:
movzbl  .LC0(%rip), %edx
movl$1, %eax
cmpb%dl, (%rdi)
jne .L2
movzbl  .LC1(%rip), %ecx
cmpb%cl, 1(%rdi)
jne .L2
movzbl  .LC2(%rip), %esi
cmpb%sil, 2(%rdi)
jne .L2
movzbl  .LC3(%rip), %r8d
cmpb%r8b, 3(%rdi)
setne   %al
movzbl  %al, %eax
.L2:
rep
ret
because nothing optimizes the constant array reads after cunroll.
If I schedule another pass_ccp right after pass_complete_unroll, much better
code is generated:

cmpb$49, (%rdi)
movl$1, %eax
jne .L2
cmpb$50, 1(%rdi)
jne .L2
cmpb$51, 2(%rdi)
jne .L2
xorl%eax, %eax
cmpb$52, 3(%rdi)
setne   %al
.L2:
rep
ret


-- 
   Summary: ccp or similar passes aren't run after cunroll
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug tree-optimization/44669] ccp or similar passes aren't run after cunroll

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug debug/44668] class->DW_TAG_typedef is missing DW_AT_accessibility

[jan dot kratochvil at redhat dot com]

--- Comment #1 from jan dot kratochvil at redhat dot com  2010-06-25 16:31 
---
Dependent GDB Bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=11757


-- 


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

[Bug rtl-optimization/44659] Combiner fails to match QI cmp patterns with upper 8bit register

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-06-25 16:43 ---
Another testcase:

[...@gnu-6 44659]$ cat extract-3.c
typedef struct
{
  unsigned char c1;
  unsigned char c2;
  unsigned char c3;
  unsigned char c4;
} foo_t;

int
foo (foo_t x)
{
   return x.c2 != 0;
}
[...@gnu-6 44659]$ make extract-3.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -S extract-3.c
[...@gnu-6 44659]$ cat extract-3.s
.file   "extract-3.c"
.text
.globl foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl%edi, %eax
movzbl  %ah, %edi
xorl%eax, %eax
testb   %dil, %dil
setne   %al
ret

movzbl  %ah, %edi
testb   %dil, %dil

can be combined into one instruction.


-- 


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

[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 
16:48 ---
Subject: Re:  [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and
--traditional-cpp

It occured to me that this is only failing for me with 32-bit cc1,
i.e. i386-pc-solaris2.11, sparc-sun-solaris2.11, mips-sgi-irix6.5, but
not alpha-dec-osf5.1 (which is 64-bit).

Rainer


-- 


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 
16:49 ---
Subject: Re:  32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

>> --- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-06-22 01:24 
>> ---
>> atan2_1.f90 has failed on other platforms before too.  I think we just need:
>>
>>  ! { dg-options "-ffloat-store" }
>>
>> or maybe this
>>
>>  ! { dg-options "-O0 -ffloat-store" }
>>
>> in the test file.  Can you try that and see if it clears your problem. Add it
>> right after the line that says ! { dg-do run }
>
> The first variant works like a charm: this way, we still iterate over
> several optimization levels, which would be defeated by the second one.

How should we proceed from here?  Should I formally propose the patch
above?

Rainer


-- 


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

[Bug debug/44668] class->DW_TAG_typedef is missing DW_AT_accessibility

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-25 16:53 ---
Created an attachment (id=21005)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21005&action=view)
gcc46-pr44668.patch

Patch to fix this for typedefs.  More work will be needed to handle it for
other DW_TAG_* type dies.

// PR debug/44668
// { dg-do compile }
// { dg-options "-g -dA" }

struct C
{
private:
  typedef int a;
  a b;
  enum g { g1, g2 } h;
  struct D { int i; } i;
protected:
  typedef int c;
  c d;
public:
  typedef int e;
  e f;
} c;


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling

[changpeng dot fang at amd dot com]

--- Comment #4 from changpeng dot fang at amd dot com  2010-06-25 17:08 
---
(In reply to comment #3)
> Created an attachment (id=21001)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001&action=view) [edit]
> Potential fix for compile time regression
> 
> Here is a potential fix. We just limit prefetching to loops with a "low" 
> amount
> of memory references and bail out if the amount of references is too large.
> 

This should be a good fix for now. But the complexities of computing group
reuse
and miss rate are still a concern. I don't think we need to compute the miss
rate "exactly" here. 


-- 


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

[Bug target/44670] New: arm port fails to build with --enable-build-with-cxx

[amylaar at gcc dot gnu dot org]

../../gcc/gcc/config/arm/arm.c: In function ‘insn_code
locate_neon_builtin_icode(int, neon_itype*)’:
../../gcc/gcc/config/arm/arm.c:18244: error: structure ‘key’ with uninitialized
const members


-- 
   Summary: arm port fails to build with --enable-build-with-cxx
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-elf
 BugsThisDependsOn: 44512
OtherBugsDependingO 44433
 nThis:


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

[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()

[kargl at gcc dot gnu dot org]

--- Comment #14 from kargl at gcc dot gnu dot org  2010-06-25 17:14 ---
(In reply to comment #11)

> 
> Well, it is invalid code - based on a valid Fortran code. If you use Delta to
> reduce a test case (cf. 
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
> it simply removes lines of the source code using a constraint. I think
> Sebastian's constraint was that it segfaults. This seemingly happens for the
> unmodified gamess due to a Graphite bug - but also due to a buggy error
> recovery in gfortran.

Well, then Delta is broken for fortran.  Reducing valid fortran that is
causing a compiler issue to some invalid fortran fragment that may or 
(more than likely) may not have anything to do with the original issue
is a waste of time. 


-- 


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

[Bug tree-optimization/44667] [4.5/4.6 Regression] ICE: verify_stmts failed: non-trivial conversion at assignment with -fprofile-generate

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-06-25 17:50 ---
It is caused by revision 150519:

http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-25 17:50:35
   date||


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

[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2010-06-25 18:11 ---
Well, the compiler shouldn't ICE on invalid input.

And, delta is just a simple text tool, it depends on the user how he writes the
test script.  Ideally when reducing a testcase to find an ICE the delta test
script should check just for the ICE that was reported originally, and if the
original source didn't report any errors other than the ICE the script
shouldn't allow any errors in the source either.  I'm usually using something
like:
#!/bin/sh
/usr/src/gcc/obj/gcc/cc1 -quiet -g -O2 -m32 -fPIC $1 2>&1 \
  | awk \
'/output_operand/{seen+=32;next}/error:/{exit 1}END{if (seen!=32)exit 1}'
if ! test $? == 0; then
  exit 1
fi
exit 0

so it doesn't match unrelated ICEs and doesn't match any error: lines (except
for the ICE it is looking for).


-- 


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2010-06-25 18:22 
---
Please go ahead and commit, OK by me.


-- 


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

[Bug debug/44668] class->DW_TAG_typedef is missing DW_AT_accessibility

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-25 18:23 ---
Created an attachment (id=21006)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21006&action=view)
gcc46-pr44668.patch

Updated patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #21005|0   |1
is obsolete||


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at gcc dot gnu dot org]

--- Comment #12 from ro at gcc dot gnu dot org  2010-06-25 18:32 ---
Subject: Bug 8

Author: ro
Date: Fri Jun 25 18:31:33 2010
New Revision: 161392

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161392
Log:
2010-06-25  Jerry DeLisle  

PR fortran/8
* gfortran.dg/atan2_1.f90: Add -ffloat-store.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/atan2_1.f90


-- 


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at gcc dot gnu dot org]

--- Comment #13 from ro at gcc dot gnu dot org  2010-06-25 18:33 ---
Subject: Bug 8

Author: ro
Date: Fri Jun 25 18:33:01 2010
New Revision: 161393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161393
Log:
2010-06-25  Jerry DeLisle  

PR fortran/8
* gfortran.dg/atan2_1.f90: Add -ffloat-store.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/atan2_1.f90


-- 


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

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at gcc dot gnu dot org]

--- Comment #14 from ro at gcc dot gnu dot org  2010-06-25 18:36 ---
Thanks, installed on mainline and 4.5 branch.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail|4.5.1 4.6.0 |
  Known to work||4.5.1 4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.5.1


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

[Bug bootstrap/44512] --enable-build-with-cxx bootstrap fails in revision 160669

[amylaar at gcc dot gnu dot org]

--- Comment #8 from amylaar at gcc dot gnu dot org  2010-06-25 18:39 ---
Subject: Bug 44512

Author: amylaar
Date: Fri Jun 25 18:38:47 2010
New Revision: 161399

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161399
Log:
PR bootstrap/44512
* genenums.c (main): Output include of insn-constants.h
* Makefile.in (insn-enums.o): Depend on insn-constants.h.

Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/genenums.c


-- 


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

[Bug bootstrap/44637] rs6000 port fails to build with --enable-build-with-cxx

[amylaar at gcc dot gnu dot org]

--- Comment #2 from amylaar at gcc dot gnu dot org  2010-06-25 18:41 ---
Subject: Bug 44637

Author: amylaar
Date: Fri Jun 25 18:41:06 2010
New Revision: 161400

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161400
Log:
PR bootstrap/44637
* config/rs6000/rs6000.c (rs6000_xcoff_strip_dollar): Use const char *
variable for const char * strchr result.

Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/config/rs6000/rs6000.c


-- 


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

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

[amylaar at gcc dot gnu dot org]

--- Comment #3 from amylaar at gcc dot gnu dot org  2010-06-25 18:44 ---
Subject: Bug 44566

Author: amylaar
Date: Fri Jun 25 18:44:18 2010
New Revision: 161401

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161401
Log:
PR other/44566
* function.h (target-gtypes.h): Include.
(struct function): New member target_arch.
* Makefile.in (TARGET_NUM): New Makefile variable.
(cs-tm.h): Add TARGET_NUM to DEFINES.
(GTFILES): Add target-gtypes.h.

* function.h (struct incoming_args): Use type cumulative_args_u for
member info.
(INCOMING_ARGS_INFO): Define.
* Makefile.in (target-gtypes.h, s-target-gtypes): New rules.

* function.c (assign_parms): Use INCOMING_ARGS_INFO.

* config/alpha/alpha.c (entire file): Replace crtl->args.info with
INCOMING_ARGS_INFO (crtl->args).
* config/xtensa/xtensa.c: Likewise.
* config/sh/sh.md: Likewise.
* config/sh/sh.c: Likewise.
* config/arc/arc.c: Likewise.
* config/mmix/mmix.c: Likewise.
* config/m68hc11/m68hc11.c: Likewise.
* config/sparc/sparc.c: Likewise.
* config/ia64/ia64.c: Likewise.
* config/avr/avr.c: Likewise.
* config/stormy16/stormy16.c: Likewise.
* config/iq2000/iq2000.c: Likewise.
* config/frv/frv.c: Likewise.
* config/mips/mips.c: Likewise.
* config/spu/spu.c: Likewise.
* config/v850/v850.c: Likewise.
* config/s390/s390.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/arm/arm.c: Likewise.
* config/i386/i386.c: Likewise.

Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch/gcc/config/arc/arc.c
branches/multi-target-20100625-branch/gcc/config/arm/arm.c
branches/multi-target-20100625-branch/gcc/config/avr/avr.c
branches/multi-target-20100625-branch/gcc/config/frv/frv.c
branches/multi-target-20100625-branch/gcc/config/i386/i386.c
branches/multi-target-20100625-branch/gcc/config/ia64/ia64.c
branches/multi-target-20100625-branch/gcc/config/iq2000/iq2000.c
branches/multi-target-20100625-branch/gcc/config/m68hc11/m68hc11.c
branches/multi-target-20100625-branch/gcc/config/mips/mips.c
branches/multi-target-20100625-branch/gcc/config/mmix/mmix.c
branches/multi-target-20100625-branch/gcc/config/rs6000/rs6000.c
branches/multi-target-20100625-branch/gcc/config/s390/s390.c
branches/multi-target-20100625-branch/gcc/config/sh/sh.c
branches/multi-target-20100625-branch/gcc/config/sh/sh.md
branches/multi-target-20100625-branch/gcc/config/sparc/sparc.c
branches/multi-target-20100625-branch/gcc/config/spu/spu.c
branches/multi-target-20100625-branch/gcc/config/stormy16/stormy16.c
branches/multi-target-20100625-branch/gcc/config/v850/v850.c
branches/multi-target-20100625-branch/gcc/config/xtensa/xtensa.c
branches/multi-target-20100625-branch/gcc/function.c
branches/multi-target-20100625-branch/gcc/function.h
branches/multi-target-20100625-branch/gcc/target.h


-- 


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

[Bug middle-end/44671] New: [4.6 Regression] Partial inlining breaks C++

[hjl dot tools at gmail dot com]

On Linux/x86-64, revision 161382:

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

caused make-check failure in the libstdc++-v3 dir, during
the final link for testsuite_shared.so, ld spills:

relocation R_X86_64_PC32 against symbol
`__gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool()' can
not be used when making a shared object; recompile with -fPIC


-- 
   Summary: [4.6 Regression] Partial inlining breaks C++
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

--- Comment #21 from ro at gcc dot gnu dot org  2010-06-25 18:56 ---
Jerry, could you perhaps have a look at this one, too?  This is the last
remaining
fortran testsuite failure on Solaris 11/x86.

Thanks.
  Rainer


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org


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

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

[amylaar at gcc dot gnu dot org]

--- Comment #4 from amylaar at gcc dot gnu dot org  2010-06-25 19:00 ---
Subject: Bug 44566

Author: amylaar
Date: Fri Jun 25 19:00:34 2010
New Revision: 161404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161404
Log:
PR other/44566
* function.h (MACHINE_FUNCTION): Define.
* Makefile.in (target-gtypes.h): Add machine_function_u definition.

* function.h (struct function): Use machine_function_u for member
machine.
* function.c (free_after_compilation): Use MACHINE_FUNCTION.
(allocate_struct_function): Likewise.
* doc/tm.texi: Adjust struct machine_function documentation.

* config/alpha/alpha.c (entire file): Replace cfun->machine with
MACHINE_FUNCTION (*cfun).
* config/xtensa/xtensa.c: Likewise.
* config/pa/pa.c: Likewise.
* config/mmix/mmix.md: Likewise.
* config/mmix/mmix.c: Likewise.
* config/sparc/sparc.c: Likewise.
* config/bfin/bfin.c: Likewise.
* config/moxie/moxie.c: Likewise.
* config/ia64/ia64.md: Likewise.
* config/ia64/ia64.c: Likewise.
* config/mep/mep.c: Likewise.
* config/m32c/m32c.c: Likewise.
* config/cris/cris.c: Likewise.
* config/avr/avr.c: Likewise.
* config/avr/avr.md: Likewise.
* config/iq2000/iq2000.c: Likewise.
* config/frv/frv.c: Likewise.
* config/mips/mips.h: Likewise.
* config/mips/sde.h: Likewise.
* config/mips/mips.c: Likewise.
* config/s390/s390.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/arm/arm.c: Likewise.
* config/arm/arm.md: Likewise.
* config/arm/arm.h: Likewise.
* config/i386/i386.h: Likewise.
* config/i386/i386.c: Likewise.
* config/i386/cygming.h: Likewise.

Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch/gcc/config/arm/arm.c
branches/multi-target-20100625-branch/gcc/config/arm/arm.h
branches/multi-target-20100625-branch/gcc/config/arm/arm.md
branches/multi-target-20100625-branch/gcc/config/avr/avr.c
branches/multi-target-20100625-branch/gcc/config/avr/avr.md
branches/multi-target-20100625-branch/gcc/config/bfin/bfin.c
branches/multi-target-20100625-branch/gcc/config/cris/cris.c
branches/multi-target-20100625-branch/gcc/config/frv/frv.c
branches/multi-target-20100625-branch/gcc/config/i386/cygming.h
branches/multi-target-20100625-branch/gcc/config/i386/i386.c
branches/multi-target-20100625-branch/gcc/config/i386/i386.h
branches/multi-target-20100625-branch/gcc/config/ia64/ia64.c
branches/multi-target-20100625-branch/gcc/config/ia64/ia64.md
branches/multi-target-20100625-branch/gcc/config/iq2000/iq2000.c
branches/multi-target-20100625-branch/gcc/config/m32c/m32c.c
branches/multi-target-20100625-branch/gcc/config/mep/mep.c
branches/multi-target-20100625-branch/gcc/config/mips/mips.c
branches/multi-target-20100625-branch/gcc/config/mips/mips.h
branches/multi-target-20100625-branch/gcc/config/mips/sde.h
branches/multi-target-20100625-branch/gcc/config/mmix/mmix.c
branches/multi-target-20100625-branch/gcc/config/mmix/mmix.md
branches/multi-target-20100625-branch/gcc/config/moxie/moxie.c
branches/multi-target-20100625-branch/gcc/config/pa/pa.c
branches/multi-target-20100625-branch/gcc/config/rs6000/rs6000.c
branches/multi-target-20100625-branch/gcc/config/s390/s390.c
branches/multi-target-20100625-branch/gcc/config/sparc/sparc.c
branches/multi-target-20100625-branch/gcc/config/xtensa/xtensa.c
branches/multi-target-20100625-branch/gcc/doc/tm.texi
branches/multi-target-20100625-branch/gcc/function.c
branches/multi-target-20100625-branch/gcc/function.h


-- 


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

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

[amylaar at gcc dot gnu dot org]

--- Comment #5 from amylaar at gcc dot gnu dot org  2010-06-25 19:13 ---
Subject: Bug 44566

Author: amylaar
Date: Fri Jun 25 19:12:37 2010
New Revision: 161408

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161408
Log:
PR other/44566
* coretypes.h [!USED_FOR_TARGET] (reg_class_t): Define.
* target.h (struct gcc_target): Replace enum reg_class with
reg_class_t in hook argument / return types.
* doc/tm.texi (TARGET_SECONDARY_RELOAD): Likewise.
(TARGET_IRA_COVER_CLASSES, TARGET_MEMORY_MOVE_COST): Likewise.
(TARGET_BRANCH_TARGET_REGISTER_CLASS): Likewise.
* targhooks.h (default_branch_target_register_class): Likewise.
(default_ira_cover_classes, default_secondary_reload): Likewise.
(default_memory_move_cost): Likewise.
* targhooks.c (default_branch_target_register_class): Likewise.
(default_ira_cover_classes, default_secondary_reload): Likewise.
(default_memory_move_cost): Likewise.
* reload.c (push_secondary_reload, secondary_reload_class): Likewise.
* bt-load.c (branch_target_load_optimize): Likewise.
* ira.c (setup_cover_and_important_classes): Likewise.
* ira-costs.c (copy_cost): Likewise.
* reload1.c (emit_input_reload_insns): Likewise.
* config/alpha/alpha.c (alpha_secondary_reload): Likewise.
* config/frv/frv.c (frv_secondary_reload): Likewise.
* config/s390/s390.c (s390_secondary_reload): Likewise.
* config/i386/i386.c (i386_ira_cover_classes): Likewise.
(ix86_secondary_reload, ix86_memory_move_cost): Likewise.
* config/sh/sh-protos.h (sh_secondary_reload): Likewise.
* config/sh/sh.c (sh_target_reg_class, sh_secondary_reload): Likewise.
* config/xtensa/xtensa.c (xtensa_secondary_reload): Likewise.
* config/xtensa/xtensa-protos.h (xtensa_secondary_reload): Likewise.
* config/rs6000/rs6000.c (rs6000_secondary_reload): Likewise.
(rs6000_ira_cover_classes): Likewise.
* config/picochip/picochip.c (picochip_secondary_reload): Likewise.
* config/picochip/picochip-protos.h (picochip_secondary_reload):
Likewise.
* config/pa/pa.c (pa_secondary_reload): Likewise.
* config/mips/mips.c (mips_ira_cover_classes): Likewise.
* config/bfin/bfin.c (bfin_secondary_reload): Likewise.

Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/bt-load.c
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch/gcc/config/bfin/bfin.c
branches/multi-target-20100625-branch/gcc/config/frv/frv.c
branches/multi-target-20100625-branch/gcc/config/i386/i386.c
branches/multi-target-20100625-branch/gcc/config/mips/mips.c
branches/multi-target-20100625-branch/gcc/config/pa/pa.c
branches/multi-target-20100625-branch/gcc/config/picochip/picochip-protos.h
branches/multi-target-20100625-branch/gcc/config/picochip/picochip.c
branches/multi-target-20100625-branch/gcc/config/rs6000/rs6000.c
branches/multi-target-20100625-branch/gcc/config/s390/s390.c
branches/multi-target-20100625-branch/gcc/config/sh/sh-protos.h
branches/multi-target-20100625-branch/gcc/config/sh/sh.c
branches/multi-target-20100625-branch/gcc/config/xtensa/xtensa-protos.h
branches/multi-target-20100625-branch/gcc/config/xtensa/xtensa.c
branches/multi-target-20100625-branch/gcc/coretypes.h
branches/multi-target-20100625-branch/gcc/doc/tm.texi
branches/multi-target-20100625-branch/gcc/ira-costs.c
branches/multi-target-20100625-branch/gcc/ira.c
branches/multi-target-20100625-branch/gcc/reload.c
branches/multi-target-20100625-branch/gcc/reload1.c
branches/multi-target-20100625-branch/gcc/target.h
branches/multi-target-20100625-branch/gcc/targhooks.c
branches/multi-target-20100625-branch/gcc/targhooks.h


-- 


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

[Bug tree-optimization/43567] linear loop transform

[tjvries at xs4all dot nl]

--- Comment #2 from tjvries at xs4all dot nl  2010-06-25 19:16 ---
Created an attachment (id=21007)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21007&action=view)
slightly more minimal testcase

reproduced on trunk revision 161295


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

--- Comment #22 from jvdelisle at gcc dot gnu dot org  2010-06-25 19:24 
---
Rainer,

I will look at the array_constructor_23.f itself and see what the front-end is
doing with it.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 
19:26 ---
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

Great, thanks.


-- 


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

[Bug fortran/44672] New: [F2008] ALLOCATE with SOURCE and no array-spec

[burnus at gcc dot gnu dot org]

Follow up to PR 43388.

Currently,
   ALLOCATE (var(allocate-shape-spec-list), SOURCE=source-expr)
works but
   ALLOCATE (var(allocate-shape-spec-list), SOURCE=array-source-expr)
does not; in the latter case the array shape should be taken from the SOURCE --
this is a new Fortran 2008 feature.

Currently, it is rejected with:

allocate(a, source=c) ! FAILS but is valid F2008
 1
Error: Array specification required in ALLOCATE statement at (1)


Test case:

type t
end type t
type(t) :: a(:), b, c(:)
allocatable :: a,b,c
allocate(b,c(5))
allocate(a(5), source=b) ! OK 
allocate(a, source=c) ! FAILS but is valid F2008
end


>From the standards. Fortran 2003 has:

C628 (R628) An allocate-shape-spec-list shall appear if
and only if the allocate-object is an array.

C632 (R623) The source-expr shall be a scalar or have the same
rank as allocate-object.


While Fortran 2008 has:

C633 (R631) If allocate-object is an array either allocate-shape-spec-list
shall appear or source-expr shall appear and have the same rank
as allocate-object. If allocate-object is scalar,
allocate-shape-spec-list shall not appear.

C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with
source-expr. If SOURCE= appears, source-expr shall be a scalar
or have the same rank as each allocate-object.


-- 
   Summary: [F2008] ALLOCATE with SOURCE and no array-spec
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/43567] linear loop transform

[tjvries at xs4all dot nl]

--- Comment #3 from tjvries at xs4all dot nl  2010-06-25 20:06 ---
Created an attachment (id=21008)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21008&action=view)
partially redoing the fix for bug 20612

The problem is in this piece of code in lambda_loopnest_gcc_loopnest:
...
  /* Create the new iv.  */

  standard_iv_increment_position (temp, &bsi, &insert_after);
  create_iv (newlowerbound,
 build_int_cst (type, LL_STEP (newloop)),
 ivvar, temp, &bsi, insert_after, &ivvar,
 NULL);

  /* Unfortunately, the incremented ivvar that create_iv inserted may not
 dominate the block containing the exit condition.
 So we simply create our own incremented iv to use in the new exit
 test,  and let redundancy elimination sort it out.  */
  inc_stmt = gimple_build_assign_with_ops (PLUS_EXPR, SSA_NAME_VAR (ivvar),
   ivvar,
   build_int_cst (type, LL_STEP
(newloop)));

  ivvarinced = make_ssa_name (SSA_NAME_VAR (ivvar), inc_stmt);
  gimple_assign_set_lhs (inc_stmt, ivvarinced);
  bsi = gsi_for_stmt (exitcond);
  gsi_insert_before (&bsi, inc_stmt, GSI_SAME_STMT);
...

In case the loop header is copied (-ftree-ch), the second increment is in the
same block as the first increment:
...
  lnivtmp.6_13 = lnivtmp.6_20 + 1;
  lnivtmp.6_1 = lnivtmp.6_20 + 1;
  if (lletmp.8_21 >= lnivtmp.6_1)
...
indeed redundancy elimination sorts this out.

However, if the loop header is not copied:
...:
  i_11 = i_1 + 1;
  lnivtmp.2_19 = lnivtmp.2_5 + 1;

:
  # i_1 = PHI <0(2), i_11(5)>
  # lnivtmp.2_5 = PHI <0(2), lnivtmp.2_19(5)>
  lletmp.4_16 = n_4(D) + -1;
  lnivtmp.2_17 = lnivtmp.2_5 + 1;
  if (lletmp.4_16 >= lnivtmp.2_17)
...
the second increment is an extra increment, on top of the first one.

The patches fixes this, I'm not sure how minimal or efficient, but I did a
x86_64-unknown-linux-gnu bootstrap build and ran testsuites (gcc, objc,
gfortran, g++, libgomp, libstdc++, libjava, libmudflap, libffi) for r161295
and r161295+patch, with identical results.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

--- Comment #24 from jvdelisle at gcc dot gnu dot org  2010-06-25 20:20 
---
Created an attachment (id=21009)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21009&action=view)
Modified array_constructor_23.f to allow for some precision error

Rainer,

Try this version of the test case and see what it does.  If this fails, I will
send one instrumented a bit more.


-- 


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

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2010-06-25 20:21 ---
I see this failure on ia64 linux and hp-ux.  The interesting thing is that it
fails when compiled with C++ but not when compiled with C.  Here is a smaller
test case that shows that the imaginary part of c1 is +0 in the good case
(compiled with C) and -0 in the bad case (compiled with C++).  This only shows
up when not doing any optimization (-O0) because with optimization everything
seems to get correctly folded.

#ifdef __cplusplus
extern "C" {
#endif
extern void exit(int);
int printf(const char *format, ...);
#ifdef __cplusplus
}
#endif

int main (void) {

 _Complex float a1, b1, c1;

 a1 = 0.0f + 0.0if;
 b1 = 0.0f - 0.0if;

 c1 = a1 + b1;
 if (__builtin_copysignf (1.0, __imag__ (a1)) != + 1.0) printf("one\n");
 if (__builtin_copysignf (1.0, __imag__ (b1)) != - 1.0) printf("two\n");
 if (__builtin_copysignf (1.0, __imag__ (c1)) != + 1.0) printf("three\n");
 printf("%f\n",__imag__ (c1));
 exit (0);
}


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug tree-optimization/44667] [4.5/4.6 Regression] ICE: verify_stmts failed: non-trivial conversion at assignment with -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-25 20:31 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-25 17:50:35 |2010-06-25 20:31:46
   date||


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 
20:34 ---
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

Jerry,

> Try this version of the test case and see what it does.  If this fails, I will
> send one instrumented a bit more.

this one works without problems, both 32 and 64-bit, at all optimization
levels (tested with

DEJAGNU=site.exp runtest --tool gfortran --srcdir $srcdir
dg.exp=array_constructor_23.f

Rainer


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

--- Comment #26 from jvdelisle at gcc dot gnu dot org  2010-06-25 20:41 
---
I will commit the change


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 
20:43 ---
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

> --- Comment #26 from jvdelisle at gcc dot gnu dot org  2010-06-25 20:41 
> ---
> I will commit the change

Excellent: no remaining fortran testsuite failures :-)

Rainer


-- 


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

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-25 20:51 ---
Can you verify that reverting r160903 fixes the issue and attach differences
in -fdump-rtl-expand-details and assembly (and maybe point me to the
important difference?)


-- 


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

[Bug tree-optimization/44669] ccp or similar passes aren't run after cunroll

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-25 20:56 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-25 20:56:34
   date||
   Target Milestone|4.6.0   |---


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

[Bug debug/44610] VTA produces wrong variable location information

[aoliva at gcc dot gnu dot org]

--- Comment #6 from aoliva at gcc dot gnu dot org  2010-06-25 21:11 ---
Subject: Bug 44610

Author: aoliva
Date: Fri Jun 25 21:11:32 2010
New Revision: 161413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161413
Log:
PR debug/44610
* simplify-rtx.c (delegitimize_mem_from_attrs): Don't use a base
address if the offset is unknown.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c


-- 


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

[Bug debug/44610] VTA produces wrong variable location information

[aoliva at gcc dot gnu dot org]

--- Comment #7 from aoliva at gcc dot gnu dot org  2010-06-25 21:12 ---
Subject: Bug 44610

Author: aoliva
Date: Fri Jun 25 21:11:56 2010
New Revision: 161414

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161414
Log:
PR debug/44610
* simplify-rtx.c (delegitimize_mem_from_attrs): Don't use a base
address if the offset is unknown.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/simplify-rtx.c


-- 


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

[Bug debug/44610] VTA produces wrong variable location information

[aoliva at gcc dot gnu dot org]

--- Comment #8 from aoliva at gcc dot gnu dot org  2010-06-25 21:13 ---
Fixed


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/44673] New: static const variable works in if/else, fails at linking in ternary

[Hodapp87 at gmail dot com]

Reproduced on 4.6.0 and 4.1.2 as well.

Here is the header file:
class TestClass
{
public:
void testFn() const;
private:
static const int VAR1 = 9;
static const int VAR2 = 5;
};

And here is the source file including it:
#include "testclass.h"
void TestClass::testFn() const {
int b = 1;
int c = (b == 0) ? VAR1 : VAR2;
int d;
if (b == 0) d = VAR1;
else d = VAR2;
}
int main(void) { return 0; }

This compiles, but does not link (g++ is called with no options, only the
source). The following error is given:
gcc-test.o: In function `TestClass::testFn() const':
gcc-test.cpp:(.text+0x14): undefined reference to `TestClass::VAR1'
gcc-test.cpp:(.text+0x1b): undefined reference to `TestClass::VAR2'
collect2: ld returned 1 exit status

If I comment out the line "int c = (b == 0) ? VAR1 : VAR2;" in the source, then
the linker errors disappear.

I have been told that VAR1 and VAR2 are declared and initialized, but not
defined, and therefore this code is not valid C++. If it is indeed invalid,
then why does only the ternary statement cause a linking error, but not the
equivalent if/else?


-- 
   Summary: static const variable works in if/else, fails at linking
in ternary
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Hodapp87 at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-25 21:31 ---
You need indeed a definition.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-06-25 21:32 ---
Note if case does not need a diagnostic according to the C++ standard.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

--- Comment #28 from jvdelisle at gcc dot gnu dot org  2010-06-25 21:32 
---
Subject: Bug 38946

Author: jvdelisle
Date: Fri Jun 25 21:32:37 2010
New Revision: 161416

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161416
Log:
2010-06-25  Jerry DeLisle  

PR testsuite/38946
* gfortran.dg/array_constructor_23.f: Update test to allow for small
error in comparing reals.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/array_constructor_23.f


-- 


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

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

[amylaar at gcc dot gnu dot org]

cse.o, dce.o, dse.o, fwprop.o, web.o, implicit-zee.o): Likewise.
(gcse.o, store-motion.o, resource.o, mode-switching.o): Likewise.
(df-core.o, df-problems.o, df-scan.o, df-byte-scan.o): Likewise.
(regstat.o, var-tracking.o, loop-doloop.o, auto-inc-dec.o): Likewise.
(cfg.o, cfghooks.o, cfgexpand.o, cfgrtl.o, cfganal.o): Likewise.
(cfgbuild.o, cfgcleanup.o, cfgloopanal.o, loop-iv.o): Likewise.
(loop-invariant.o, loop-init.o, loop-unswitch.o): Likewise.
(loop-unroll.o, combine.o, reginfo.o, reload.o, reload1.o): Likewise.
(rtlhooks.o, postreload.o, postreload-gcse.o, caller-save.o): Likewise.
(bt-load.o, reorg.o, alias.o, stack-ptr-mod.o, init-regs.o): Likewise.
(ira-build.o, ira-costs.o, ira-conflicts.o, ira-color.o): Likewise.
(ira-emit.o, ira-lives.o, ira.o, regmove.o): Likewise.
(combine-stack-adj.o, ddg.o, modulo-sched.o, haifa-sched.o): Likewise.
(sched-deps.o, sched-rgn.o, sched-ebb.o, sched-vis.o): Likewise.
(sel-sched.o, sel-sched-dump.o, sel-sched-ir.o, final.o): Likewise.
(recog.o, reg-stack.o, predict.o, bb-reorder.o, cfglayout.o): Likewise.
(regcprop.o, regrename.o, ifcvt.o, lower-subreg.o): Likewise.
($(out_object_file)), insn-attrtab.o, insn-automata.o): Likewise.
(insn-emit.o, insn-enums.o, insn-extract.o, insn-modes.o): Likewise.
(insn-opinit.o, insn-output.o, insn-peep.o, insn-preds.o): Likewise.
(insn-recog.o, insn-modes.c, min-insn-modes.c, insn-preds.c): Likewise.
(insn-emit.c, insn-recog.c, insn-extract.c, insn-output.c): Likewise.
(insn-peep.c, insn-attrtab.c, insn-automata.c, insn-enums.c): Likewise.
(insn-enums.c, insn-opinit.c): Likewise.
($(simple_generated_c:insn-%.c=s-%)): Likewise.
($(simple_rtl_generated_c:insn-%.c=s-%)): Likewise.
($(simple_generated_c:insn-%.c=s-%)): Likewise.
(ggc-common.o): Depend on $(TM_H).
(tree-affine.o): Depend on $(TARGET_H).
($(TA)targhooks.o): Depend on tree-pretty-print.h.
($(TA)$(out_object_file)): Add compiler flags -Dtargetm and
-DTARGET_NAME.
($(simple_generated_c)): Add $(TA) prefix.
(GTFILES-RAW): New makefile variable.  Use it to compute...
(GTFILES) so that extra targets don't see *.c files the object files
of which are not in $(OBJS-extra-target).
[EXTRA_TARGET] (GTFILES): Bracket $(out_file) between [target_files]
and [extra_target].
(gtype-ttags.h): Depend on s-gtype.
(build/%.o) [$(EXTRA_TARGET)]: Add -DEXTRA_TARGET to compiler flags.
(build/gengtype.o): Add EXTRA_TARGETS_FILES and EXTRA_TARGET_STRING
to BUILD_CPPFLAGS.
Depend on extra-modes.h instead of $(extra_modes_file).
[!TA] (extra-modes.h, target-types.h): New rules.
[!TA] (EXTRA_OBJS): Include files from extra targets.
* gimple.h (gimple_stmt_iterator_d): New struct tag.
* passes.c (register_dump_files): No longer static.  Declare.
(init_optimization_passes) [!EXTRA_TARGET]: Make EXTRA_TARGETS_CALL
to self.
(init_optimization_passes) [EXTRA_TARGET]: Start new pass list
with pass_expand at &pass_expand.target_variants[TARGET_NUM-1];
call register_dump_files for this pass list.
[!EXTRA_TARGET] (execute_todo): Call df_finish_pass on target
indicated by targetm.
(execute_pass_list): Handle TODO_arch_dispatch.
* reload1.c (emit_input_reload_insns): : Remove enum reg_class from
target hook interface.

* config/spu/spu-protos.h (spu_override_options): Don't declare.
* config/spu/spu.c (spu_override_options): Now static.  Change
signature to fit target hook.
(TARGET_OVERRIDE_OPTIONS): Redefine.
* config/spu/spu.h (OVERRIDE_OPTIONS): Don't define.

* config/sh/sh.h (OVERRIDE_OPTIONS): Delete.
* config/sh/sh.c (sh_override_options): Change type to match hook.
Make manipulation of global flags dependent on main_target.
(TARGET_OVERRIDE_OPTIONS): Redefine.

gcc/po:
* EXCLUDES: Add gentargtype.cc.

Added:
branches/multi-target-20100625-branch/ChangeLog.multi-target
  - copied unchanged from r161408,
branches/multi-target-20100622-branch/ChangeLog.multi-target
branches/multi-target-20100625-branch/gcc/ChangeLog.multi-target
  - copied, changed from r161408,
branches/multi-target-20100622-branch/gcc/ChangeLog.multi-target
branches/multi-target-20100625-branch/gcc/README-multi-target
  - copied unchanged from r161408,
branches/multi-target-20100622-branch/gcc/README-multi-target
branches/multi-target-20100625-branch/gcc/T-extra.in
  - copied unchanged from r161408,
branches/multi-target-20100622-branch/gcc/T-extra.in
branches/multi-target-20100625-branch/gcc/any-lang.c
  - copied unchanged from r161408,
branches/multi-target-

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[Hodapp87 at gmail dot com]

--- Comment #3 from Hodapp87 at gmail dot com  2010-06-25 21:45 ---
(In reply to comment #1)
> You need indeed a definition.
> 

Why does it require a definition in the ternary case, but not in the if/else?


-- 


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-06-25 21:47 ---
In the case of if, the value was "inlined" and in the case of ?:, it is not.  I
had a patch which changed the behavior but lost it when I moved companies.


-- 


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