[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 29 Oct 2015, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
> 
> Markus Trippelsdorf  changed:
> 
>What|Removed |Added
> 
>  CC||ienkovich at gcc dot gnu.org
> 
> --- Comment #9 from Markus Trippelsdorf  ---
> (In reply to Richard Biener from comment #8)
> > Does it only reproduce with a LTO built compiler?  Usually gc-checking with
> > always-collect might help tracking down GC issues (which this looks like
> > one).
> 
> It also happens with a --disable-bootstrap compiler.
>
> Valgrind points to r228599:

Nothing obvious but does removing

  mark_virtual_operands_for_renaming (cfun);

help?  It's the only thing that may end up releasing SSA names
(if only virtuals).

> ==114559== Invalid write of size 8
> ==114559==at 0x10866488: link_imm_use_to_list (ssa-iterators.h:261)
> ==114559==by 0x10866488: link_imm_use (ssa-iterators.h:278)
> ==114559==by 0x10866488: set_ssa_use_from_ptr (ssa-iterators.h:288)
> ==114559==by 0x10866488: add_phi_arg(gphi*, tree_node*, edge_def*, 
> unsigned
> int) (tree-phinodes.c:382)
> ==114559==by 0x109A814F: flush_pending_stmts(edge_def*) (tree-ssa.c:195)
> ==114559==by 0x103B94C3: loop_version(loop*, void*, basic_block_def**,
> unsigned int, unsigned int, unsigned int, bool) (cfgloopmanip.c:1753)
> ==114559==by 0x1090F687: tree_unswitch_loop (tree-ssa-loop-unswitch.c:423)
> ==114559==by 0x1090F687: tree_unswitch_single_loop(loop*, int)
> (tree-ssa-loop-unswitch.c:383)
> ==114559==by 0x1090FF0F: tree_ssa_unswitch_loops()
> (tree-ssa-loop-unswitch.c:106)
> ==114559==by 0x106D856B: execute_one_pass(opt_pass*) (passes.c:2338)
> ==114559==by 0x106D8AB3: execute_pass_list_1(opt_pass*) (passes.c:2391)
> ==114559==by 0x106D8ACB: execute_pass_list_1(opt_pass*) (passes.c:2392)
> ==114559==by 0x106D8ACB: execute_pass_list_1(opt_pass*) (passes.c:2392)
> ==114559==by 0x106D8B53: execute_pass_list(function*, opt_pass*)
> (passes.c:2402)
> ==114559==by 0x103DDECB: cgraph_node::expand() (cgraphunit.c:1976)
> ==114559==by 0x103DFA57: expand_all_functions (cgraphunit.c:2112)
> ==114559==by 0x103DFA57: symbol_table::compile() (cgraphunit.c:2461)
> ==114559==  Address 0x24039848 is not stack'd, malloc'd or (recently) free'd
> ==114559==
> ==114559== Invalid write of size 8
> ==114559==at 0x108665C0: delink_imm_use (ssa-iterators.h:248)
> ==114559==by 0x108665C0: remove_phi_arg_num (tree-phinodes.c:400)
> ==114559==by 0x108665C0: remove_phi_args(edge_def*) (tree-phinodes.c:433)
> ==114559==by 0x107EA977: gimple_execute_on_shrinking_pred(edge_def*)
> (tree-cfg.c:8193)
> ==114559==by 0x103AA707: execute_on_shrinking_pred(edge_def*)
> (cfghooks.c:1207)
> ==114559==by 0x10D2C813: redirect_edge_succ(edge_def*, basic_block_def*)
> (cfg.c:361)
> ==114559==by 0x103A8D8B: redirect_edge_succ_nodup(edge_def*,
> basic_block_def*) (cfghooks.c:444)
> ==114559==by 0x109A8C27: ssa_redirect_edge(edge_def*, basic_block_def*)
> (tree-ssa.c:166)
> ==114559==by 0x107FBEDB: gimple_redirect_edge_and_branch(edge_def*,
> basic_block_def*) (tree-cfg.c:5677)
> ==114559==by 0x103A89F3: redirect_edge_and_branch(edge_def*,
> basic_block_def*) (cfghooks.c:358)
> ==114559==by 0x107F4C57: gimple_split_edge(edge_def*) (tree-cfg.c:2747)
> ==114559==by 0x103A92B7: split_edge(edge_def*) (cfghooks.c:629)
> ==114559==by 0x103B94FB: loop_version(loop*, void*, basic_block_def**,
> unsigned int, unsigned int, unsigned int, bool) (cfgloopmanip.c:1782)
> ==114559==by 0x1090F687: tree_unswitch_loop (tree-ssa-loop-unswitch.c:423)
> ==114559==by 0x1090F687: tree_unswitch_single_loop(loop*, int)
> (tree-ssa-loop-unswitch.c:383)
> ==114559==  Address 0x24039848 is not stack'd, malloc'd or (recently) free'd
> ==114559==
> ==114559== Invalid write of size 8
> ==114559==at 0x10866488: link_imm_use_to_list (ssa-iterators.h:261)
> ==114559==by 0x10866488: link_imm_use (ssa-iterators.h:278)
> ==114559==by 0x10866488: set_ssa_use_from_ptr (ssa-iterators.h:288)
> ==114559==by 0x10866488: add_phi_arg(gphi*, tree_node*, edge_def*, 
> unsigned
> int) (tree-phinodes.c:382)
> ==114559==by 0x107F4D0F: reinstall_phi_args (tree-cfg.c:2698)
> ==114559==by 0x107F4D0F: gimple_split_edge(edge_def*) (tree-cfg.c:2749)
> ==114559==by 0x103B94FB: loop_version(loop*, void*, basic_block_def**,
> unsigned int, unsigned int, unsigned int, bool) (cfgloopmanip.c:1782)
> ==114559==by 0x1090F687: tree_unswitch_loop (tree-ssa-loop-unswitch.c:423)
> ==114559==by 0x1090F687: tree_unswitch_single_loop(loop*, int)
> (tree-ssa-loop-unswitch.c:383)
> ==114559==by 0x1090FF0F: tree_ssa_unswitch_loops()
> 

[Bug fortran/49566] [DWARF/DEBUG] Add coarray shapes (codimensions) to the debug output

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49566

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Any progress?

[Bug fortran/59263] Fortran debug: For MODULEs, set DW_AT_accessibility with DW_ACCESS_private where appopriate

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59263

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-29
 Blocks||24546
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Any progress?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug 24546] [meta-bug] gfortran debugging problems

[Bug c++/68144] New: operator~ in trailing return type leads to spurrious error

[joel.falcou at lri dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68144

Bug ID: 68144
   Summary: operator~ in trailing return type leads to spurrious
error
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel.falcou at lri dot fr
  Target Milestone: ---

THe following code :

#include 

struct bar
{
  template 
  auto operator()(T const& a) const -> decltype(~a) { return ~a; }
};

int main()
{  
  // works
  std::cout << ~1 << std::endl;

  // doesnt work
  bar z;  
  std::cout << z(1) << std::endl;
} 

Fails on g++ 5.2.0 with the following error:

main.cpp: In substitution of 'template decltype (~ a)
bar::operator()(const T&) const [with T = int]':
main.cpp:15:19:   required from here
main.cpp:5:29: error: 'a' was not declared in this scope


Changing -> decltype(~a) to -> decltype(~(a)) fixes this incorrect behavior.

Clang++ currently compiles this code correctly.

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117

--- Comment #8 from Dominique d'Humieres  ---
Related to/duplicate of pr55824? Still fails for
"allocate(vector,source=pack(array,.true.))".

[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55824

--- Comment #6 from Dominique d'Humieres  ---
Related to/duplicate of pr57117? With the patch in comment 5 of pr57117, the
original code in comment 0 compiles but segfault at run time, while the
original test in pr57117 does not (altho there is a problem with
"allocate(y(3,3), source=transpose(x))".

Compiling the test in comment 4 still gives an ICE at r229494 with the patch

pr55824_1.f90:4:0:

 allocate(vector,source=pack(array,.true.))
1
internal compiler error: in wide_int_to_tree, at tree.c:1480

[Bug fortran/49475] [OOP][debugging] Add DWARF info for Fortran's OOP features (extension, member functions)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49475

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-29
 Blocks||24546
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Any progress?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug 24546] [meta-bug] gfortran debugging problems

[Bug middle-end/68142] unsafe association of multiplication

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68142

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 29 14:10:31 2015
New Revision: 229528

URL: https://gcc.gnu.org/viewcvs?rev=229528=gcc=rev
Log:
2015-10-29  Richard Biener  

PR middle-end/68142
* fold-const.c (extract_muldiv_1): Avoid introducing undefined
overflow.

* c-c++-common/ubsan/pr68142.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr68142.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/37134] Debug/Fortran: ENTRY -> no DW_TAG_entry_point generated

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
AFAICT this is still present at r229494.

[Bug target/68124] [6 Regression] Many i386 test failures

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68124

--- Comment #10 from H.J. Lu  ---
(In reply to Richard Henderson from comment #9)
> Created attachment 36611 [details]
> proposed patch
> 
> Ho hum.  Post-reload register adjustments ought to use something
> than gen_lowpart to force a hard register into a new mode.
> 
> So let's be a tad more specific in the checks.

It seems to fix the problem.  Thanks.

[Bug tree-optimization/68145] New: [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5684

[jtaylor.debian at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145

Bug ID: 68145
   Summary: [6 Regression] ICE: in vectorizable_store, at
tree-vect-stmts.c:5684
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com
  Target Milestone: ---

Created attachment 36612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36612=edit
reduced testcase

New ICE in current trunk, rev 229522. 5.x is fine.
Reduced preprocessed testcase attached.

$ g++-6.0 -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/scratch/jtaylor/gcc/local-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /scratch/jtaylor/progs/gcc-trunk/configure --disable-werror
--enable-languages=c,c++,fortran --enable-tls
--prefix=/scratch/jtaylor/gcc/local-trunk --with-gmp=/usr --with-mpfr=/usr
--with-mpc=/usr --with-cloog=/usr --with-ppl=/usr --with-isl=/usr
--disable-bootstrap --enable-checking=release
Thread model: posix
gcc version 6.0.0 20151029 (experimental) (GCC) 

$ g++-6.0  ExprLogicNodeArray.ii -c -ftree-vectorize -O1
ExprLogicNodeArray.ii: In member function ‘B D::getArrayBool(const int&)’:
ExprLogicNodeArray.ii:37:3: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:5684
 B D::getArrayBool(const int &) { lnode_p.getArrayBool() && c; }
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #8)
> Does it only reproduce with a LTO built compiler?  Usually gc-checking with
> always-collect might help tracking down GC issues (which this looks like
> one).

It also happens with a --disable-bootstrap compiler.

Valgrind points to r228599:

==114559== Invalid write of size 8
==114559==at 0x10866488: link_imm_use_to_list (ssa-iterators.h:261)
==114559==by 0x10866488: link_imm_use (ssa-iterators.h:278)
==114559==by 0x10866488: set_ssa_use_from_ptr (ssa-iterators.h:288)
==114559==by 0x10866488: add_phi_arg(gphi*, tree_node*, edge_def*, unsigned
int) (tree-phinodes.c:382)
==114559==by 0x109A814F: flush_pending_stmts(edge_def*) (tree-ssa.c:195)
==114559==by 0x103B94C3: loop_version(loop*, void*, basic_block_def**,
unsigned int, unsigned int, unsigned int, bool) (cfgloopmanip.c:1753)
==114559==by 0x1090F687: tree_unswitch_loop (tree-ssa-loop-unswitch.c:423)
==114559==by 0x1090F687: tree_unswitch_single_loop(loop*, int)
(tree-ssa-loop-unswitch.c:383)
==114559==by 0x1090FF0F: tree_ssa_unswitch_loops()
(tree-ssa-loop-unswitch.c:106)
==114559==by 0x106D856B: execute_one_pass(opt_pass*) (passes.c:2338)
==114559==by 0x106D8AB3: execute_pass_list_1(opt_pass*) (passes.c:2391)
==114559==by 0x106D8ACB: execute_pass_list_1(opt_pass*) (passes.c:2392)
==114559==by 0x106D8ACB: execute_pass_list_1(opt_pass*) (passes.c:2392)
==114559==by 0x106D8B53: execute_pass_list(function*, opt_pass*)
(passes.c:2402)
==114559==by 0x103DDECB: cgraph_node::expand() (cgraphunit.c:1976)
==114559==by 0x103DFA57: expand_all_functions (cgraphunit.c:2112)
==114559==by 0x103DFA57: symbol_table::compile() (cgraphunit.c:2461)
==114559==  Address 0x24039848 is not stack'd, malloc'd or (recently) free'd
==114559==
==114559== Invalid write of size 8
==114559==at 0x108665C0: delink_imm_use (ssa-iterators.h:248)
==114559==by 0x108665C0: remove_phi_arg_num (tree-phinodes.c:400)
==114559==by 0x108665C0: remove_phi_args(edge_def*) (tree-phinodes.c:433)
==114559==by 0x107EA977: gimple_execute_on_shrinking_pred(edge_def*)
(tree-cfg.c:8193)
==114559==by 0x103AA707: execute_on_shrinking_pred(edge_def*)
(cfghooks.c:1207)
==114559==by 0x10D2C813: redirect_edge_succ(edge_def*, basic_block_def*)
(cfg.c:361)
==114559==by 0x103A8D8B: redirect_edge_succ_nodup(edge_def*,
basic_block_def*) (cfghooks.c:444)
==114559==by 0x109A8C27: ssa_redirect_edge(edge_def*, basic_block_def*)
(tree-ssa.c:166)
==114559==by 0x107FBEDB: gimple_redirect_edge_and_branch(edge_def*,
basic_block_def*) (tree-cfg.c:5677)
==114559==by 0x103A89F3: redirect_edge_and_branch(edge_def*,
basic_block_def*) (cfghooks.c:358)
==114559==by 0x107F4C57: gimple_split_edge(edge_def*) (tree-cfg.c:2747)
==114559==by 0x103A92B7: split_edge(edge_def*) (cfghooks.c:629)
==114559==by 0x103B94FB: loop_version(loop*, void*, basic_block_def**,
unsigned int, unsigned int, unsigned int, bool) (cfgloopmanip.c:1782)
==114559==by 0x1090F687: tree_unswitch_loop (tree-ssa-loop-unswitch.c:423)
==114559==by 0x1090F687: tree_unswitch_single_loop(loop*, int)
(tree-ssa-loop-unswitch.c:383)
==114559==  Address 0x24039848 is not stack'd, malloc'd or (recently) free'd
==114559==
==114559== Invalid write of size 8
==114559==at 0x10866488: link_imm_use_to_list (ssa-iterators.h:261)
==114559==by 0x10866488: link_imm_use (ssa-iterators.h:278)
==114559==by 0x10866488: set_ssa_use_from_ptr (ssa-iterators.h:288)
==114559==by 0x10866488: add_phi_arg(gphi*, tree_node*, edge_def*, unsigned
int) (tree-phinodes.c:382)
==114559==by 0x107F4D0F: reinstall_phi_args (tree-cfg.c:2698)
==114559==by 0x107F4D0F: gimple_split_edge(edge_def*) (tree-cfg.c:2749)
==114559==by 0x103B94FB: loop_version(loop*, void*, basic_block_def**,
unsigned int, unsigned int, unsigned int, bool) (cfgloopmanip.c:1782)
==114559==by 0x1090F687: tree_unswitch_loop (tree-ssa-loop-unswitch.c:423)
==114559==by 0x1090F687: tree_unswitch_single_loop(loop*, int)
(tree-ssa-loop-unswitch.c:383)
==114559==by 0x1090FF0F: tree_ssa_unswitch_loops()
(tree-ssa-loop-unswitch.c:106)
==114559==by 0x106D856B: execute_one_pass(opt_pass*) (passes.c:2338)
==114559==by 0x106D8AB3: execute_pass_list_1(opt_pass*) (passes.c:2391)
==114559==by 0x106D8ACB: execute_pass_list_1(opt_pass*) (passes.c:2392)
==114559==by 0x106D8ACB: execute_pass_list_1(opt_pass*) (passes.c:2392)
==114559==by 0x106D8B53: execute_pass_list(function*, opt_pass*)
(passes.c:2402)
==114559==by 0x103DDECB: cgraph_node::expand() (cgraphunit.c:1976)
==114559==by 

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546

--- Comment #9 from Dominique d'Humieres  ---
> Hi FX,
>
> are you planning to submit that patch?  It sounds like a good idea.

This patch seems to have been committed at least since 4.7.

[Bug fortran/54503] debug: Consider using the beginning of the main program as locus for the set_* calls

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54503

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Blocks||24546
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still present at r229494.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug 24546] [meta-bug] gfortran debugging problems

[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993

--- Comment #5 from Dominique d'Humieres  ---
> Changing the gcc_assert to an early return gives ...

Confirmed with the patch

--- ../_clean/gcc/fortran/decl.c2015-10-27 18:14:22.0 +0100
+++ gcc/fortran/decl.c  2015-10-29 12:02:02.0 +0100
@@ -1293,7 +1293,9 @@ gfc_set_constant_character_len (int len,
   int slen;

   gcc_assert (expr->expr_type == EXPR_CONSTANT);
-  gcc_assert (expr->ts.type == BT_CHARACTER);
+  /* gcc_assert (expr->ts.type == BT_CHARACTER); */
+  if (expr->ts.type != BT_CHARACTER)
+return;

   slen = expr->value.character.length;
   if (len != slen)

No regression.

[Bug c++/67845] ICE on invalid use of const qualifier on x86_64-linux-gnu in merge_types, at cp/typeck.c:854

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67845

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #4 from Paolo Carlini  ---
Fixed.

[Bug fortran/59438] DWARF: Fortran mishandles ALLOCATABLE/ASSOCIATED in debug output

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59438

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-29
 Blocks||24546
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Any progress?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug 24546] [meta-bug] gfortran debugging problems

[Bug middle-end/68112] [6 Regression] FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68112

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Sure, but gcc exploits undefinedness of multiply, so rewriting shift to
multiply is not equivalent in the general case :(.

One way forward might be to make definedness of overflow a bit finer-grained
(either on types, i.e. TYPE_OVERFLOW_DEFINED, or maybe as a property of
chrecs?)

[Bug target/68014] ICE when using Flag Output Operands

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68014

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||segher at gcc dot gnu.org
  Component|inline-asm  |target
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
Confirmed the ICE.  It is a target bug: the x86 backend has an assert
here that we're not trying to print text for the flags register, it
should do output_operand_lossage or similar instead.

For other targets (e.g. those with multiple condition registers) it
_is_ useful to be able to refer to %0 here.

For @cc being silently accepted by older compilers (but meaning CX):
that's unfortunate, but you can check __GCC_ASM_FLAG_OUTPUTS__ making
this mostly moot.

[Bug c++/67845] ICE on invalid use of const qualifier on x86_64-linux-gnu in merge_types, at cp/typeck.c:854

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67845

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Oct 29 13:12:45 2015
New Revision: 229523

URL: https://gcc.gnu.org/viewcvs?rev=229523=gcc=rev
Log:
/cp
2015-10-29  Paolo Carlini  

PR c++/67845
* decl.c (grokfndecl): In case of erroneous cv-qualified non-member
functions consistently reset TREE_TYPE (decl) too.

/testsuite
2015-10-29  Paolo Carlini  

PR c++/67845
* g++.dg/other/cv_func4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/other/cv_func4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to rguent...@suse.de from comment #10)
> >
> > Valgrind points to r228599:
> 
> Nothing obvious but does removing
> 
>   mark_virtual_operands_for_renaming (cfun);
> 
> help?  It's the only thing that may end up releasing SSA names
> (if only virtuals).

No, it doesn't help. But reverting r228760 and r228599 fixes the issue.

[Bug fortran/49792] OpenMP workshare: Wrong result with array assignment

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49792

--- Comment #4 from Dominique d'Humieres  ---
> Fixed for 4.6+ so far.

Any reason why this PR is not closed as FIXED?

[Bug target/68149] [6 Regression][ARM] ICE when splitting unaligned DImode load

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68149

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[ARM] ICE when splitting|[6 Regression][ARM] ICE
   |unaligned DImode load   |when splitting unaligned
   ||DImode load

--- Comment #1 from ktkachov at gcc dot gnu.org ---
It's a regression on this particular testcase for GCC 6, but I don't know how
old the latent bug is

[Bug middle-end/65962] Missed vectorization of strided stores

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

--- Comment #16 from Christophe Lyon  ---
Created attachment 36614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36614=edit
Vectorizer dump for little endian

[Bug c++/68148] New: Devirtualization only applies to last of multiple successive calls

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68148

Bug ID: 68148
   Summary: Devirtualization only applies to last of multiple
successive calls
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

Given the code:


struct Interface {
  virtual ~Interface() {}
  virtual void virtualFunc() = 0;
  virtual void virtualFunc2() = 0;
};

struct Concrete : Interface {
  int counter_;
  Concrete() : counter_(0) {}
  void virtualFunc() { counter_++; }
  void virtualFunc2() { counter_++; }
};

void test(Interface ) {
  c.virtualFunc();
  c.virtualFunc2();
}


(Compiled at -O3 -fdevirtualize-speculatively)

Speculative devirtualization is applied to the call to virtualFunc2, but not to
virtualFunc. (See https://goo.gl/Vtx5Fe). If one comments out the call to
virtualFunc2, then the virtualFunc() call *is* speculatively devirtualized
(https://goo.gl/G8f505).

It seems to me that either both should be spec devirtualized, or none. Or
perhaps even more generally, if the vtable pointer is that of "Concrete" then
both calls can be inlined in one and converted to counter+=2 (provided
inspection proved that Concrete's virtualFunc() does not modify the vtable,
which I believe is otherwise a barrier to this kind of optimization).

Am I missing something here, or is this a missed opportunity?

Thanks, Matt

[Bug target/68149] New: [ARM] ICE when splitting unaligned DImode load

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68149

Bug ID: 68149
   Summary: [ARM] ICE when splitting unaligned DImode load
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36617=edit
Testcase

The attached testcase (reduced from a testcase in the testsuite) ICEs with
-O2 -mthumb -mcpu=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=hard
-mfp16-format=ieee -w on arm targets.

As reported at https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03074.html
this started with r229344 but it's a latend bug exposed by that commit.

internal compiler error: in change_address_1, at emit-rtl.c:2132
 }
 ^
0x7a44f4 change_address_1
$SRC/gcc/emit-rtl.c:2132
0x7a74b3 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
$SRC/gcc/emit-rtl.c:2270
0xab79f1 gen_lowpart_general(machine_mode, rtx_def*)
$SRC/gcc/rtlhooks.c:90
0xfd7201 gen_split_47(rtx_insn*, rtx_def**)
$SRC/gcc/config/arm/arm.md:4336
0x12473e3 split_11
$SRC/gcc/config/arm/arm.md:4331
0x12473e3 split_insns(rtx_def*, rtx_insn*)
$SRC/gcc/config/arm/sync.md:361
0x7af36e try_split(rtx_def*, rtx_insn*, int)
$SRC/gcc/emit-rtl.c:3664
0xa53e89 split_insn
$SRC/gcc/recog.c:2874
0xa5cdb9 split_all_insns()
$SRC/gcc/recog.c:2964
0xa5cea7 rest_of_handle_split_after_reload
$SRC/gcc/recog.c:3900
0xa5cea7 execute
$SRC/gcc/recog.c:3929
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This is the unaligned_loaddi splitter in arm.md
The DImode memory load it's trying to split into two is:
(insn 105 403 122 2 (set (reg:DI 0 r0 [198])
(unspec:DI [
(mem/u/c:DI (plus:SI (reg:SI 2 r2)
(const_int -256 [0xff00])) [0  S8 A8])
] UNSPEC_UNALIGNED_LOAD)) besttry.c:408 137 {unaligned_loaddi}

The splitter wants to split it into two SImode loads and -256 is not a valid
offset for such a load.

-256 was accepted as valid during reload because at that point it's seen as a
DImode load and it's accepted there because DImode is a valid
VALID_NEON_DREG_MODE, but it's not a NEON load :(

[Bug fortran/54758] accessing gcc builtins from fortran

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54758

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed, but where do you expect to find "__builtin_prefetch"? in a way
similar to the patch at https://gcc.gnu.org/ml/fortran/2015-10/msg00163.html?

[Bug fortran/68146] New: ice in gimple_stmt_nonnegative_warnv_p with -O2

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68146

Bug ID: 68146
   Summary: ice in gimple_stmt_nonnegative_warnv_p with -O2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 36613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36613=edit
FORTRAN source code

The attached FORTRAN code, when compiled with -c -O2 on x86_64,
does this

internal compiler error: Segmentation fault
0xc4d67f crash_signal
../../src/trunk/gcc/toplev.c:353
0x991e56 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
../../src/trunk/gcc/gimple-fold.c:6266
0x991f21 gimple_phi_nonnegative_warnv_p
../../src/trunk/gcc/gimple-fold.c:6251
0x991f21 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
../../src/trunk/gcc/gimple-fold.c:6276
0x92d9f5 tree_expr_nonnegative_p(tree_node*)
../../src/trunk/gcc/fold-const.c:13164

gimple-fold.c:6266 is

switch (gimple_code (stmt))

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064

Martin Jambor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #2 from Martin Jambor  ---
Mine.

[Bug middle-end/65962] Missed vectorization of strided stores

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

--- Comment #18 from Christophe Lyon  ---
I've attached vectorizer dumps for LE and BE from trunk@229448.

[Bug middle-end/65962] Missed vectorization of strided stores

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

--- Comment #17 from Christophe Lyon  ---
Created attachment 36615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36615=edit
Vectorizer dump for big endian

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). The following code

program test
  implicit none
  character(len=:),allocatable ::name, tmp
  name="./a.out"
  print *, name
  print *, name(3:)
  if (index(name,"/")  /=  0) THEN
tmp=name(3:)
!name=name(3:)
name=tmp
print *,name
  endif
end program

outputs

 ./a.out
 a.out
 a.out

so it seems the assignment "name=name(3:)" is missing a temporary.

[Bug middle-end/68146] [6 Regression] ice in gimple_stmt_nonnegative_warnv_p with -O2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68146

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
  Component|fortran |middle-end
   Target Milestone|--- |6.0
Summary|ice in  |[6 Regression] ice in
   |gimple_stmt_nonnegative_war |gimple_stmt_nonnegative_war
   |nv_p with -O2   |nv_p with -O2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

We enter

12877 return (!name_registered_for_update_p (t)
12878 && depth < PARAM_VALUE (PARAM_MAX_SSA_NAME_QUERY_DEPTH)
12879 && gimple_stmt_nonnegative_warnv_p (SSA_NAME_DEF_STMT
(t),
12880 strict_overflow_p,
depth));

with a released SSA name (TREE_TYPE == NULL)

#0  0x00b38160 in gimple_code (g=0x0)
at /space/rguenther/src/svn/trunk/gcc/gimple.h:1661
#1  0x00b4d90d in gimple_stmt_nonnegative_warnv_p (stmt=, 
strict_overflow_p=0x7fffd5ae, depth=1)
at /space/rguenther/src/svn/trunk/gcc/gimple-fold.c:6260
#2  0x00af455b in tree_single_nonnegative_warnv_p (
t=, strict_overflow_p=0x7fffd5ae, depth=1)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12880
#3  0x00b4d8bf in gimple_phi_nonnegative_warnv_p (stmt=
, strict_overflow_p=0x7fffd5ae, depth=0)
at /space/rguenther/src/svn/trunk/gcc/gimple-fold.c:6245
#4  0x00b4d962 in gimple_stmt_nonnegative_warnv_p (
stmt=, strict_overflow_p=0x7fffd5ae, 
depth=0) at /space/rguenther/src/svn/trunk/gcc/gimple-fold.c:6270
#5  0x00af455b in tree_single_nonnegative_warnv_p (
t=, strict_overflow_p=0x7fffd5ae, depth=0)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12880
#6  0x00af5176 in tree_expr_nonnegative_warnv_p (
t=, strict_overflow_p=0x7fffd5ae, depth=0)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:13146
#7  0x00af51bf in tree_expr_nonnegative_p (t=)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:13162
#8  0x0133c63a in generic_simplify_ABS_EXPR (loc=214740, 
code=ABS_EXPR, type=, 
op0=) at generic-match.c:7996
#9  0x01346b58 in generic_simplify (loc=214740, code=ABS_EXPR, 
type=, 
op0=) at generic-match.c:10127
#10 0x00adc246 in fold_unary_loc (loc=214740, code=ABS_EXPR, 
type=, 
op0=)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:7596
#11 0x00af2ad8 in fold_build1_stat_loc (loc=214740, code=ABS_EXPR, 
type=, 
op0=)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12267
#12 0x00eb1ec6 in gimplify_build1 (gsi=0x7fffdad0, code=ABS_EXPR, 
type=, a=)
at /space/rguenther/src/svn/trunk/gcc/tree-cfg.c:8541
#13 0x00ebd3b4 in expand_complex_div_wide (gsi=0x7fffdad0, 
inner_type=, 
ar=, ai=, 
br=, bi=, code=RDIV_EXPR)
at /space/rguenther/src/svn/trunk/gcc/tree-complex.c:1126

[Bug fortran/68147] New: Potential incorrect code generation for string self-assignment

[mar...@mpa-garching.mpg.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

Bug ID: 68147
   Summary: Potential incorrect code generation for string
self-assignment
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Created attachment 36616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36616=edit
test case

Current gfortran trunk compiles the following testcase into a binary which
outputs "a.o", where I would naively expect "a.out".

martin@marvin ~ $ gfortran -v -ffree-form test.f
Driving: gfortran -v -ffree-form test.f -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/gcc/configure --disable-multilib --enable-gold
--enable-plugins --prefix=/home/martin/ugcc --enable-languages=c++,fortran
--enable-target=all --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 test.f -quiet
-dumpbase test.f -mtune=generic -march=x86-64 -auxbase test -version
-ffree-form -fintrinsic-modules-path
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o /tmp/cco9Tqxj.s
GNU Fortran (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o /tmp/ccwxULsf.o /tmp/cco9Tqxj.s
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24
Reading specs from
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
COMPILER_PATH=/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/collect2 -plugin
/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/liblto_plugin.so
-plugin-opt=/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccCtMKpb.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath
-plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/crtbegin.o
-L/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0
-L/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../.. /tmp/ccwxULsf.o
-lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/crtend.o
/usr/lib/x86_64-linux-gnu/crtn.o
martin@marvin ~ $ ./a.out
 a.o  


If I remove the if-statement, the code works as expected.
Intel ifort 15.0 outputs "a.out".

Am I missing some subtleties regarding self-assignment of allocatable strings?

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064

--- Comment #3 from Martin Jambor  ---
The problem is that IPA-CP does not handle zero-aligned pointers (what
would they be?) but get_pointer_alignment_1 actually returns zero for
one and itself returns true, meaning it claims it knows the alignment
is what it says.  The reason for that is that the pointer is actually
either zero or an integer constant, selected by a ternary operator.

Given the circumstances, the behavior of get_pointer_alignment_1 is
actually OK, I suppose, so wee need to check for it like this:

--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1651,6 +1651,7 @@ ipa_compute_jump_functions_for_edge (struct
ipa_func_body_info *fbi,
  unsigned align;

  if (get_pointer_alignment_1 (arg, , _bitpos)
+ && align != 0
  && align % BITS_PER_UNIT == 0
  && hwi_bitpos % BITS_PER_UNIT == 0)
{

[Bug tree-optimization/67892] [5/6 Regression] Wrong code at -O1 and above

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67892

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug tree-optimization/67892] [5/6 Regression] Wrong code at -O1 and above

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67892

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Thu Oct 29 16:20:06 2015
New Revision: 229538

URL: https://gcc.gnu.org/viewcvs?rev=229538=gcc=rev
Log:
[PATCH][PR tree-optimization/67892] Use FSM threader to handle backedges

PR tree-optimization/67892
* tree-ssa-threadedge.c (simplify_controL_stmt_condition): Fix typo
in comment.
(thread_through_normal_block): If we have seen a backedge, then
do nothing.  No longer call find_jump_threads_backwards here.
(thread_across_edge): Use find_jump_threads_backwards to find
jump threads if the old style threader was not successful.
* tree-ssa-threadbackward.c (get_gimple_control_stmt): Use
gsi_last_nondebug_bb.  Return NULL if the block does not end
with a control statement.
(find_jump_threads_backwards): Setup code moved here from
tree-ssa-threadedge.c::thread_through_normal_block.  Accept
single edge argument instead of name & block.
* tree-ssa-threadbackward.h (find_jump_threads_backwards): Update
prototype.

PR tree-optimization/67892
* gcc.dg/tree-ssa/pr21417: Update expected output.
* gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21417.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2b.c
trunk/gcc/tree-ssa-threadbackward.c
trunk/gcc/tree-ssa-threadbackward.h
trunk/gcc/tree-ssa-threadedge.c

[Bug tree-optimization/68145] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5684

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||ienkovich at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

5743  /* We should have catched mismatched types earlier.  */
5744  gcc_assert (useless_type_conversion_p (vectype,
5745 TREE_TYPE
(vec_oprnd)));
(gdb) p debug_generic_expr (vectype)
vector(16) unsigned char
(gdb) p debug_generic_expr (vec_oprnd->typed.type)
vector(16) 

(vector bool)

[Bug middle-end/65962] Missed vectorization of strided stores

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

--- Comment #19 from Richard Biener  ---
Ok, so the difference is that BE doesn't support unaligned vector loads while
LE does. The targetm.vectorize.support_vector_misalignment hook has

static bool
arm_builtin_support_vector_misalignment (machine_mode mode,
 const_tree type, int misalignment,
 bool is_packed)
{
  if (TARGET_NEON && !BYTES_BIG_ENDIAN && unaligned_access)
{

whatever reason for.  So the testcase would need adjustment with hw_misalign.

[Bug middle-end/68146] [6 Regression] ice in gimple_stmt_nonnegative_warnv_p with -O2

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68146

--- Comment #2 from Dominique d'Humieres  ---
Reduced test case

SUBROUTINE CJYVB(V,Z,VM,CBJ,CDJ,CBY,CDY)
IMPLICIT DOUBLE PRECISION (A,B,G,O-Y)
IMPLICIT COMPLEX*16 (C,Z)
DIMENSION CBJ(0:*),CDJ(0:*),CBY(0:*),CDY(0:*)
N=INT(V)
   CALL GAMMA2(VG,GA)
DO 65 K=1,N
   CBY(K)=CYY
65  CONTINUE
CDJ(0)=V0/Z*CBJ(0)-CBJ(1)
DO 70 K=1,N
70 CDJ(K)=-(K+V0)/Z*CBJ(K)+CBJ(K-1)
END

This appeared between revisions r228586 (2015-10-07, compiles) and r228678
(2015-10-10, ICE).

Backtrace for the reduced test with r229438

Program received signal SIGSEGV, Segmentation fault.
gimple_stmt_nonnegative_warnv_p (stmt=,
strict_overflow_p=, depth=)
at ../../_clean/gcc/gimple-fold.c:6266
warning: Source file is more recent than executable.
6266{
(gdb) bt
#0  gimple_stmt_nonnegative_warnv_p (stmt=,
strict_overflow_p=, depth=)
at ../../_clean/gcc/gimple-fold.c:6266
#1  0x000100679375 in tree_expr_nonnegative_p (t=) at
../../_clean/gcc/fold-const.c:13164
#2  0x0001001d2f18 in generic_simplify (loc=,
code=, type=, op0=)
at generic-match.c:7964
#3  0x000100688e20 in fold_unary_loc (loc=, code=, type=, op0=)
at ../../_clean/gcc/fold-const.c:7598
#4  0x00010068a40a in fold_build1_stat_loc (loc=,
code=, type=, op0=)
at ../../_clean/gcc/fold-const.c:12269
#5  0x00010099cfbf in gimplify_build1 (gsi=, code=, type=, a=)
at ../../_clean/gcc/tree-cfg.c:8495
#6  0x0001009ad1e9 in tree_lower_complex () at
../../_clean/gcc/tree-complex.c:1126
#7  0x0001009ae242 in ?? () at ../../_clean/gcc/tree-complex.c:1736
#8  0x00010089c091 in execute_one_pass (pass=) at
../../_clean/gcc/passes.c:2344
#9  0x00010089c57e in execute_pass_list_1 (pass=) at
../../_clean/gcc/passes.c:2397
#10 0x00010089c590 in execute_pass_list_1 (pass=) at
../../_clean/gcc/passes.c:2398
#11 0x00010089c5d9 in execute_pass_list (fn=,
pass=) at ../../_clean/gcc/passes.c:2408
#12 0x000100564017 in cgraph_node::expand (this=) at
../../_clean/gcc/cgraphunit.c:1983
#13 0x00010056561c in symbol_table::compile (this=) at
../../_clean/gcc/cgraphunit.c:2119
#14 0x000100567574 in symbol_table::finalize_compilation_unit
(this=) at ../../_clean/gcc/cgraphunit.c:2536
#15 0x000100965f3e in compile_file () at ../../_clean/gcc/toplev.c:508
#16 0x000100d536ac in ?? ()
#17 0x000100d55069 in main (argc=3, argv=0x7fff5fbff2d8) at
../../_clean/gcc/main.c:39

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #2 from Dominique d'Humieres  ---
If I use

print *, len(name), "'", name, "'"

I get

5 'a.o  '

> If I remove the if-statement, the code works as expected.

I see that too.

[Bug fortran/68151] ICE on using select case with function of wrong type

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68151

--- Comment #1 from Gerhard Steinmetz  
---
Or depending on used compiler options :

$ cat z3.f90
program p
   real :: z
   integer :: k = 1
   select case (k)
   case (:huge(z))
   end select
end

$ gfortran -fdefault-real-8 z3.f90
f951: internal compiler error: gfc_trans_select(): Bad type for case expr.

---

Analogous with complex :

$ cat z4.f90
program p
   integer :: k = 1
   select case (k)
   case (cmplx(1):)
   end select
end

$ gfortran -fdefault-real-8 z4.f90
f951: internal compiler error: gfc_trans_select(): Bad type for case expr.

[Bug fortran/68152] ICE on declaring array result for function and entry

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152

--- Comment #1 from Gerhard Steinmetz  
---
Detected with one single defect :


$ cat z2.f90
function f(n)
   integer, intent(in) :: n
   real :: f(n)
   real :: e
entry e(n)
end

$ gfortran -g -O0 -Wall -fcheck=all z2.f90
z2.f90:1:0:

 function f(n)
 1
Error: FUNCTION result f can't be an array in FUNCTION f at (1)

---

$ cat z3.f90
function f(n)
   integer, intent(in) :: n
   real :: f
   real :: e(n)
entry e(n)
end

$ gfortran -g -O0 -Wall -fcheck=all z3.f90
z3.f90:4:15:

real :: e(n)
   1
Error: ENTRY result e can't be an array in FUNCTION f at (1)

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #3 from Dominique d'Humieres  ---
> If I use
>
> print *, len(name), "'", name, "'"
>
> I get
>
> 5 'a.o  '

AFAICT the length is always right and the number of characters replaced with a
space is equal to the number of characters skipped at the beginning of 'name':

  name="./a.out.dSYM"
...
name=name(5:)

gives

8 'out.'

[Bug rtl-optimization/68150] New: postreload-gcc ignores partially clobbered registers

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68150

Bug ID: 68150
   Summary: postreload-gcc ignores partially clobbered registers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

postreload-gcse ("gcse2") does not take into account partially clobbered
registers, that is, HARD_REGNO_CALL_PART_CLOBBERED.  This can be observed
e.g. with gcc.c-torture/execute/memcpy-bi.c when compiled for rs6000 with
options "-O3 -m32 -mpowerpc64 -mlra": it CSEs various DImode values over
calls although only the (low) SImode part of the integer registers is
preserved over calls, making the test fail.

[Bug fortran/67885] ICE on using parameter array in block

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67885

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 17:06:58 2015
New Revision: 229540

URL: https://gcc.gnu.org/viewcvs?rev=229540=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/67885
* trans-decl.c (generate_local_decl): Mark PARAMETER entities in
BLOCK construct.

2015-10-26  Steven G. Kargl  

PR fortran/67885
* gfortran.dg/pr67885.f90: New test.

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

[Bug fortran/68151] New: ICE on using select case with function of wrong type

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68151

Bug ID: 68151
   Summary: ICE on using select case with function of wrong type
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

A select case with a function value of wrong type :

$ cat z1.f90
program p
   integer :: k = 1
   select case (k)
   case (:huge(1._8))
   end select
end

$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: gfc_trans_select(): Bad type for case expr.

---

Whereas, detected with real(4) result :

$ cat z2.f90
program p
   integer :: k = 1
   select case (k)
   case (:huge(1._4))
   end select
end

$ gfortran z2.f90
z2.f90:4:10:

case (:huge(1._4))
  1
Error: Expression in CASE statement at (1) must be of type INTEGER

[Bug fortran/68152] New: ICE on declaring array result for function and entry

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152

Bug ID: 68152
   Summary: ICE on declaring array result for function and entry
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Declaring both function result and entry result as array :


$ cat z1.f90
function f(n)
   integer, intent(in) :: n
   real :: f(n)
   real :: e(n)
entry e(n)
end


$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: gfc_compare_array_spec(): Array spec clobbered

[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68153

--- Comment #1 from Gerhard Steinmetz  
---
Detected, but pointing to the line before :

$ cat z3.f90
program p
   integer, parameter :: sh(2) = [2, 2]
   integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], -sh)
   print *, a
end

$ gfortran -g -O0 -Wall -fcheck=all z3.f90
z3.f90:2:34:

integer, parameter :: sh(2) = [2, 2]
  1
Error: 'shape' argument of 'reshape' intrinsic at (1) has negative element (-2)

[Bug fortran/68154] New: ICE on initializing character parameter array (explicit, implied)

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

Bug ID: 68154
   Summary: ICE on initializing character parameter array
(explicit, implied)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Some variants of initializing a character parameter array
(explicit-shape, implied-shape) are not working :


$ cat z1.f90
program p
   character(1), parameter :: x1(2) = 'a'
   character(*), parameter :: x2(2) = x1
   character(*), parameter :: x3(*) = x1
end

$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: Segmentation fault


$ cat z2.f90
program p
   character(*), parameter :: x1(2) = 'a'
   character(*), parameter :: x2(2) = x1
   character(*), parameter :: x3(*) = x1
end

$ gfortran -g -O0 -Wall -fcheck=all z2.f90
f951: internal compiler error: Segmentation fault

[Bug target/68124] [6 Regression] Many i386 test failures

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68124

--- Comment #11 from Richard Henderson  ---
Author: rth
Date: Thu Oct 29 18:36:39 2015
New Revision: 229550

URL: https://gcc.gnu.org/viewcvs?rev=229550=gcc=rev
Log:
Fix target/68124

PR target/68124
PR rtl-opt/67609
* config/i386/i386.c (ix86_cannot_change_mode_class): Tighten
sse check to the exact conditions of PR 67609.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

--- Comment #33 from Richard Henderson  ---
Author: rth
Date: Thu Oct 29 18:36:39 2015
New Revision: 229550

URL: https://gcc.gnu.org/viewcvs?rev=229550=gcc=rev
Log:
Fix target/68124

PR target/68124
PR rtl-opt/67609
* config/i386/i386.c (ix86_cannot_change_mode_class): Tighten
sse check to the exact conditions of PR 67609.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155

--- Comment #2 from Gerhard Steinmetz  
---
Fails (again len_lhs <> len_rhs) :

$ cat z3t.f90
program p
   type t
  character(2) :: z(1) = 'ab' // ['y']
   end type
   type(t) :: z
   print *, z
end

$ gfortran -g -O0 -Wall -fcheck=all z3t.f90
z3t.f90:3:28:

   character(2) :: z(1) = 'ab' // ['y']
1
Warning: CHARACTER expression at (1) is being truncated (3/2)
[-Wcharacter-truncation]
f951: internal compiler error: Segmentation fault

---

Again, works without type :

$ cat z3c.f90
program p
   character(2) :: z(1) = 'ab' // ['y']
   print *, z
end

$ gfortran -g -O0 -Wall -fcheck=all z3c.f90
z3c.f90:2:25:

character(2) :: z(1) = 'ab' // ['y']
 1
Warning: CHARACTER expression at (1) is being truncated (3/2)
[-Wcharacter-truncation]

$ a.out
 ab

---

Eventually one of the recent patches cures this one too.

[Bug c/63336] cilkplus array notation ICE in find_rank

[jtamagnan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336

jtamagnan at gmail dot com changed:

   What|Removed |Added

 CC||jtamagnan at gmail dot com

--- Comment #7 from jtamagnan at gmail dot com ---
I had the same error with the following code:

> class test{
> public:
>   int arr[2][2][2];
> 
>   test()
>   {
> arr[0:2][0:2][0:2] = 1;
>   }
> };
> 
> 
> int main(){
>   test t;
>   return 1;
> }

And compiling with

> gcc cilk_test.cc -std-gnu++11 -fcilkplus

with gcc version: 

> gcc (Debian 5.2.1-21) 5.2.1 20151003

The full output from the compiler was:

> cilk_test.cc: In constructor ‘test::test()’:
> cilk_test.cc:8:3: internal compiler error: in find_rank, at 
> c-family/array-notation-common.c:244
>}
>^
> 0x7567cc find_rank(unsigned int, tree_node*, tree_node*, bool, unsigned long*)
> ../../src/gcc/c-family/array-notation-common.c:244
> 0x6fd22b expand_an_in_modify_expr
> ../../src/gcc/cp/cp-array-notation.c:576
> 0x6fe677 expand_array_notation_exprs(tree_node*)
> ../../src/gcc/cp/cp-array-notation.c:1172
> 0x6fe4f8 expand_array_notation_exprs(tree_node*)
> ../../src/gcc/cp/cp-array-notation.c:1252
> 0x6fe4f8 expand_array_notation_exprs(tree_node*)
> ../../src/gcc/cp/cp-array-notation.c:1252
> 0x6fe4f8 expand_array_notation_exprs(tree_node*)
> ../../src/gcc/cp/cp-array-notation.c:1252
> 0x6fe6c3 expand_array_notation_exprs(tree_node*)
> ../../src/gcc/cp/cp-array-notation.c:1185
> 0x6f97af cp_genericize(tree_node*)
> ../../src/gcc/cp/cp-gimplify.c:1406
> 0x61652a finish_function(int)
> ../../src/gcc/cp/decl.c:14328
> 0x6890e5 cp_parser_function_definition_after_declarator
> ../../src/gcc/cp/parser.c:23528
> 0x690e1c cp_parser_late_parsing_for_member
> ../../src/gcc/cp/parser.c:24205
> 0x6703fd cp_parser_class_specifier_1
> ../../src/gcc/cp/parser.c:20082
> 0x6703fd cp_parser_class_specifier
> ../../src/gcc/cp/parser.c:20108
> 0x6703fd cp_parser_type_specifier
> ../../src/gcc/cp/parser.c:14727
> 0x6851e7 cp_parser_decl_specifier_seq
> ../../src/gcc/cp/parser.c:11958
> 0x68abf1 cp_parser_simple_declaration
> ../../src/gcc/cp/parser.c:11535
> 0x673023 cp_parser_block_declaration
> ../../src/gcc/cp/parser.c:11482
> 0x66d1d9 cp_parser_declaration
> ../../src/gcc/cp/parser.c:11379
> 0x693f4a cp_parser_declaration_seq_opt
> ../../src/gcc/cp/parser.c:11265
> 0x69425f cp_parser_translation_unit
> ../../src/gcc/cp/parser.c:4100
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

[Bug fortran/67805] ICE on array constructor with wrong character specification

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67805

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 19:37:59 2015
New Revision: 229553

URL: https://gcc.gnu.org/viewcvs?rev=229553=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/67805
PR fortran/68108
* array.c (gfc_match_array_constructor): Check for error from type
spec matching.
* decl.c (char_len_param_value): Check for valid of charlen parameter.
Check for REF_ARRAY.  Reap dead code dating to 2008.
match.c (gfc_match_type_spec): Special case the keyword use in REAL.

2015-10-29  Steven G. Kargl  

PR fortran/67805
PR fortran/68108
* gfortran.dg/pr67805.f90: New testcase.
* gfortran.dg/pr67805_2.f90: New test.
* gfortran.dg/array_constructor_26.f03: Update testcase.
* gfortran.dg/array_constructor_27.f03: Ditto.
* gfortran.dg/char_type_len_2.f90: Ditto.
* gfortran.dg/pr67802.f90: Ditto.
* gfortran.dg/used_before_typed_3.f90: Ditto.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67805.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67805_2.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/array.c
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_26.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_27.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/char_type_len_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/large_real_kind_3.F90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67802.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/used_before_typed_3.f90

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 19:37:59 2015
New Revision: 229553

URL: https://gcc.gnu.org/viewcvs?rev=229553=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/67805
PR fortran/68108
* array.c (gfc_match_array_constructor): Check for error from type
spec matching.
* decl.c (char_len_param_value): Check for valid of charlen parameter.
Check for REF_ARRAY.  Reap dead code dating to 2008.
match.c (gfc_match_type_spec): Special case the keyword use in REAL.

2015-10-29  Steven G. Kargl  

PR fortran/67805
PR fortran/68108
* gfortran.dg/pr67805.f90: New testcase.
* gfortran.dg/pr67805_2.f90: New test.
* gfortran.dg/array_constructor_26.f03: Update testcase.
* gfortran.dg/array_constructor_27.f03: Ditto.
* gfortran.dg/char_type_len_2.f90: Ditto.
* gfortran.dg/pr67802.f90: Ditto.
* gfortran.dg/used_before_typed_3.f90: Ditto.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67805.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67805_2.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/array.c
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_26.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_27.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/char_type_len_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/large_real_kind_3.F90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67802.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/used_before_typed_3.f90

[Bug fortran/67885] ICE on using parameter array in block

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67885

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/67885] ICE on using parameter array in block

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67885

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 19:52:56 2015
New Revision: 229554

URL: https://gcc.gnu.org/viewcvs?rev=229554=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/67885
* trans-decl.c (generate_local_decl): Mark PARAMETER entities in
BLOCK construct.

2015-10-29  Steven G. Kargl  

PR fortran/67885
* gfortran.dg/pr67885.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67885.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68154] ICE on initializing character parameter array (explicit, implied)

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

--- Comment #1 from Gerhard Steinmetz  
---
These variants are working well :


$ cat z0.f90
program p
   character(*), parameter :: c0(2) = 'a'
   character(*), parameter :: c1(*) = ['a', 'b']
   character(*), parameter :: c2(*) = [character(2) :: 'a', 'b']
   character(2), parameter :: c3(*) = c1
   character(*), parameter :: c4(3) = 'c'
   character(*), parameter :: c5(*) = c1
   print *, c0
   print *, c1
   print *, c2
   print *, c3
   print *, c4
   print *, c5
end


$ gfortran -g -O0 -Wall -fcheck=all z0.f90
$ a.out
 aa
 ab
 a b
 a b
 ccc
 ab

[Bug target/68124] [6 Regression] Many i386 test failures

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68124

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Richard Henderson  ---
Fixed.

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|6.0 |5.3

--- Comment #9 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/67939] ICE on using data with negative substring range

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67939

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 20:07:13 2015
New Revision: 229555

URL: https://gcc.gnu.org/viewcvs?rev=229555=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/67939
* data.c (create_character_initializer): Deal with zero length string.

2015-10-29  Steven G. Kargl  

PR fortran/67939
* gfortran.dg/pr67939.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67939.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/data.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68153] New: ICE for intrinsic reshape with negative dim in effective shape

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68153

Bug ID: 68153
   Summary: ICE for intrinsic reshape with negative dim in
effective shape
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code with negative dimension(s) in shape sh :

$ cat z1.f90
program p
   integer, parameter :: sh(2) = [2, -2]
   integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], sh)
   print *, a
end

$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in gfc_simplify_reshape, at
fortran/simplify.c:5091

---

$ cat z4.f90
program p
   integer, parameter :: sh(2) = -2
   integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], sh)
   print *, a
end

$ gfortran -g -O0 -Wall -fcheck=all z4.f90
f951: internal compiler error: in gfc_simplify_reshape, at
fortran/simplify.c:5091

[Bug fortran/68155] New: ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155

Bug ID: 68155
   Summary: ICE on initializing character array in type (len_lhs
<> len_rhs)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Embedded in a type :

$ cat z1t.f90
program p
   type t
  character(2) :: z(1) = '' // ['y']
   end type
   type(t) :: z
   print *, z
end

$ gfortran -g -O0 -Wall -fcheck=all z1t.f90
f951: internal compiler error: Segmentation fault

---

Simplified and correct :

$ cat z1c.f90
program p
   character(2) :: z(1) = '' // ['y']
   print *, '>>' // z // '<<'
end

$ gfortran -g -O0 -Wall -fcheck=all z1c.f90
$ a.out
 >>y <<

[Bug fortran/67805] ICE on array constructor with wrong character specification

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67805

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug rtl-optimization/67609] [5 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

Richard Henderson  changed:

   What|Removed |Added

Summary|[5/6 Regression] Generates  |[5 Regression] Generates
   |wrong code for SSE2 |wrong code for SSE2
   |_mm_load_pd |_mm_load_pd

--- Comment #34 from Richard Henderson  ---
Fixed for 6; let's wait a bit and see if there's any more fallout
before backporting to 5.

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155

--- Comment #1 from Gerhard Steinmetz  
---
Works with len_lhs == len_rhs :

$ cat z2t.f90
program p
   type t
  character(2) :: z(1) = 'a' // ['y']
   end type
   type(t) :: z
   print *, z
end

$ gfortran -g -O0 -Wall -fcheck=all z2t.f90
$ a.out
 ay

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117

--- Comment #9 from Paul Thomas  ---
Created attachment 36618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36618=edit
A completely different approach to the fix.

This one does far better and is less invasive. It is not yet regtested but I am
certain that any problems will be trivial.

I will try with other transformational intrinsics than transpose and rehape,
whilst on tonight's flight to London.

Cheers

Paul

[Bug fortran/68054] ICE on using protected attribute in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68054

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 20:32:41 2015
New Revision: 229558

URL: https://gcc.gnu.org/viewcvs?rev=229558=gcc=rev
Log:
2015-10-24  Steven G. Kargl  

PR fortran/68054
* decl.c (match_attr_spec): PROTECTED can only be a module.

2015-10-24  Steven G. Kargl  

PR fortran/68054
* gfortran.dg/pr68054.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68054.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68055

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/68054] ICE on using protected attribute in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68054

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.

[Bug libstdc++/68139] rethrow_if_nested should tolerate overloaded unary operator

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68139

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Your argumentation is a bit flawed because the standard never guarantees that
address values within library code implicitly are required to use
std::addressof - the library specification needs to say that explicitly. But in
this case I agree that the library needs to handle that case. The reason for
this is, because the *specification* of rethrow_if_nested doesn't say anything
about the need to determine address values.

[Bug fortran/67939] ICE on using data with negative substring range

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67939

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for bug report.

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68055

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 20:44:09 2015
New Revision: 229560

URL: https://gcc.gnu.org/viewcvs?rev=229560=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/68055
* decl.c (gfc_match_decl_type_spec): Check for valid kind in old-style
declarations.

2015-10-29  Steven G. Kargl  

PR fortran/68055
* gfortran.dg/pr68055.f90: New case.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68055.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/68156] New: --disable-hosted-libstdcxx doesn't work

[fedor_qd at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68156

Bug ID: 68156
   Summary: --disable-hosted-libstdcxx doesn't work
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fedor_qd at mail dot ru
  Target Milestone: ---

Created attachment 36619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36619=edit
This log file created by configure

When configuring with --disable-hosted-libstdcxx configure script terminates
with "exit 1"

I need to build libsupc++ only, any libc not aviable.
These commands taken used for configuring in MSYS:

export TARGET=arm-none-symbianelf
export PREFIX=/usr/local/$TARGET
export PATH=$PATH:$PREFIX/bin

../../gcc-5.2.0/libstdc++-v3/configure --build=i686-pc-mingw32
--host=arm-none-symbianelf --target=arm-none-symbianelf \
--prefix=$PREFIX --disable-nls --disable-hosted-libstdcxx

config.log attached

[Bug fortran/68151] ICE on using select case with function of wrong type

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68151

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). I see a change of behavior between
revisions r217961 (2014-11-22)

pr68151.f90:1.9:

program p
 1
Internal Error at (1):
gfc_trans_select(): Bad type for case expr.

and r218255 (2014-12-02)

f951: internal compiler error: gfc_trans_select(): Bad type for case expr.

pr68151.f90:3:0:

select case (k)
 ^
internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
...

[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68153

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Note that the error emitted for the code
in comment 1 is quite misleading.

[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||kargl at gcc dot gnu.org
Summary|ICE on initializing |[5/6 Regression] ICE on
   |character parameter array   |initializing character
   |(explicit, implied) |parameter array (explicit,
   ||implied)
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
The tests in comment 0 compile with revisions up to r30 (2015-04-20), but
give an ICE from r222351 (2015-04-23), likely r222342 (pr65429) for trunk (6.0)
and r222343 for 5.1.0.

[Bug tree-optimization/68130] [6 Regression] gfortran.dg/ieee/ieee_2.f90 is miscomputed with '-Os -m32' on x86_64-apple-darwin1* after r228971

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68130

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Dominique d'Humieres  ---
Fixed by revision r229515. Thanks for the quick fix.

[Bug fortran/68152] ICE on declaring array result for function and entry

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). As for pr68151 I see a change of behavior
between
revisions r217961 (2014-11-22)

pr68152.f90:1:

function f(n)
1
Internal Error at (1):
gfc_compare_array_spec(): Array spec clobbered

and r218255 (2014-12-02)

f951: internal compiler error: gfc_compare_array_spec(): Array spec clobbered

f951: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug other/52192] GCC_CHECK_TLS doesn't detect native TLS

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52192

David Edelsohn  changed:

   What|Removed |Added

 Target|*-*-solaris2.[89]   |*-*-solaris2.[89],
   ||powerpc-ibm-aix*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||dje at gcc dot gnu.org
Summary|GCC_CHECK_TLS doesn't   |GCC_CHECK_TLS doesn't
   |detect native TLS on|detect native TLS
   |Solaris 8/9 |
 Ever confirmed|0   |1

--- Comment #3 from David Edelsohn  ---
This problem also occurs on AIX.  What happened to this bug and the patch?

[Bug fortran/68040] [5/6 Regression] Internal compiler error: Error reporting routines re-entered.

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68040

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #2)
> > However, I would argue that this precise warning does not need to use
> > %E and it could simply use %s, which will make it less dependent on trees
> > and fix this bug without further changes in Fortran.
> 
> Where should I do the change?

#13 0x000100ca61f1 in decl_attributes (node=,
attributes=, flags=) at
../../_clean/gcc/attribs.c:446

But you need to figure out how to get the const char* pointing to the attribute
name from the tree passed to %E.

[Bug fortran/68054] ICE on using protected attribute in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68054

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 29 17:23:52 2015
New Revision: 229542

URL: https://gcc.gnu.org/viewcvs?rev=229542=gcc=rev
Log:
2015-10-29  Steven G. Kargl  

PR fortran/68054
* decl.c (match_attr_spec): PROTECTED can only be a module.

2015-10-29  Steven G. Kargl  

PR fortran/68054
* gfortran.dg/pr68054.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68054.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug other/52192] GCC_CHECK_TLS doesn't detect native TLS on Solaris 8/9

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52192

David Edelsohn  changed:

   What|Removed |Added

 Target|*-*-solaris2.[89],  |*-*-solaris2.[89]
   |powerpc-ibm-aix*|
Summary|GCC_CHECK_TLS doesn't   |GCC_CHECK_TLS doesn't
   |detect native TLS   |detect native TLS on
   ||Solaris 8/9

--- Comment #4 from David Edelsohn  ---
I guess never mind because this would require libstdc++ always to be built with
-pthread.

[Bug target/63975] some of the builtin-arith-overflow* fail on aarch64

[mshawcroft at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63975

mshawcroft at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||mshawcroft at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from mshawcroft at gcc dot gnu.org ---
This is already fixed.

[Bug testsuite/63971] Some of gcc.target/aarch64/test_frame_*.c tests fail now

[mshawcroft at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971

mshawcroft at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mshawcroft at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from mshawcroft at gcc dot gnu.org ---
Fixed by Tejas

[Bug target/64456] [AArch64] pr64252.c fail on aarch64_be

[mshawcroft at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64456

mshawcroft at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mshawcroft at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from mshawcroft at gcc dot gnu.org ---
Resolved by Tejas/Richard

[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

--- Comment #3 from Steve Kargl  ---
On Thu, Oct 29, 2015 at 10:56:37PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154
> 
> Dominique d'Humieres  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2015-10-29
>  CC||kargl at gcc dot gnu.org
> Summary|ICE on initializing |[5/6 Regression] ICE on
>|character parameter array   |initializing character
>|(explicit, implied) |parameter array (explicit,
>||implied)
>  Ever confirmed|0   |1
> 
> --- Comment #2 from Dominique d'Humieres  ---
> The tests in comment 0 compile with revisions up to r30 (2015-04-20), but
> give an ICE from r222351 (2015-04-23), likely r222342 (pr65429) for trunk 
> (6.0)
> and r222343 for 5.1.0.
> 

Index: decl.c
===
--- decl.c  (revision 229542)
+++ decl.c  (working copy)
@@ -1461,7 +1461,16 @@ add_init_expr_to_sym (const char *name, 
}
  else if (init->expr_type == EXPR_ARRAY)
{
- clen = mpz_get_si (init->ts.u.cl->length->value.integer);
+ if (init->ts.u.cl)
+   clen = mpz_get_si
(init->ts.u.cl->length->value.integer);
+ else if (init->value.constructor)
+   {
+ gfc_constructor *c;
+ c = gfc_constructor_first (init->value.constructor);  
+ clen = c->expr->value.character.length;
+   }
+ else
+ clen = 1;
  sym->ts.u.cl->length
= gfc_get_int_expr (gfc_default_integer_kind,
NULL, clen);

[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

--- Comment #4 from Dominique d'Humieres  ---
> +   else
> +   clen = 1;

Why clen=1? When is this branch accessed?

[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

--- Comment #5 from Steve Kargl  ---
On Thu, Oct 29, 2015 at 11:59:54PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154
> 
> --- Comment #4 from Dominique d'Humieres  ---
> > + else
> > + clen = 1;
> 
> Why clen=1? When is this branch accessed?
> 

Hedging my bet. ;-)

I'll change this to gcc_unreachable() before I
commit the change.  The if-branch is my fix for
PR 65429, and the else-if-branch restores the
old code.

[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154

--- Comment #6 from Dominique d'Humieres  ---
> I'll change this to gcc_unreachable() before I commit the change.

I agree.

> The if-branch is my fix for PR 65429, and the else-if-branch
> restores the old code.

It is what I understood.

[Bug go/68141] New: go/gofrontend/import-archive.cc: 2 * poor choice of function parameter type ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68141

Bug ID: 68141
   Summary: go/gofrontend/import-archive.cc: 2 * poor choice of
function parameter type ?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dcb314 at hotmail dot com
CC: cmang at google dot com
  Target Milestone: ---

1.

[trunk/gcc/go/gofrontend/import-archive.cc:471]: (performance) Function
parameter 'p' should be passed by reference.

Source code is

  operator==(const Archive_iterator p) const

Maybe better code

  operator==(const Archive_iterator & p) const

2.

[trunk/gcc/go/gofrontend/import-archive.cc:475]: (performance) Function
parameter 'p' should be passed by reference.

Source code is

  operator!=(const Archive_iterator p) const

Duplicate.

[Bug tree-optimization/68060] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68060

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||anton at samba dot org

--- Comment #2 from Markus Trippelsdorf  ---
*** Bug 68140 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68140] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68140

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
Looks like a dup

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

[Bug middle-end/56956] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 29 08:21:50 2015
New Revision: 229517

URL: https://gcc.gnu.org/viewcvs?rev=229517=gcc=rev
Log:
2015-10-29  Richard Biener  

PR middle-end/56956
* fold-const.c (fold_cond_expr_with_comparison): Do not fold
unsigned conditonal negation to ABS_EXPR.

* c-c++-common/ubsan/pr56956.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr56956.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56956] [4.9/5 Regression] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956

Richard Biener  changed:

   What|Removed |Added

  Known to work||3.4.6, 6.0
   Target Milestone|--- |4.9.4
Summary|ftrapv traps on valid   |[4.9/5 Regression] ftrapv
   |abs-like code   |traps on valid abs-like
   ||code
  Known to fail|6.0 |4.0.0, 4.3.3, 4.5.2

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.

[Bug libstdc++/68133] constexpr basic_string_view(const _CharT* __str)

[d.v.a at ngs dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68133

--- Comment #2 from __vic  ---
Too much black magic in the library already...
I think this is defect in specification/design of the class. But it's easier
for you guys to reach the committee than for me

[Bug target/68124] [6 Regression] Many i386 test failures

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68124

--- Comment #9 from Richard Henderson  ---
Created attachment 36611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36611=edit
proposed patch

Ho hum.  Post-reload register adjustments ought to use something
than gen_lowpart to force a hard register into a new mode.

So let's be a tad more specific in the checks.

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117

--- Comment #6 from Markus Trippelsdorf  ---
Hmm, it looks like r229437 may be innocent after all.
This morning I've hit another ICE that goes away if I add --save-temps 
to the command line:

trippels@gcc2-power8 tools % ~/gcc_6/usr/local/bin/g++ -ftemplate-depth-128 -O3
-finline-functions -Wno-inline -Wall -m64 -Winvalid-pch -DBOOST_ALL_NO_LIB=1
-DBOOST_BUILD_PCH_ENABLED -DBOOST_CHRONO_STATIC_LINK=1
-DBOOST_CHRONO_THREAD_DISABLED -DBOOST_HAS_ICU=1 -DBOOST_SYSTEM_NO_DEPRECATED
-DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1
-DBOOST_TIMER_STATIC_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -DNDEBUG
-I"/home/trippels/boost_testing/results/boost/bin.v2/libs/math/test/gcc-6.0.0/release/link-static"
-I".." -I"../libs/math/include_private" -I"../libs/math/test" -c -o
"/home/trippels/boost_testing/results/boost/bin.v2/libs/math/test/test_bessel_y_prime.test/gcc-6.0.0/release/link-static/test_bessel_y_prime.o"
"../libs/math/test/test_bessel_y_prime.cpp" 
In file included from
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/vector:65:0,
 from
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/random.h:34,
 from
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/random:49,
 from
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_algo.h:66,
 from
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/algorithm:62,
 from ../boost/math/tools/config.hpp:17,
 from ../boost/math/tools/promotion.hpp:26,
 from ../boost/math/special_functions/detail/round_fwd.hpp:12,
 from ../boost/math/special_functions/math_fwd.hpp:26,
 from ../libs/math/test/pch_light.hpp:9,
 from ../libs/math/test/test_bessel_y_prime.cpp:6:
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_bvector.h: In
function ‘void std::fill(std::_Bit_iterator, std::_Bit_iterator, const bool&)’:
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_bvector.h:398:3:
internal compiler error: in fold_convert_loc, at fold-const.c:2201
   fill(_Bit_iterator __first, _Bit_iterator __last, const bool& __x)
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
trippels@gcc2-power8 tools % ~/gcc_6/usr/local/bin/g++ --save-temps
-ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m64
-Winvalid-pch -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED
-DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_CHRONO_THREAD_DISABLED -DBOOST_HAS_ICU=1
-DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1
-DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_TIMER_STATIC_LINK=1
-DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -DNDEBUG
-I"/home/trippels/boost_testing/results/boost/bin.v2/libs/math/test/gcc-6.0.0/release/link-static"
-I".." -I"../libs/math/include_private" -I"../libs/math/test" -c -o
"/home/trippels/boost_testing/results/boost/bin.v2/libs/math/test/test_bessel_y_prime.test/gcc-6.0.0/release/link-static/test_bessel_y_prime.o"
"../libs/math/test/test_bessel_y_prime.cpp"
trippels@gcc2-power8 tools %  

Any hints on how to debug this further?
Looks like memory is corrupted somehow.