date:20160621

[Bug tree-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

2016-06-21 Thread jakub at gcc dot gnu.org

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 21 06:59:33 2016
New Revision: 237628

URL: https://gcc.gnu.org/viewcvs?rev=237628&root=gcc&view=rev
Log:
PR tree-optimization/71588
* tree-ssa-strlen.c (valid_builtin_call): New function.
(adjust_last_stmt, handle_builtin_memset, strlen_optimize_stmt): Use
it.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr71558.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug c++/71528] [5/6 Regression] multiple extern reference declarations produce uninitialized access

2016-06-21 Thread jakub at gcc dot gnu.org

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 21 07:02:59 2016
New Revision: 237629

URL: https://gcc.gnu.org/viewcvs?rev=237629&root=gcc&view=rev
Log:
Backported from mainline
2016-06-14  Jakub Jelinek  

PR c++/71528
* decl.c (duplicate_decls): For DECL_INITIALIZED_P non-external
olddecl vars, preserve their TREE_READONLY bit.

* g++.dg/opt/pr71528.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/opt/pr71528.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71604] New: ICE on valid C++11 code with range-based for loop: in pop_binding, at cp/name-lookup.c:376

2016-06-21 Thread su at cs dot ucdavis.edu

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

Bug ID: 71604
   Summary: ICE on valid C++11 code with range-based for loop: in
pop_binding, at cp/name-lookup.c:376
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It also causes 6.1.x to ICE, and is a regression from 5.4.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160620 (experimental) [trunk revision 237606] (GCC) 
$ 
$ g++-5.4 -c -std=c++11 small.cpp
$ 
$ g++-trunk -c -std=c++11 small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:5:5: internal compiler error: in pop_binding, at cp/name-lookup.c:376
 ;
 ^
0x86b26d pop_binding(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/name-lookup.c:376
0x6adf57 poplevel(int, int, int)
../../gcc-source-trunk/gcc/cp/decl.c:756
0x80e0e3 do_poplevel(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:446
0x81156b finish_for_stmt(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:1039
0x7b3d87 cp_parser_iteration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11632
0x7a9a28 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10393
0x7aac6c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10804
0x7aad5f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10758
0x7aaf0f cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20696
0x7aaf0f cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20732
0x7ab9b1 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25415
0x7ac6c5 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25327
0x7ac6c5 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18468
0x7aca19 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12378
0x7acd21 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
0x7b6100 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12143
0x7b4bd4 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12022
0x7b4f08 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4324
0x7b4f08 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37486
0x918e52 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


---


void foo ()
{
  int a[2] = { 1, 2 }; 
  for (struct S { S (int) {} } S : a) 
;
}

[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

2016-06-21 Thread jakub at gcc dot gnu.org

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 21 07:13:52 2016
New Revision: 237632

URL: https://gcc.gnu.org/viewcvs?rev=237632&root=gcc&view=rev
Log:
Backported from mainline
2016-06-20  Jakub Jelinek  

PR middle-end/71581
* tree-ssa-uninit.c (warn_uninit): If EXPR and VAR are NULL,
see if T isn't anonymous SSA_NAME with COMPLEX_EXPR created
for conversion of scalar user var to complex type and use the
underlying SSA_NAME_VAR in that case.  If EXPR is still NULL,
punt.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr71581.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-uninit.c

[Bug tree-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

2016-06-21 Thread jakub at gcc dot gnu.org

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 21 07:15:36 2016
New Revision: 237633

URL: https://gcc.gnu.org/viewcvs?rev=237633&root=gcc&view=rev
Log:
PR tree-optimization/71588
* tree-ssa-strlen.c (valid_builtin_call): New function.
(adjust_last_stmt, handle_builtin_memset, strlen_optimize_stmt): Use
it.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr71558.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-strlen.c

[Bug c/71567] Incorrect loop optimization

2016-06-21 Thread tyoma.ariv at gmail dot com

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

--- Comment #4 from Artem  ---
Thank you very much.
This help

[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.

[Bug middle-end/71581] [5 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|[5/6/7 Regression] ICE on   |[5 Regression] ICE on valid
   |valid code on   |code on x86_64-linux-gnu
   |x86_64-linux-gnu with   |with -Wuninitialized
   |-Wuninitialized |(Segmentation fault)
   |(Segmentation fault)|

--- Comment #6 from Jakub Jelinek  ---
Fixed for 6.2+ now.

[Bug tree-optimization/71588] [4.9/5 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression] ICE  |[4.9/5 Regression] ICE on
   |on valid code at -O2 and|valid code at -O2 and -O3
   |-O3 on x86_64-linux-gnu: in |on x86_64-linux-gnu: in
   |execute_todo, at|execute_todo, at
   |passes.c:2009   |passes.c:2009

--- Comment #6 from Jakub Jelinek  ---
Fixed for 6.2+ now.

[Bug c++/71528] [5 Regression] multiple extern reference declarations produce uninitialized access

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 Regression] multiple   |[5 Regression] multiple
   |extern reference|extern reference
   |declarations produce|declarations produce
   |uninitialized access|uninitialized access

--- Comment #7 from Jakub Jelinek  ---
Fixed for 6.2+ too.

[Bug c++/71604] [6/7 Regression] ICE on valid C++11 code with range-based for loop: in pop_binding, at cp/name-lookup.c:376

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||jakub at gcc dot gnu.org,
   ||ville at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE on valid C++11 code |[6/7 Regression] ICE on
   |with range-based for loop:  |valid C++11 code with
   |in pop_binding, at  |range-based for loop: in
   |cp/name-lookup.c:376|pop_binding, at
   ||cp/name-lookup.c:376
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r228354.

[Bug c++/71605] New: ICE on invalid C++ code (incorrect member access): in pop_binding, at cp/name-lookup.c:368

2016-06-21 Thread su at cs dot ucdavis.edu

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

Bug ID: 71605
   Summary: ICE on invalid C++ code (incorrect member access): in
pop_binding, at cp/name-lookup.c:368
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++ code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It also affects 4.8.x and later, and is a regression from 4.7.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160620 (experimental) [trunk revision 237606] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:11:4: error: ‘operator I’ is not a member of ‘B’
   &B::operator struct I; // should be: &B::operator struct A;
^
small.cpp:11:24: internal compiler error: in pop_binding, at
cp/name-lookup.c:368
   &B::operator struct I; // should be: &B::operator struct A;
^
0x86b23a pop_binding(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/name-lookup.c:368
0x6adf57 poplevel(int, int, int)
../../gcc-source-trunk/gcc/cp/decl.c:756
0x80e0e3 do_poplevel(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:446
0x812769 finish_compound_stmt(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:1408
0x7aad67 cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10760
0x7aaf0f cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20696
0x7aaf0f cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20732
0x7ab9b1 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25415
0x7ac6c5 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25327
0x7ac6c5 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18468
0x7aca19 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12378
0x7acd21 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
0x7b6100 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12143
0x7b4bd4 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12022
0x7b4f08 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4324
0x7b4f08 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37486
0x918e52 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


struct A {};

struct B
{
  int I; 
  operator struct A () {  return A ();  };
};

void foo ()
{
  &B::operator struct I; // should be: &B::operator struct A;
}

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

2016-06-21 Thread malekpatryk+gcc at gmail dot com

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

Patryk  changed:

   What|Removed |Added

 CC||malekpatryk+gcc at gmail dot 
com

--- Comment #1 from Patryk  ---
Related issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68071.

I can confirm this is also a problem in 6.1.0 and 5.2.1. The workaround for me
for this issue is to name the parameter pack that ends up being empty:

#include 

int main()
{
  auto f = [](auto&& arg1, auto&& arg2, auto&& ...x)// this works
  //auto f = [](auto&& arg1, auto&& arg2, auto&& ...x)// this gives the below
error
  {
std::cout << arg1 << arg2;
  };

  f("a", "b");
}

error on commented line on 5.2.1

main.cpp: In function ‘int main()’:
main.cpp:10:13: error: no match for call to ‘(main()::) (const char [2], const char [2])’
   f("a", "b");
 ^
main.cpp:5:51: note: candidate: template main()operator decltype
(((main()::)0u).operator()(arg1,
arg2, )) (*)(auto:1&&, auto:2&&, auto:3&&, ...)() const 
   auto f = [](auto&& arg1, auto&& arg2, auto&& ...)
   ^
main.cpp:5:51: note:   template argument deduction/substitution failed:
main.cpp:10:13: note:   candidate expects 1 argument, 2 provided
   f("a", "b");
 ^
main.cpp:5:51: note: candidate: template main()::
   auto f = [](auto&& arg1, auto&& arg2, auto&& ...)
   ^
main.cpp:5:51: note:   template argument deduction/substitution failed:
main.cpp:10:13: note:   candidate expects 3 arguments, 2 provided
   f("a", "b");
 ^

[Bug c++/71605] ICE on invalid C++ code (incorrect member access): in pop_binding, at cp/name-lookup.c:368

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Doesn't seem to be a regression, even r104500 ICEs similarly, e.g. 4.4 or 4.6
also end up in release mode with
pr71605.C: In function ‘void foo()’:
pr71605.C:11: error: ‘operator I’ is not a member of ‘B’
pr71605.C:11: confused by earlier errors, bailing out

[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810

2016-06-21 Thread vries at gcc dot gnu.org

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

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 38737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38737&action=edit
tentative patch with log entry and test-case

Currently testing on x86_64.

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #11 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:10:46 2016
New Revision: 237635

URL: https://gcc.gnu.org/viewcvs?rev=237635&root=gcc&view=rev
Log:
PR target/71103
* config/avr/avr.md (movqi): Only handle loading subreg:qi of
constant addresses if can_create_pseudo_p.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md

[Bug c/71606] New: ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

2016-06-21 Thread chengniansun at gmail dot com

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

Bug ID: 71606
   Summary: ICE on -O2 and above on x86_64-linux-gnu (internal
compiler error: in get_expr_operands, at
tree-ssa-operands.c:882)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

This is a regression. gcc-4.8 also crashes. 

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160621 (experimental) [trunk revision 237628] (GCC) 
$: 
$: gcc-trunk -O2 small.c
unhandled expression in get_expr_operands():
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7fe5fd7ae5e8
precision 64
pointer_to_this >
DC
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7fe5fd7aef18>
side-effects
arg 0 
visiteddef_stmt a.0_1 = a;

version 1>>

small.c: In function ‘main’:
small.c:5:3: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:882
   fn1 (a);
   ^~~
0xd40154 get_expr_operands
../../gcc-source-trunk/gcc/tree-ssa-operands.c:882
0xd3f81f get_expr_operands
../../gcc-source-trunk/gcc/tree-ssa-operands.c:769
0xd40939 parse_ssa_operands
../../gcc-source-trunk/gcc/tree-ssa-operands.c:932
0xd422ca build_ssa_operands
../../gcc-source-trunk/gcc/tree-ssa-operands.c:947
0xd422ca update_stmt_operands(function*, gimple*)
../../gcc-source-trunk/gcc/tree-ssa-operands.c:1081
0x926466 update_stmt_if_modified
../../gcc-source-trunk/gcc/gimple-ssa.h:185
0x926466 update_modified_stmt
../../gcc-source-trunk/gcc/gimple-iterator.c:44
0x926466 gsi_insert_after(gimple_stmt_iterator*, gimple*, gsi_iterator_update)
../../gcc-source-trunk/gcc/gimple-iterator.c:545
0xc2d157 insert_init_stmt
../../gcc-source-trunk/gcc/tree-inline.c:3054
0xc3a788 setup_one_parameter
../../gcc-source-trunk/gcc/tree-inline.c:3221
0xc3b965 initialize_inlined_parameters
../../gcc-source-trunk/gcc/tree-inline.c:3248
0xc3b965 expand_call_inline
../../gcc-source-trunk/gcc/tree-inline.c:4590
0xc3d644 gimple_expand_calls_inline
../../gcc-source-trunk/gcc/tree-inline.c:4849
0xc3d644 optimize_inline_calls(tree_node*)
../../gcc-source-trunk/gcc/tree-inline.c:4989
0x12c1132 early_inliner(function*)
../../gcc-source-trunk/gcc/ipa-inline.c:2725
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: gcc-trunk small.c
$: 
$: cat small.c
_Complex a;
void fn1 ();

int main () {
  fn1 (a);
  return 0;
}

void fn1 (__complex__ long double p1) {
  __imag__ p1 = 6.0L;
}
$:

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #12 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:15:25 2016
New Revision: 237636

URL: https://gcc.gnu.org/viewcvs?rev=237636&root=gcc&view=rev
Log:
PR target/71103
* config/avr/avr.md (movqi): Only handle loading subreg:qi of
constant addresses if can_create_pseudo_p.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/avr/avr.md

[Bug c/71606] [4.9/5/6/7 Regression] ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

2016-06-21 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on -O2 and above on |[4.9/5/6/7 Regression] ICE
   |x86_64-linux-gnu (internal  |on -O2 and above on
   |compiler error: in  |x86_64-linux-gnu (internal
   |get_expr_operands, at   |compiler error: in
   |tree-ssa-operands.c:882)|get_expr_operands, at
   ||tree-ssa-operands.c:882)
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
ICEs since GCC 4.7.

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #13 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:18:26 2016
New Revision: 237637

URL: https://gcc.gnu.org/viewcvs?rev=237637&root=gcc&view=rev
Log:
PR target/71103
* config/avr/avr.md (movqi): Only handle loading subreg:qi of
constant addresses if can_create_pseudo_p.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/avr/avr.md

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #14 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:23:08 2016
New Revision: 237638

URL: https://gcc.gnu.org/viewcvs?rev=237638&root=gcc&view=rev
Log:
PR target/71103
* config/avr/avr.md (movqi): Only handle loading subreg:qi of
constant addresses if can_create_pseudo_p.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/avr.md

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #7 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:36:13 2016
New Revision: 237639

URL: https://gcc.gnu.org/viewcvs?rev=237639&root=gcc&view=rev
Log:
PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/gen-avr-mmcu-specs.c

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #8 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:39:59 2016
New Revision: 237640

URL: https://gcc.gnu.org/viewcvs?rev=237640&root=gcc&view=rev
Log:
Backport from 2016-06-21 trunk r237639.
PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/gen-avr-mmcu-specs.c

[Bug target/71607] New: [ARM] ice due to forbidden enabled attribute dependency on instruction operands

2016-06-21 Thread mickael.guene at st dot com

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

Bug ID: 71607
   Summary: [ARM] ice due to forbidden enabled attribute
dependency on instruction operands
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mickael.guene at st dot com
  Target Milestone: ---

Created attachment 38738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38738&action=edit
reduce test case that ice

There is a rule in the 'gcc internals' document that states that 'enabled'
attribute must not depend on the current insn operands.

 But unfortunately such a dependency exists due to 'use_literal_pool' attribute
dependency on operands[1] and 'use_literal_pool' usage in 'enabled'
attribute definition (see arm.md).

 This leads to ice on check_bool_attrs() assertion in recog.c that exactly 
checks that 'enabled', 'preferred_for_size' or 'preferred_for_speed'
are static properties of the subtarget (as stated in gcc internals document
and in check_bool_attrs() comment).

 Find attached a test case that triggers this ice.
>> arm-none-eabi-gcc -c simple.c -mslow-flash-data -O0 -mfloat-abi=hard 
>> -march=armv7-m -mthumb -mfpu=vfpv3
will trigger an ice whereas
>> arm-none-eabi-gcc -c simple.c -mno-slow-flash-data -O0 -mfloat-abi=hard 
>> -march=armv7-m -mthumb -mfpu=vfpv3
will not.

Mickael

[Bug target/71607] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

2016-06-21 Thread mickael.guene at st dot com

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

--- Comment #1 from Mickael Guene  ---
Created attachment 38739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38739&action=edit
ice backtrace

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #9 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 10:43:12 2016
New Revision: 237641

URL: https://gcc.gnu.org/viewcvs?rev=237641&root=gcc&view=rev
Log:
Backport from 2016-06-21 trunk r237639.
PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c

[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

2016-06-21 Thread ktkachov at gcc dot gnu.org

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-06-21
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[ARM] ice due to forbidden  |[5/6/7 Regression] [ARM]
   |enabled attribute   |ice due to forbidden
   |dependency on instruction   |enabled attribute
   |operands|dependency on instruction
   ||operands
   Target Milestone|--- |5.5
  Known to fail||5.4.1, 6.1.1, 7.0

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirned, doesn't ICE on 4.9

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

2016-06-21 Thread gjl at gcc dot gnu.org

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

--- Comment #10 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Jun 21 11:00:54 2016
New Revision: 237643

URL: https://gcc.gnu.org/viewcvs?rev=237643&root=gcc&view=rev
Log:
Backport from 2016-06-21 trunk r237639.
PR target/30417
* config/avr/driver-avr.c (avr_device_to_data_start):
Wrap -Tdata into %{!Tdata:...}.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/avr/driver-avr.c

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

2016-06-21 Thread gjl at gcc dot gnu.org

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |RESOLVED
   Host|x86_64-linux-gnu|
 Resolution|--- |FIXED
   Target Milestone|--- |6.2
  Build|x86_64-linux-gnu|
   Severity|minor   |enhancement

--- Comment #11 from Georg-Johann Lay  ---
Fixed in 4.9.4, 5.5 and 6.2+.

[Bug tree-optimization/71144] [6/7 Regression] isl_aff.c:1001: position out of bounds

2016-06-21 Thread vogt at linux dot vnet.ibm.com

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #1 from Dominik Vogt  ---
I get (pprobably) the same ICE on s390x with today's devel branch in
pr68279.f90.  Reduced test case (which intentionally has some out of bound
array accesses):

MODULE foo 
  CONTAINS 
  SUBROUTINE bar(o) 
INTEGER, DIMENSION(2, 1) :: a 
INTEGER, DIMENSION(1) :: b 
INTEGER, DIMENSION(1, 1) :: o 
INTEGER :: d 
 DO i=1,2 
b(1:2) = b(1:2) 
o(1:1, 1:d) = a(1:1, 1:d) 
a(1:2, 2) = b(1:2) 
d = d + 1 
 END DO 
  END SUBROUTINE bar 
END MODULE 

==>

.../gcc/testsuite/gfortran2/../../gfortran -B.../gcc/testsuite/gfortran2/../../
-B.../s390x-ibm-linux-gnu/32/libgfortran/ x.f90 -floop-nest-optimize -O1 -S
-m64
x.f90:9:10:

 b(1:2) = b(1:2)
  1
Warning: Upper array reference at (1) is out of bounds (2 > 1) in dimension 1
x.f90:9:19:

 b(1:2) = b(1:2)
   1
Warning: Upper array reference at (1) is out of bounds (2 > 1) in dimension 1
x.f90:11:15:

 a(1:2, 2) = b(1:2)
   1
Warning: Array reference at (1) is out of bounds (2 > 1) in dimension 2
x.f90:11:22:

 a(1:2, 2) = b(1:2)
  1
Warning: Upper array reference at (1) is out of bounds (2 > 1) in dimension 1
isl_aff.c:944: position out of bounds
x.f90:3:0:

   SUBROUTINE bar(o)

internal compiler error: Aborted
0x806bd397 crash_signal
/home/vogt/src/t/gcc/toplev.c:335
0x80b3b683 extract_affine_chrec
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:239
0x80b3b683 extract_affine
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:381
0x80b3b8b7 extract_affine
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:421
0x80b3c52d add_condition_to_pbb
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:458
0x80b3c52d add_conditions_to_domain
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:525
0x80b3c52d build_iteration_domains
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:1017
0x80b3c2dd build_iteration_domains
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:1040
0x80b3c95f build_poly_scop(scop*)
/home/vogt/src/t/gcc/graphite-sese-to-poly.c:1364
0x80b296c9 graphite_transform_loops()
/home/vogt/src/t/gcc/graphite.c:319
0x80b29c4f graphite_transforms
/home/vogt/src/t/gcc/graphite.c:356
0x80b29c4f execute
/home/vogt/src/t/gcc/graphite.c:433

[Bug tree-optimization/71608] New: Wrong constant folding

2016-06-21 Thread ishiura-compiler at ml dot kwansei.ac.jp

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

Bug ID: 71608
   Summary: Wrong constant folding
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC 7.0.0 for x86_64 miscompiles the following code.

% cat test.c  

int x = 0x4000;

int main (void)
{
  int t = - 0x7FFF - ( -2 * x ) ;
  if (t != 1) __builtin_abort();
  return 0;
}

% gcc-7.0 test.c -O3  
% ./a.out 
zsh: abort (core dumped)  ./a.out

% gcc-7.0 -v  
Using built-in specs.
COLLECT_GCC=gcc-7.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-7.0.0/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-7.0.0 --disable-nls
--disable-multilib --program-suffix=-7.0 --enable-languages=c
Thread model: posix
gcc version 7.0.0 20160621 (experimental) (GCC) 

Reproduces on gcc-4.3.6 or later with -O3.
Also reproduces on 5.1.0 or later with -O1.

[Bug target/71549] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

2016-06-21 Thread hjl at gcc dot gnu.org

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #7 from H.J. Lu  ---
Fixed.

--- Comment #8 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jun 21 14:24:31 2016
New Revision: 237647

URL: https://gcc.gnu.org/viewcvs?rev=237647&root=gcc&view=rev
Log:
Convert V1TImode register to TImode in debug insn

TImode register referenced in debug insn can be converted to V1TImode
by scalar to vector optimization.  After converting a TImode register
to V1TImode, we need to check all debug insns on its use chain to
convert the V1TImode register to SUBREG TImode.

gcc/

2016-06-21  H.J. Lu  
Ilya Enkovich  

PR target/71549
* config/i386/i386.c (timode_scalar_chain::fix_debug_reg_uses):
New member function to convert V1TImode register to SUBREG
TImode in debug insn.
(timode_scalar_chain::convert_insn): Call fix_debug_reg_uses
after changing register mode to V1TImode.

gcc/testsuite/

2016-06-21  H.J. Lu  

PR target/71549
* gcc.target/i386/pr71549.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr71549.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71549] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

2016-06-21 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #7 from H.J. Lu  ---
Fixed.

--- Comment #8 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jun 21 14:24:31 2016
New Revision: 237647

URL: https://gcc.gnu.org/viewcvs?rev=237647&root=gcc&view=rev
Log:
Convert V1TImode register to TImode in debug insn

TImode register referenced in debug insn can be converted to V1TImode
by scalar to vector optimization.  After converting a TImode register
to V1TImode, we need to check all debug insns on its use chain to
convert the V1TImode register to SUBREG TImode.

gcc/

2016-06-21  H.J. Lu  
Ilya Enkovich  

PR target/71549
* config/i386/i386.c (timode_scalar_chain::fix_debug_reg_uses):
New member function to convert V1TImode register to SUBREG
TImode in debug insn.
(timode_scalar_chain::convert_insn): Call fix_debug_reg_uses
after changing register mode to V1TImode.

gcc/testsuite/

2016-06-21  H.J. Lu  

PR target/71549
* gcc.target/i386/pr71549.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr71549.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71068] [5/6/7 Regression] ICE in check_data_variable(): Bad expression

2016-06-21 Thread kargl at gcc dot gnu.org

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

--- Comment #2 from kargl at gcc dot gnu.org ---
cat pr71068.diff
Index: resolve.c
===
--- resolve.c   (revision 236243)
+++ resolve.c   (working copy)
@@ -14495,6 +14495,17 @@ check_data_variable (gfc_data_variable *
   mpz_init_set_si (offset, 0);
   e = var->expr;

+  /* F2008:C565.  */
+  if (flag_coarray == GFC_FCOARRAY_LIB && e->expr_type == EXPR_FUNCTION
+  && e->value.function.isym
+  && (e->value.function.isym->id == GFC_ISYM_CAF_GET
+ || e->value.function.isym->id == GFC_ISYM_CAF_SEND))
+{
+  gfc_error ("DATA statement object near %L shall not have a coindex",
+where);
+  return false;
+}
+
   if (e->expr_type != EXPR_VARIABLE)
 gfc_internal_error ("check_data_variable(): Bad expression");

[Bug tree-optimization/71608] Wrong constant folding

2016-06-21 Thread glisse at gcc dot gnu.org

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
I am pretty sure there is a dup somewhere...

[Bug fortran/71068] [5/6/7 Regression] ICE in check_data_variable(): Bad expression

2016-06-21 Thread dominiq at lps dot ens.fr

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

--- Comment #3 from Dominique d'Humieres  ---
> cat pr71068.diff
> Index: resolve.c
> ===
...

Different patch at https://gcc.gnu.org/ml/fortran/2016-06/msg00067.html.

[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

2016-06-21 Thread jnorris at gcc dot gnu.org

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

jnorris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from jnorris at gcc dot gnu.org ---
Complete backporting.

[Bug tree-optimization/71608] Wrong constant folding

2016-06-21 Thread pinskia at gcc dot gnu.org

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

--- Comment #2 from Andrew Pinski  ---
Hmm. Doesnt -2 * x overflow?

[Bug tree-optimization/71608] Wrong constant folding

2016-06-21 Thread glisse at gcc dot gnu.org

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

--- Comment #3 from Marc Glisse  ---
negate_expr_p, for MULT_EXPR, has:

  /* INT_MIN/n * n doesn't overflow while negating one operand it does
 if n is a power of two.  */
  if (INTEGRAL_TYPE_P (TREE_TYPE (t))
  && ! TYPE_OVERFLOW_WRAPS (TREE_TYPE (t))
  && ! ((TREE_CODE (TREE_OPERAND (t, 0)) == INTEGER_CST
 && ! integer_pow2p (TREE_OPERAND (t, 0)))
|| (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST
&& ! integer_pow2p (TREE_OPERAND (t, 1)
break;

It handles INT_MIN/n * n where n is a power of 2 but not -(INT_MIN/n) * -n.

I am not convinced by the way fold_negate_expr handles this either.

[Bug tree-optimization/71608] Wrong constant folding

2016-06-21 Thread glisse at gcc dot gnu.org

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #2)
> Hmm. Doesnt -2 * x overflow?

(-2) * x gives INT_MIN, no overflow there. 2*x does overflow. And we optimize
the first to the second...

[Bug tree-optimization/71609] New: [7 regression] test case gfortran.dg/vect/vect-8.f90 fails starting with r237549

2016-06-21 Thread seurer at linux dot vnet.ibm.com

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

Bug ID: 71609
   Summary: [7 regression] test case gfortran.dg/vect/vect-8.f90
fails starting with r237549
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on both powerpc64 LE and BE as well as on X86.

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/vect/vect-8.f90 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O  -O2
-ftree-vectorize -fvect-cost-model=unlimited -fdump-tree-vect-details -maltivec
-mpower8-vector -S   -o vect-8.s(timeout = 300)
spawn /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/vect/vect-8.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -O2 -ftree-vectorize
-fvect-cost-model=unlimited -fdump-tree-vect-details -maltivec -mpower8-vector
-S -o vect-8.s
PASS: gfortran.dg/vect/vect-8.f90   -O  (test for excess errors)
FAIL: gfortran.dg/vect/vect-8.f90   -O   scan-tree-dump-times vect "vectorized
20 loops" 1
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/vect/vect.exp
completed in 4 seconds

=== gfortran Summary ===

# of expected passes1
# of unexpected failures1

[Bug tree-optimization/71609] [7 regression] test case gfortran.dg/vect/vect-8.f90 fails starting with r237549

2016-06-21 Thread amker at gcc dot gnu.org

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

--- Comment #1 from amker at gcc dot gnu.org ---
Should be fixed by https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01501.html ?

Thanks,
bin

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

2016-06-21 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Created attachment 38740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38740&action=edit
gcc7-pr66867-wip.patch

WIP untested patch using the same technique as we use for __builtin_*_overflow*
builtins.  I'll need to still finish writing the expansion for the case when we
should expand it to external calls, once that is tested disable the ifn folding
for !flag_inline_atomics, fix up -fsanitize=threads, use for other spots that
look at atomic builtins.
And, we need some optimization that would optimize the case where REALPART_EXPR
is conditionally stored into a non-addressable var - we can store the oldval
there unconditionally then, because it can't create a race.

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

2016-06-21 Thread gjl at gcc dot gnu.org

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #15 from Georg-Johann Lay  ---
Fixed in 4.9.4, 5.5 and 6.2+.

[Bug fortran/71068] [5/6/7 Regression] ICE in check_data_variable(): Bad expression

2016-06-21 Thread burnus at gcc dot gnu.org

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

--- Comment #4 from Tobias Burnus  ---
Author: burnus
Date: Tue Jun 21 18:36:25 2016
New Revision: 237656

URL: https://gcc.gnu.org/viewcvs?rev=237656&root=gcc&view=rev
Log:
2016-06-20  Tobias Burnus  

PR fortran/71068
* resolve.c (resolve_function): Don't resolve caf_get/caf_send.
(check_data_variable): Strip-off caf_get before checking.

PR fortran/71068
* gfortran.dg/coarray/data_1.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/coarray/data_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c/71610] New: Improve location for "warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]"?

2016-06-21 Thread ch3root at openwall dot com

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

Bug ID: 71610
   Summary: Improve location for "warning: ISO C restricts
enumerator values to range of ‘int’ [-Wpedantic]"?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Only the first token of the offending value is underlined for this warning.
Underlining all the value (like in clang) seems to be better.

Source code:

--
int main()
{
  enum { c = -30 };
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:3:14: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
   enum { c = -30 };
  ^
--

gcc version: gcc (GCC) 7.0.0 20160616 (experimental)

For comparison:

--
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
test.c:3:10: warning: ISO C restricts enumerator values to range of 'int'
(-30 is too small) [-Wpedantic]
  enum { c = -30 };
 ^   ~~~
1 warning generated.
--

clang version: clang version 3.9.0 (trunk 271312)

[Bug sanitizer/71611] New: UBSan shows type '' for enums based on long

2016-06-21 Thread ch3root at openwall dot com

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

Bug ID: 71611
   Summary: UBSan shows type '' for enums based on long
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Source code:

--
#include 

int main()
{
  enum { c = LONG_MIN } x = c;
  x = -x;
  return x;
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 -fsanitize=undefined test.c &&
./a.out
test.c:6:5: runtime error: negation of -9223372036854775808 cannot be
represented in type ''; cast to an unsigned type to negate this value
to itself
--

gcc version: gcc (GCC) 7.0.0 20160616 (experimental)

For comparison:

--
$ clang -std=c11 -Weverything -O3 -fsanitize=undefined test.c && ./a.out
test.c:5:10: warning: ISO C restricts enumerator values to range of 'int'
(-9223372036854775808 is too small) [-Wpedantic]
  enum { c = LONG_MIN } x = c;
 ^   
test.c:7:10: warning: implicit conversion loses integer precision: 'enum
(anonymous enum at test.c:5:3)' to 'int' [-Wshorten-64-to-32]
  return x;
  ~~ ^
2 warnings generated.
test.c:6:7: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long'; cast to an unsigned type to negate this value to
itself
--

clang version: clang version 3.9.0 (trunk 271312)

[Bug fortran/71612] [Coarray] Wrongly rejects coindexed variables in READ

2016-06-21 Thread burnus at gcc dot gnu.org

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

--- Comment #1 from Tobias Burnus  ---
Something like the following is needed; the first part should be fine
(untested) and be sufficient for compiling the code, but the FIXME is required
to get it actually working ...

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 4378313..950f5a2 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8645,4 +8645,19 @@ resolve_transfer (gfc_code *code)
-  if (code->ext.dt && code->ext.dt->dt_io_kind->value.iokind == M_READ
-  && !gfc_check_vardef_context (exp, false, false, false,
-   _("item in READ")))
-return;
+  if (code->ext.dt && code->ext.dt->dt_io_kind->value.iokind == M_READ)
+{
+  bool coindexed = false;
+  if (exp->expr_type == EXPR_FUNCTION
+ && exp->value.function.isym
+ && exp->value.function.isym->id == GFC_ISYM_CAF_GET)
+   {
+ coindexed = true;
+ remove_caf_get_intrinsic (exp);
+   }
+
+  if (!gfc_check_vardef_context (exp, false, false, false,
+_("item in READ")))
+   return;
+  if (coindexed)
+   {
+// FIXME: Add temporary - and send it via GFC_ISYM_CAF_SEND
+   }
+}

[Bug c/71613] New: Useful warnings silenced when macros from system headers are used

2016-06-21 Thread ch3root at openwall dot com

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

Bug ID: 71613
   Summary: Useful warnings silenced when macros from system
headers are used
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Useful warnings seem to be silenced when macros from system headers are used.
For example, in the example below a warning would be useful for both enums but
only one warning is shown. The same can probably happen for other warnings.

Source code:

--
#include 

int main()
{
  enum { e1 = LLONG_MIN };
  enum { e2 = +LLONG_MIN };
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:6:15: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
   enum { e2 = +LLONG_MIN };
   ^
--

gcc version: gcc (GCC) 7.0.0 20160616 (experimental)

[Bug fortran/71612] [Coarray] Wrongly rejects coindexed variables in READ

2016-06-21 Thread dominiq at lps dot ens.fr

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
AFAICT the test compiles and runs with -fcoarray=single, but not with
-fcoarray=lib. The test does not link before gcc-5, e.g., 4.8 or 4.9.

[Bug fortran/71068] [5/6/7 Regression] ICE in check_data_variable(): Bad expression

2016-06-21 Thread burnus at gcc dot gnu.org

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED on the trunk.

Thanks for the bug report!

[Bug tree-optimization/71609] [7 regression] test case gfortran.dg/vect/vect-8.f90 fails starting with r237549

2016-06-21 Thread seurer at linux dot vnet.ibm.com

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

Bill Seurer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Bill Seurer  ---
It is fixed, thanks!

[Bug c/71603] pragma diagnostic pop fails to restore warning level

2016-06-21 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
We only record the kind of warning, not any variables associated to it: See
diagnostic_classify_diagnostic(). This will need changes in:

/* Each time a diagnostic's classification is changed with a pragma,
   we record the change and the location of the change in an array of
   these structs.  */
struct diagnostic_classification_change_t
{
  location_t location;
  int option;
  diagnostic_t kind;
};

to record the 'arg' and save/restore it. It is not a small change but it looks
pretty straight-forward.

However, we do not make any attempt to follow the chain of dependencies for a
'pop'. That could be a bit more intricate to accomplish since we only want to
restore to the previous state, not reset to the default.

[Bug c/71597] Confusing error for incompatible enums, wrong previous declaration

2016-06-21 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||manu at gcc dot gnu.org
Summary|Confusing warning for   |Confusing error for
   |incompatible enums  |incompatible enums, wrong
   ||previous declaration
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Indeed.

[Bug c/71567] Incorrect loop optimization

2016-06-21 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #3)
> Try -fno-aggressive-loop-optimizations .

Note that it is not ensured that switch will disable all optimizations that
rely on undefined behavior: https://gcc.gnu.org/wiki/FAQ#misoptimization

Your code is still broken and it may get miscompiled with a different version
of GCC or a different compiler or due to any changes to the surrounding code.

[Bug c/71610] Improve location for "warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]"?

2016-06-21 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
We have now the capability to do this. However, there are so many places that
need improving that we do not have the manpower to do the necessary changes.
Any help would be appreciated.

[Bug c/71613] Useful warnings silenced when macros from system headers are used

2016-06-21 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
I think this is the same issue as for NULL (see Locations here:
https://gcc.gnu.org/wiki/DiagnosticsGuidelines), however, we cannot keep track
of all NULL-like macros defined in system-headers, can we?

Perhaps a better work-around is to follow Clang, and give the warning at the
location of the label plus highlighting the values:

test.c:3:10: warning: ISO C restricts enumerator values to range of 'int'
(-30 is too small) [-Wpedantic]
  enum { c = -30 };
 ^   ~~~

That would completely avoid the problem.

[Bug c/71613] Useful warnings silenced when macros from system headers are used

2016-06-21 Thread joseph at codesourcery dot com

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

--- Comment #2 from joseph at codesourcery dot com  ---
Really we need to review warnings and work out in each case what's right 
for macros from system headers.  If the issue is about the macro's 
contents, the warnings should be avoided; if it relates in some way to the 
context in which it is used, the warnings shouldn't be avoided.

[Bug target/70123] [5 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144

2016-06-21 Thread law at redhat dot com

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

--- Comment #11 from Jeffrey A. Law  ---
Certainly OK by me to backport to gcc-5.  So go for it Bernd when you're back
from PTO.

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

2016-06-21 Thread gcc at joe dot coffland.com

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

Joseph Coffland  changed:

   What|Removed |Added

 CC||gcc at joe dot coffland.com

--- Comment #15 from Joseph Coffland  ---
After compiling and running the test case, I can confirm that this bug still
exists in ``gcc (Debian 5.3.1-11) 5.3.1 20160307``.  It crashes both under Wine
and 64-bit Windows 7.

I would love to see this fixed.  It's the only thing keeping me from building
all of the Folding@home software for Windows under Linux.  We need AVX for our
protein folding simulations.  The extra performance gained by using AVX is
significant.  My other options are clang or building on Windows using MSVC or
Intel compilers.

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-11'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160307 (Debian 5.3.1-11) 
```

[Bug fortran/70864] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

2016-06-21 Thread ian_harvey at bigpond dot com

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

Ian Harvey  changed:

   What|Removed |Added

 CC||ian_harvey at bigpond dot com

--- Comment #2 from Ian Harvey  ---
*** Bug 71580 has been marked as a duplicate of this bug. ***

[Bug fortran/71580] Internal compiler error associated with type bound defined assignment

2016-06-21 Thread ian_harvey at bigpond dot com

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

Ian Harvey  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Ian Harvey  ---
Likely so.

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

[Bug middle-end/71614] New: ppc __gcc_qmul is mis-optimized not to be commutative

2016-06-21 Thread timshen at gcc dot gnu.org

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

Bug ID: 71614
   Summary: ppc __gcc_qmul is mis-optimized not to be commutative
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timshen at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38741&action=edit
reduced c file

The libgcc __gcc_qmul seems to be miscompiled. Suppose the attached file is
a.c, compiling it with -O1 gives:
% ~/sandbox/bin/powerpc64le-linux-gnu-gcc -O1 -static b.c && ./a.out
4059dd231dd95f2a 3cff6dea3a4b2648
4059dd231dd95f2a 3cff6dea3a4b2648

-O2 gives:
% ~/sandbox/bin/powerpc64le-linux-gnu-gcc -O2 -static b.c && ./a.out
4059dd231dd95f2a 3cff6dea3a4b2648
4059dd231dd95f2a 3cff6dea3a4b2646

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

2016-06-21 Thread timshen at gcc dot gnu.org

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

--- Comment #1 from Tim Shen  ---
> Suppose the attached file is a.c

s/a\.c/b.c

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

2016-06-21 Thread pinskia at gcc dot gnu.org

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

--- Comment #2 from Andrew Pinski  ---
Two things, try -fno-strict-aliasing first.
Since your main violates C aliasing rules.
Second thing to try is -ffp-contract=off as I am suspecting:
  v = a*d;
  w = b*c;
  tau += v + w; /* Add in other second-order terms.  */
  u = t + tau;

is using an fmadd here.

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

2016-06-21 Thread timshen at gcc dot gnu.org

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

--- Comment #3 from Tim Shen  ---
(In reply to Andrew Pinski from comment #2)
> Two things, try -fno-strict-aliasing first.
> Since your main violates C aliasing rules.
> Second thing to try is -ffp-contract=off as I am suspecting:
>   v = a*d;
>   w = b*c;
>   tau += v + w;   /* Add in other second-order terms.  */
>   u = t + tau;
> 
> is using an fmadd here.

Passing -fno-strict-aliasing doesn't change the -O2 result; -ffp-contract=off
does give the consistent result as -O1.

What result is __gcc_qmul supposed to give? As a user I'd expect the
commutativity here.

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

2016-06-21 Thread pinskia at gcc dot gnu.org

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

--- Comment #4 from Andrew Pinski  ---
The fix would then put a barrier to force GCC not to do contracting.

Something like:
  v = a*d;
  w = b*c;
  asm("":"+f"(v));
  asm("":"+f"(w));
  tau += v + w; /* Add in other second-order terms.  */

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

2016-06-21 Thread pinskia at gcc dot gnu.org

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

--- Comment #5 from Andrew Pinski  ---
The other thing to note is:
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00157.html

[Bug fortran/71615] New: wrong float point result with {-Ofast, -march=native, and valgrind}

2016-06-21 Thread wangmianzhi1 at linuxmail dot org

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

Bug ID: 71615
   Summary: wrong float point result with {-Ofast, -march=native,
and valgrind}
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangmianzhi1 at linuxmail dot org
  Target Milestone: ---

Created attachment 38742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38742&action=edit
reduced test

Problem:
float point calculation gives wrong result

Hardware:
AMD A4-5000 CPU

Software:
Ubuntu 16.04 x86_64
gcc and valgrind from apt

Steps to Repeat the Bug:
1. compile the attached REDUCED test code with
$ gfortran -Wall -Ofast -march=native test.f90 -o test 
2. execute the program via valgrind
$ valgriand ./test

Result:
The calculation gives
   0.   -2.6901205975860183   0.95110109754591643
While the correct result should be
   0.  -0.94280905929685954   0.3328322831940

Note:
Would give the correct result WITHOUT ANY of {-Ofast, -march=native, or
valgrind}.

[Bug target/71615] wrong float point result with {-Ofast, -march=native, and valgrind}

2016-06-21 Thread pinskia at gcc dot gnu.org

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
  Component|fortran |target
   Severity|major   |normal

--- Comment #1 from Andrew Pinski  ---
This sounds like a bug in valgrind.

[Bug fortran/71592] Add some facilities for compile-time check

2016-06-21 Thread heresy-me at hotmail dot com

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

--- Comment #2 from 鍾  ---
(In reply to Jakub Jelinek from comment #1)
> You can't use such static_assert this way in C++, unless the function is
> constexpr, nor in C (always), so guess you are proposing something
> completely different (like, if this function/subroutine is inlined and the
> expression is after inlining/optimizations constant, then see if it is true
> or false, otherwise do nothing.  So more like
> if (__builtin_constant_p (r >= 0.0))
>   {
> if (!(r >= 0.0)) __builtin_warning ("...");
>   }
> Also, !$ already has a specific meaning in OpenMP, so it would be a bad idea
> to abuse it.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
Please read this bug-report page. static assert is now part of C11 standard.
And can be used in 4.7 and above with _Static_assert keyword.

Actually, This kind of "static check" need not to alter any function/subroutine
body. It added and used by the consumer of functions/subroutine. no relate to
inlining and optimization anything. It signed as "$!" on the function
declaration or function implementation(so it don't reserved on real execution
code, works only on current compilation unit if the compiler recognize this
directive). "$!" is not only used by OpenMP($!omp), but also used by
OpenACC($!openacc), and used to import or export the dll function on ivf($!DEV
DLLIMPORT or $!DEV DLLEXPORT), etc.

[Bug c++/71616] New: ICE on valid C++ code at -O1 and above on x86_64-linux-gnu: in binds_to_current_def_p, at symtab.c:2232

2016-06-21 Thread su at cs dot ucdavis.edu

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

Bug ID: 71616
   Summary: ICE on valid C++ code at -O1 and above on
x86_64-linux-gnu: in binds_to_current_def_p, at
symtab.c:2232
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++ code causes an ICE when compiled with the current GCC trunk
at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 6.1.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160621 (experimental) [trunk revision 237650] (GCC) 
$ 
$ g++-trunk -O0 -c small.cpp
$ g++-6.1 -O1 -c small.cpp
$ 
$ g++-trunk -O1 -c small.cpp
_ZL21__gthrw_pthread_equalv/1 (int __gthrw_pthread_equal()) @0x7f9c64d75170
  Type: function definition analyzed alias transparent_alias weakref
  Visibility: weak
  References: pthread_equal/0 (alias)
  Referring: 
  Availability: available
  First run: 0
  Function flags: process
  Called by: _Z3foov/2 (1.00 per call) (can throw external) 
  Calls: 
small.cpp: In function ‘int pthread_equal()’:
small.cpp:10:1: internal compiler error: in binds_to_current_def_p, at
symtab.c:2232
 }
 ^
0x9ad798 symtab_node::binds_to_current_def_p(symtab_node*)
../../gcc-source-trunk/gcc/symtab.c:2232
0x9b6b29 set_const_flag_1
../../gcc-source-trunk/gcc/cgraph.c:2500
0x9b6a3c set_const_flag_1
../../gcc-source-trunk/gcc/cgraph.c:2531
0x9b6d9f cgraph_node::set_const_flag(bool, bool)
../../gcc-source-trunk/gcc/cgraph.c:2562
0x14e2a41 execute
../../gcc-source-trunk/gcc/ipa-pure-const.c:1829
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


--


extern "C" __inline __attribute__ ((__gnu_inline__)) 
int pthread_equal () {}

static __typeof pthread_equal __gthrw_pthread_equal 
__attribute__ ((__weakref__ ("pthread_equal")));

void foo () 
{
  __gthrw_pthread_equal ();
}

[Bug fortran/71592] Add some facilities for compile-time check

2016-06-21 Thread kargl at gcc dot gnu.org

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to 鍾 from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > You can't use such static_assert this way in C++, unless the function is
> > constexpr, nor in C (always), so guess you are proposing something
> > completely different (like, if this function/subroutine is inlined and the
> > expression is after inlining/optimizations constant, then see if it is true
> > or false, otherwise do nothing.  So more like
> > if (__builtin_constant_p (r >= 0.0))
> >   {
> > if (!(r >= 0.0)) __builtin_warning ("...");
> >   }
> > Also, !$ already has a specific meaning in OpenMP, so it would be a bad idea
> > to abuse it.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
> Please read this bug-report page. static assert is now part of C11 standard.
> And can be used in 4.7 and above with _Static_assert keyword.
> 
> Actually, This kind of "static check" need not to alter any
> function/subroutine body. It added and used by the consumer of
> functions/subroutine. no relate to inlining and optimization anything. It
> signed as "$!" on the function declaration or function implementation(so it
> don't reserved on real execution code, works only on current compilation
> unit if the compiler recognize this directive). "$!" is not only used by
> OpenMP($!omp), but also used by OpenACC($!openacc), and used to import or
> export the dll function on ivf($!DEV DLLIMPORT or $!DEV DLLEXPORT), etc.

Just use the pre-processor.

% cat a.F90
program foo
   external mysqrt
   real x, mysqrt
   x = -1.
#ifdef EBUG
   if (x < 0) then
  stop "I'm an idiot to call mysqrt() with a negative arg"
   end if
#endif
   print *, mysqrt(x)
end program foo

function mysqrt(x)
   real x, mysqrt
   mysqrt = sqrt(x)
end function

% gfc -o z -DEBUG a.F90 && ./z
STOP I'm an idiot to call mysqrt() with a negative arg
% gfc -o z a.F90 && ./z
  NaN

[Bug fortran/71592] Add some facilities for compile-time check

2016-06-21 Thread jakub at gcc dot gnu.org

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to 鍾 from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > You can't use such static_assert this way in C++, unless the function is
> > constexpr, nor in C (always), so guess you are proposing something
> > completely different (like, if this function/subroutine is inlined and the
> > expression is after inlining/optimizations constant, then see if it is true
> > or false, otherwise do nothing.  So more like
> > if (__builtin_constant_p (r >= 0.0))
> >   {
> > if (!(r >= 0.0)) __builtin_warning ("...");
> >   }
> > Also, !$ already has a specific meaning in OpenMP, so it would be a bad idea
> > to abuse it.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
> Please read this bug-report page. static assert is now part of C11 standard.
> And can be used in 4.7 and above with _Static_assert keyword.

You are either not showing the intended use, or misunderstanding what
_Static_assert is.  _Static_assert is a compile time assertion during parsing.
The expression in it must be integral constant expression, otherwise you get
error.  So, you certainly can't use a function argument in there.

> Actually, This kind of "static check" need not to alter any
> function/subroutine body. It added and used by the consumer of
> functions/subroutine. no relate to inlining and optimization anything. It
> signed as "$!" on the function declaration or function implementation(so it
> don't reserved on real execution code, works only on current compilation
> unit if the compiler recognize this directive). "$!" is not only used by
> OpenMP($!omp), but also used by OpenACC($!openacc), and used to import or
> export the dll function on ivf($!DEV DLLIMPORT or $!DEV DLLEXPORT), etc.

You are mixing the order, $! means nothing, !$ followed by space or & is OpenMP
conditional compilation, !$omp is OpenMP directive, !$acc is OpenACC directive.

[Bug fortran/71592] Add some facilities for compile-time check

2016-06-21 Thread heresy-me at hotmail dot com

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

鍾  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #5 from 鍾  ---
full_assertion_declaration ::= assertion_directive assertion_declaration
assertion_directive ::= *$assertion|c$assertion|!$assertion
assertion_declaration ::= assertion_body{,assertion_body}
assertion_body ::= static_assertion|dynamic_assertion
static_assertion ::= static(compile_time_boolean_expression,[failure_message])
dynamic_assertion ::=
dynamic(execution_time_boolean_expression,[failure_message])
failure_message ::= static_fortran_string

the static assertion directives of procedure is not only work on current
compilation unit, but also work on any module(possibly). a procedure contain
static assertion directive of a module, its assertion can contained by the
modules' mod file. So any procedures use this module procedure will be checked
the assertions by the compiler on compile-time(not on execution-time).

the dynamic assertion isn't like the simple preprocess assertion. dynamic
assertion will generate some check code, but the check code is not expanded on
the body of procedures. it can be a independent code fraction, or inlined to
the procedure consumer, but never alter the execution code of called procedure.

Then, the assertion can added freely for the function when declaration or
implementation.

75 matches

Mail list logo