[Bug c++/77739] New: internal compiler error: in create_tmp_var, at gimple-expr.c:524

[vcato1701 at yahoo dot com]

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

Bug ID: 77739
   Summary: internal compiler error: in create_tmp_var, at
gimple-expr.c:524
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vcato1701 at yahoo dot com
  Target Milestone: ---

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) 


Command: g++ -c -std=c++14 ice.cpp

Output:

ice.cpp: In member function ‘auto B::g(Args&& ...) [with Args = {A, const
char (&)[1]}]’:
ice.cpp:15:41: internal compiler error: in create_tmp_var, at gimple-expr.c:524
return [=](){ return f(args...); };


ice.cpp:

template 
struct A {
A() { }
A(const A &) { }
};


struct B
{
B();

template 
auto g(Args&&... args)
{
   return [=](){ return f(args...); };
}

void f(A,const char*) { }
};


B::B()
{
g(A(),"");
}

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[anton at samba dot org]

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

--- Comment #4 from Anton Blanchard  ---
Created attachment 39683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39683=edit
Another bitop LHS test case

Here's another issue found in the Linux kernel. Seems like this should be a
single lwz/stw since the union of counter and the bitops completely overlap.

The half word store followed by word load is going to prevent it from store
forwarding.

 :
   0:   00 00 03 81 lwz r8,0(r3)
   4:   20 00 89 78 clrldi  r9,r4,32
   8:   c2 0f 2a 79 rldicl  r10,r9,33,31
   c:   00 f8 48 51 rlwimi  r8,r10,31,0,0
  10:   5e 00 2a 55 rlwinm  r10,r9,0,1,15
  14:   00 00 03 91 stw r8,0(r3)
  18:   00 00 83 b0 sth r4,0(r3)
  1c:   00 00 42 60 ori r2,r2,0
  20:   00 00 23 81 lwz r9,0(r3)
  24:   00 04 29 55 rlwinm  r9,r9,0,16,0
  28:   78 53 29 7d or  r9,r9,r10
  2c:   00 00 23 91 stw r9,0(r3)
  30:   20 00 80 4e blr

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01777.html

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-26
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug middle-end/68733] [6/7 Regression] FAIL: libgomp.c/target-29.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
Similar fails:

FAIL: c-c++-common/gomp/clauses-2.c  (test for errors, line 51)
FAIL: c-c++-common/gomp/clauses-2.c (test for excess errors)

FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 51)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98 (test for excess errors)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++11  (test for errors, line 51)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++11 (test for excess errors)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++14  (test for errors, line 51)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++14 (test for excess errors)

[Bug target/77738] New: Invalid initialisation of ar.lc register

[sch...@linux-m68k.org]

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

Bug ID: 77738
   Summary: Invalid initialisation of ar.lc register
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: ia64-*-*

The doloop pass miscalculates the initial value of the ar.lc register if the
loop variable is narrower than 64 bit and the loop count is bigger then
INT_MAX.

int
main (void)
{
  unsigned int t = 0x8001;

  while (--t) {}
}

movl r14 = -2147483648
;;
mov ar.lc = r14
.L2:
;;
br.cloop.sptk.few .L2

[Bug tree-optimization/77737] New: FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times optimized "" 1

[danglin at gcc dot gnu.org]

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

Bug ID: 77737
   Summary: FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times
optimized "" 1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 39682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39682=edit
Tree dump

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
-fno-di
agnostics-show-caret -fdiagnostics-color=never   -O2 -fdump-tree-optimized -S
-o
 scev-5.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
-fno-diag
nostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-optimized -S -o
sce
v-5.s
PASS: gcc.dg/tree-ssa/scev-5.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times optimized "" 1

Number is 2.

[Bug testsuite/77736] New: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-2.c (test for warnings, line 50)

[danglin at gcc dot gnu.org]

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

Bug ID: 77736
   Summary: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-2.c  (test
for warnings, line 50)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 39681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39681=edit
Test log.

Attached log for test.

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[tulipawn at gmail dot com]

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

--- Comment #5 from PeteVine  ---
OK, I hacked the last two to use -mcpu=cortex-a53 (the first one got switched
to -mtune) and the result looks like this:

http://openbenchmarking.org/result/1609258-LO-FORTRANAA63

Not exactly the original issues :)

[Bug testsuite/77735] New: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 358)

[danglin at gcc dot gnu.org]

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

Bug ID: 77735
   Summary: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test
for warnings, line 358)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 39680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39680=edit
Test log.

Attached test log.

[Bug c++/77733] Add fixit hint suggesting to use std::move

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
When template argument deduction is involved and the list of candidates is
displayed, the fixit becomes more useful, as the relevant function can get lost
in the list of failed overload resolution candidates:

struct X { };

struct Y {
  void foo();
  void foo(X&&);
  void foo(int, const X&);
  template void foo(T, X&&);
};

int main()
{
  X x;
  Y y;
  y.foo(x);
}


move.cc: In function ‘int main()’:
move.cc:14:10: error: no matching function for call to ‘Y::foo(X&)’
   y.foo(x);
  ^
move.cc:5:8: note: candidate: void Y::foo(X&&) 
   void foo(X&&);
^~~
move.cc:5:8: note:   conversion of argument 1 would be ill-formed:
move.cc:14:10: error: cannot bind rvalue reference of type ‘X&&’ to lvalue of
type ‘X’
   y.foo(x);
  ^
move.cc:4:8: note: candidate: void Y::foo()
   void foo();
^~~
move.cc:4:8: note:   candidate expects 0 arguments, 1 provided
move.cc:6:8: note: candidate: void Y::foo(int, const X&)
   void foo(int, const X&);
^~~
move.cc:6:8: note:   candidate expects 2 arguments, 1 provided
move.cc:7:29: note: candidate: template void Y::foo(T, X&&)
   template void foo(T, X&&);
 ^~~
move.cc:7:29: note:   template argument deduction/substitution failed:
move.cc:14:10: note:   candidate expects 2 arguments, 1 provided
   y.foo(x);
  ^

As well as a fixit hint suggesting to use std::move it might be useful to
display the "" text in colour so it stands out.

This example was reduced from:

#include 

int main()
{
  std::set::node_type x;
  std::set y;
  y.insert(x);
}

Which produces 48 lines of output (and they're long lines, so fill two pages at
80 columns) so highlighting the  and adding a fixit hint would make
a big difference.

[Bug testsuite/77734] New: FAIL: gcc.dg/plugin/must-tail-call-1.c -fplugin=./must_tail_call_plugin.so (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 77734
   Summary: FAIL: gcc.dg/plugin/must-tail-call-1.c
-fplugin=./must_tail_call_plugin.so (test  for excess
errors)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c   
 -fno-diagnostics-show-caret -fdiagnostics-color=never 
-fplugin=./must_tail_call_plugin.so  -ansi -pedantic-errors -S -o
must-tail-call-1.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never
-fplugin=./must_tail_call_plugin.so -ansi -pedantic-errors -S -o
must-tail-call-1.s/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c:
In functi
on
'caller':/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c:12:10:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
compiler exited with status 1
FAIL: gcc.dg/plugin/must-tail-call-1.c -fplugin=./must_tail_call_plugin.so
(test
 for excess errors)Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c:12:10:
error: cannot tail-call: target is not able to optimize the call into a sibling
call

Target has only limited capability to do sibling calls.

[Bug c++/77733] New: Add fixit hint suggesting to use std::move

[redi at gcc dot gnu.org]

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

Bug ID: 77733
   Summary: Add fixit hint suggesting to use std::move
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct X { };

struct Y {
  void foo();
  void foo(X&&);
  void foo(int, const X&);
  void foo(int, X&&);
};

int main()
{
  X x;
  Y y;
  y.foo(x);
}

Produces the error:

move.cc: In function ‘int main()’:
move.cc:14:10: error: cannot bind rvalue reference of type ‘X&&’ to lvalue of
type ‘X’
   y.foo(x);
  ^
move.cc:5:8: note:   initializing argument 1 of ‘void Y::foo(X&&)’
   void foo(X&&);
^~~

It would be useful to suggest using std::move(x) instead.

[Bug ipa/77732] New: FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[danglin at gcc dot gnu.org]

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

Bug ID: 77732
   Summary: FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times
cp "Discovered an indirect  call to a known target" 3
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 39679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39679=edit
ipa dump

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c   
-fno-d
iagnostics-show-caret -fdiagnostics-color=never   -O3 -fdump-ipa-cp-details -S
-
o ipcp-cstagg-7.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
-fno-di
agnostics-show-caret -fdiagnostics-color=never -O3 -fdump-ipa-cp-details -S -o
i
pcp-cstagg-7.s
PASS: gcc.dg/ipa/ipcp-cstagg-7.c (test for excess errors)
FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect 
call to a known target" 3

Possibly, this is a test issue:

  Jump functions of caller  foo/0:
indirect simple callsite, calling param -1, offset 0, for stmt x_13 = _3
(x_11);
   param 0: UNKNOWN
 Unknown alignment
 value: 0x0, mask: 0x
 Unknown VR
indirect simple callsite, calling param -1, offset 0, for stmt x_11 = _2
(x_9);
   param 0: UNKNOWN
 Unknown alignment
 value: 0x0, mask: 0x
 Unknown VR
indirect simple callsite, calling param -1, offset 0, for stmt x_9 = _1
(x_7
(D));
   param 0: PASS THROUGH: 1, op nop_expr
 Unknown alignment
 value: 0x0, mask: 0x
 Unknown VR

[Bug c++/77731] New: Parameter pack expansion doesn't work when used to define argument list

[michele.caini at gmail dot com]

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

Bug ID: 77731
   Summary: Parameter pack expansion doesn't work when  used to
define argument list
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

I refer to there questions on SO:
*
http://stackoverflow.com/questions/39690166/can-i-expand-a-parameters-pack-and-define-an-arguments-list-with-it
*
http://stackoverflow.com/questions/39665300/gcc-vs-clang-variadic-template-and-pointers-to-member-methods

In particular, GCC fails to compile the following snippets, but it should work
according with [temp.variadic]:

// Snippet 1

template
struct S {
template
void m() {}
};

int main() {
S s;
s.m<0, 'c'>();
// This works, but it shouldn't instead
s.m<>();
}

// Snippet 2

struct S { void f() { } };
struct T { void f() { } };

template
struct U: M... {
template
void g() { }

void f() {
g<::f...>();
}
};

int main() {
U u;
u.f();
}

The same applies to GCC v7.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[n8tm at aol dot com]

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

--- Comment #10 from n8tm at aol dot com ---
Jerry ,
Thanks for the efforts and apparent progress. I will return to wired internet
territory and the win10 box next weekend.  I have the win8.1 laptop here.

Sent via the ASUS PadFone X mini, an AT 4G LTE smartphone

 Original Message 
From:"jvdelisle at gcc dot gnu.org" 
Sent:Sun, 25 Sep 2016 15:03:55 -0400
To:tpri...@computer.org
Subject:[Bug bootstrap/77593] [7 Regression] Bootstrap failure with
configure-target-libgfortran " cygwin64 Windows 10 anniversary

>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593
>
>--- Comment #9 from Jerry DeLisle  ---
>(In reply to tprince from comment #8)
>> I show my configure parameters in my test results posts.  At some time in
>> the past, each of them has been important.  I don't know if the parameters
>> quoted by cygwin release pertain to cross compiling.  As the parameters I
>> use have been successful again last week on win8.1 I don't see how they
>> might pertain to the f951 bootstrap failure on win10.  When I get back to
>> the win10 box I will compare with disable bootstrap.
>
>Tim, using your parameters I was able to build.  I proceeded to do a regression
>hunt and confirmed that it was at the DTIO patch on 8/31/2016.
>
>In this patch we added two new functions to libgfortran and set the symbol
>versioning. I modified the library by inserting a printf("ping\n") in the code
>path for a simple program.
>
>print *, "hello"
>end
>
>The ping does not show which means the wrong library is being used at run time.
>
>I am trying various config and bath settings to see if I can sort it out. No
>luck so far.
>
>-- 
>You are receiving this mail because:
>You reported the bug.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
(In reply to tprince from comment #8)
> I show my configure parameters in my test results posts.  At some time in
> the past, each of them has been important.  I don't know if the parameters
> quoted by cygwin release pertain to cross compiling.  As the parameters I
> use have been successful again last week on win8.1 I don't see how they
> might pertain to the f951 bootstrap failure on win10.  When I get back to
> the win10 box I will compare with disable bootstrap.

Tim, using your parameters I was able to build.  I proceeded to do a regression
hunt and confirmed that it was at the DTIO patch on 8/31/2016.

In this patch we added two new functions to libgfortran and set the symbol
versioning. I modified the library by inserting a printf("ping\n") in the code
path for a simple program.

print *, "hello"
end

The ping does not show which means the wrong library is being used at run time.

I am trying various config and bath settings to see if I can sort it out. No
luck so far.

[Bug fortran/77429] ICE in gfc_check_dependency, at fortran/dependency.c:1261

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
fixed on trunk.

[Bug fortran/77429] ICE in gfc_check_dependency, at fortran/dependency.c:1261

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Sep 25 18:46:28 2016
New Revision: 240477

URL: https://gcc.gnu.org/viewcvs?rev=240477=gcc=rev
Log:
2016-09-25  Steven G. Kargl  

PR fortran/77429 
* dependency.c (gfc_check_dependency):  Convert gcc_assert() to
a conditional and possible call to  gfc_internal_error().

2016-09-25  Steven G. Kargl  

PR fortran/77429 
* gfortran.dg/pr77429.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77429.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/76957] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Similar fail on hppa-unknown-linux-gnu:
FAIL: gcc.dg/graphite/scop-dsyrk.c scan-tree-dump-times graphite "number of
SCoPs: 1" 1

[Bug fortran/77694] ICE in optimize_binop_array_assignment, at fortran/frontend-passes.c:1080

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/77694] ICE in optimize_binop_array_assignment, at fortran/frontend-passes.c:1080

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Sep 25 17:30:27 2016
New Revision: 240476

URL: https://gcc.gnu.org/viewcvs?rev=240476=gcc=rev
Log:
2016-09-22  Steven G. Kargl  

PR fortran/77694
* frontend-passes.c (optimize_binop_array_assignment): Check pointer
for NULL.

2016-09-22  Steven G. Kargl  

PR fortran/77694
* gfortran.dg/pr77694.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77694.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #24)
> The patch in comment 20 (and SDK 10.9) causes the failures of the tests
> gcc.dg/torture/darwin-cfstring-3.c and g++.dg/torture/darwin-cfstring-3.C
> with -m32, see https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02290.html.
> These failures are due to the fact that lC is now emitted instead of LC and
> are silenced with the following patch
> 
> --- ../_clean/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c
> 2014-05-10
> 23:16:48.0 +0200
> +++ gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c  2016-09-24
> 17:03:58.0 +0200

thanks.

\n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && {  lp64 } } } } } */
> 
> I don't know if the replacement of LC with lC is really intended and if yes,
> a better fix would be to use "-mtarget-linker 85.2".

Yes, that's the intention of the patch (to make the some of the internal labels
visible to the linker - but not public); that's what using "l" instead of "L"
does.

There are almost certainly other instances that need to be fixed up (I didn't
yet review all the test-suite output).

As for using "-mtarget-linker 85.2" It would be better to test the most common
configurations in use (or both cases).  So I'd suggest your patch is a better
solution than the changing the target linker.

However, we should probably have at least one test somewhere that checks we
don't regress for older toolchains (so maybe add one for legacy toolchains,
with -mtarget-linker 85.2).

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to PeteVine from comment #3)
> What about ARMv7?
> 
> http://openbenchmarking.org/result/1609253-LO-MERGE859124

Similar point there. I have seen cortex-a7 and a9 acting way different. 

Also without a testcase it is hard to figure out what is going on.

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
What about ARMv7?

http://openbenchmarking.org/result/1609253-LO-MERGE859124

[Bug tree-optimization/77621] [6 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Uroš Bizjak  ---
Fixed for gcc-6.3+

[Bug tree-optimization/77621] [6 Regression] Internal compiler error for mtune=atom + msse2

[uros at gcc dot gnu.org]

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

--- Comment #22 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Sep 25 17:07:37 2016
New Revision: 240475

URL: https://gcc.gnu.org/viewcvs?rev=240475=gcc=rev
Log:
Backport from mainline
2016-09-21  Richard Biener  
Jakub Jelinek  

PR tree-optimization/77621
* tree-vect-data-refs.c (vect_analyze_data_ref_accesses): Split
group at non-vectorizable stmts.

Backport from mainline
2016-09-20  Uros Bizjak  

PR target/77621
* config/i386/i386.c (ix86_preferred_simd_mode) :
Don't return word_mode for !TARGET_VECTORIZE_DOUBLE.
(ix86_add_stmt_cost): Penalize DFmode vector operations
for !TARGET_VECTORIZE_DOUBLE.

testsuite/ChangeLog:

Backport from mainline
2016-09-21  Richard Biener  
Jakub Jelinek  

PR tree-optimization/77621
* gcc.dg/pr77621.c: New testcase.

Backport from mainline
2016-09-20  Uros Bizjak  

PR target/77621
* gcc.target/i386/pr77621.c: New test.
* gcc.target/i386/vect-double-2.c: Update scan-tree-dump-times
pattern, loop should vectorize with -mtune=atom.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr77621.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77621.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/vect-double-2.c
branches/gcc-6-branch/gcc/tree-vect-data-refs.c

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-25
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #10 from Andrew Pinski  ---
This is how we expand it on aarch64:
(insn 10 9 11 (set (reg:QI 81)
(mem:QI (reg/v/f:DI 80 [ string ]) [0 *string_9(D)+0 S1 A8])) t.c:4 -1
 (nil))

(insn 11 10 12 (set (reg:SI 82)
(ior:SI (subreg:SI (reg:QI 81) 0)
(const_int 32 [0x20]))) t.c:4 -1
 (nil))

(insn 12 11 13 (set (reg:SI 83)
(zero_extend:SI (subreg:QI (reg:SI 82) 0))) t.c:4 -1
 (nil))

(insn 13 12 14 (set (reg:CC 66 cc)
(compare:CC (reg:SI 83)
(const_int 116 [0x74]))) t.c:4 -1
 (nil))


-
(set (reg:SI 83)
(ior:SI (and:SI (subreg:SI (mem:QI (reg/v/f:DI 80 [ string ]) [0
*string_9(D)+0 S1 A8]) 0)
(const_int 223 [0xdf]))
(const_int 32 [0x20])))

Notice how the and there is 223, but really that can be still a zero_extend. 
Basically combine is going funny.

 CUT 

Note for 33, orr does not accept 33 so combine does not see 33 and does not
change the and part around the subreg.

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #2 from Andrew Pinski  ---
If someone is running on cortex-a57, please run with -mcpu=cortex-a57. Or if
running on thunderx, -mcpu=thunderx . Or -mcpu=native.  Basically I don't think
this is a true bug.

[Bug middle-end/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
One thing I noticed is the generic vector cost model sucks for almost all
cores. It causes to emit ld2/ld3 in cases where it would be more expensive than
if doing it scalar.

[Bug middle-end/77730] New: Fortran performance on aarch64 (6/7 regression heads-up)

[tulipawn at gmail dot com]

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

Bug ID: 77730
   Summary: Fortran performance on aarch64 (6/7 regression
heads-up)
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Not sure if it's serious enough, just a quick alert:

http://openbenchmarking.org/result/1609257-LO-FORTRANAA01

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

--- Comment #9 from Julian Andres Klode  ---
(In reply to Andrew Pinski from comment #8)
> This looks like missing removal of casts.
> 
> Note in C, char_var|32 is really the same as ((int)char_var)|32

Well. The loads of the byte are already zero-extend loads. The current code is
like saying:

   (int) ((int)char|32)

:)

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
This looks like missing removal of casts.

Note in C, char_var|32 is really the same as ((int)char_var)|32

[Bug testsuite/77411] object-size-9.c -fpic -m32 failure

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger  ---
Author: edlinger
Date: Sun Sep 25 15:12:05 2016
New Revision: 240472

URL: https://gcc.gnu.org/viewcvs?rev=240472=gcc=rev
Log:
2016-09-25  Bernd Edlinger  

backport from mainline
2016-09-23  Bernd Edlinger  
Tom de Vries  

PR testsuite/77411
* c-c++-common/ubsan/object-size-9.c: Call __builtin_exit in C++.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/object-size-9.c

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #7 from Florian Weimer  ---
Something similar happens on x86_64 with -Os.  The OR instruction operates on
%eax instead of %al:

 :
   0:   8a 07   mov(%rdi),%al
   2:   83 c8 20or $0x20,%eax
   5:   3c 74   cmp$0x74,%al

(Byte-wise OR would be 0x0c 0x20, one byte shorter.)

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

--- Comment #6 from Julian Andres Klode  ---
(In reply to Andrew Pinski from comment #4)
> Note this testcase needs to be improved as I have a patch which converts a
> switch with just one case and a default into anew if statement.

FWIW, The issue is exactly the same with if statements, like in:

int TrieCase3(const char *string)
{
if((string[0] | 32) == 't') {
if((string[1] | 32) == 'a') {
if((string[2] | 32) == 'g') {
return 42;
}
}
}
return -1;
}

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

--- Comment #5 from Julian Andres Klode  ---
Created attachment 39678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39678=edit
ppc64le

Hmm, AFAICT the same seems to happen on powerpc64le:

lbz 9,0(3)  # Load zero
ori 9,9,0x20# ors in 32
rlwinm 9,9,0,0xff   # zero extend value AFAICT
cmpwi 7,9,116


So far tested:

good: mipsel, x86_64, armhf (thumb2)
bad: aarch64, powerpc64le

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
Note this testcase needs to be improved as I have a patch which converts a
switch with just one case and a default into anew if statement.

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

--- Comment #3 from Julian Andres Klode  ---
Created attachment 39677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39677=edit
arm (thumb2) output at -O2

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

--- Comment #2 from Julian Andres Klode  ---
Created attachment 39676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39676=edit
Aarch64 output at -O2

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

--- Comment #1 from Julian Andres Klode  ---
Created attachment 39675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39675=edit
C reproducer

[Bug target/77729] New: aarch64 inserts unneeded uxtb after ldrb, orr ...32

[j...@jak-linux.org]

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

Bug ID: 77729
   Summary: aarch64 inserts unneeded uxtb after ldrb, orr ...32
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j...@jak-linux.org
  Target Milestone: ---

In the attached test case, the aarch64 target inserts a uxtb instruction that
is not needed:

ldrbw1, [x0]
orr w1, w1, 32
uxtbw1, w1
cmp w1, 116

The arm backend handles that just fine:

ldrbr3, [r0]@ zero_extendqisi2
orr r3, r3, #32
cmp r3, #116

It also works with 33 or 34 instead of 32 for whatever reasons.

[Bug tree-optimization/56365] [5 Regression] Missed opportunities for smin/smax standard name patterns when compiling as C++

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
Richi, if you're not going to backport any patches, maybe close this one as
fixed?

[Bug tree-optimization/58122] loops are not evaluated at compile time if loop count > 17

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
This issue seems to be working just fine.  Not sure what kind of test case to
add for this though... just scanning final assembler code for some expected hex
or dec constant?

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01764.html

[Bug c++/77725] An example from the standard regarding member lookup fails to compile

[tamiraviv at mail dot tau.ac.il]

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

Tamir Aviv  changed:

   What|Removed |Added

 CC||tamiraviv at mail dot tau.ac.il

--- Comment #1 from Tamir Aviv  ---
It's important to note that if you switch the order of inheritance in struct F 
(
instead of:  "struct F: public D, public E { };"
use: "struct F: public E, public F { };" 
)

this example compiled without an error, even though the standard say that the
order of derivation is not significant (10.1.2 Multiple base classes
[class.mi])

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #17)
> I think this is fixed for GCC 7 with -std=c++17 support.

No, it isn't. new T[10] will give suitably aligned memory, but not
std::allocator. Only the core part of alignment support was added in C++17,
we are expecting a corresponding library part in C++20. On the other hand,
providing it as an extension in C++17-mode (gnu++17?) might be ok (requires a
discussion).

[Bug tree-optimization/77719] [7 Regression] ICE in pp_string, at pretty-print.c:955

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #6 from Joost VandeVondele  
---
(In reply to kugan from comment #5)
> Sent a patch to fix this at
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01760.html.

Thanks, add this line before the first IF statement to silence the warnings:

  INTEGER :: isp,spdim,jsp,nsp

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres  ---
The patch in comment 20 (and SDK 10.9) causes the failures of the tests
gcc.dg/torture/darwin-cfstring-3.c and g++.dg/torture/darwin-cfstring-3.C with
-m32, see https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02290.html. These
failures are due to the fact that lC is now emitted instead of LC and are
silenced with the following patch

--- ../_clean/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c  2014-05-10
23:16:48.0 +0200
+++ gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c2016-09-24
17:03:58.0 +0200
@@ -24,7 +24,7 @@ void foo(void) {
   s0 = s1;
 }

-/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
-/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
 /* { dg-final { scan-assembler
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space
4\n\t.quad\t.*\n\t.quad\t4\n" { target { *-*-darwin* && {  lp64 } } } } } */
 /* { dg-final { scan-assembler
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space
4\n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && {  lp64 } } } } } */
--- ../_clean/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C  2014-05-10
23:18:01.0 +0200
+++ gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C2016-09-24
17:02:39.0 +0200
@@ -24,7 +24,7 @@ void foo(void) {
   s0 = s1;
 }

-/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
-/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target {
*-*-darwin* && { ! lp64 } } } } } */
 /* { dg-final { scan-assembler
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space
4\n\t.quad\t.*\n\t.quad\t4\n" { target { *-*-darwin* && {  lp64 } } } } } */
 /* { dg-final { scan-assembler
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space
4\n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && {  lp64 } } } } } */

I don't know if the replacement of LC with lC is really intended and if yes, a
better fix would be to use "-mtarget-linker 85.2".

[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

[olegendo at gcc dot gnu.org]

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

--- Comment #87 from Oleg Endo  ---
Author: olegendo
Date: Sun Sep 25 06:59:37 2016
New Revision: 240471

URL: https://gcc.gnu.org/viewcvs?rev=240471=gcc=rev
Log:
This fixes a fallout that actually goes back to 5.0 but went unnoticed.
The costs for movt and movrt type of insns were not correctly reported
and ifcvt thus made some bad choices for SH.  A new cset_zero pattern
variant is also required to fix the matching for some recent changes
in the middle end.

gcc/
PR target/51244
* config/sh/sh.c (sh_movt_set_dest, sh_movrt_set_dest): Add overloads.
(sh_rtx_costs): Handle SET of movt and movrt patterns.
* cnofig/sh/sh-protos.h (sh_movt_set_dest, sh_movrt_set_dest): Forward
declare new overloads.
* config/sh/sh.md (*cset_zero): Add variant that takes a treg_set_expr
operand.

gcc/testsuite/
PR target/51244
* gcc.target/sh/pr51244-11.c: Add more detailed expected insn matching.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-protos.h
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr51244-11.c

[Bug rtl-optimization/77714] Wrong code generation for gcc.c-torture/execute/pr51447.c

[edlinger at gcc dot gnu.org]

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

--- Comment #3 from Bernd Edlinger  ---
because a different pattern is choosen for this insn
the reg-note is overwritten here:

 Choosing alt 2 in insn 48:  (0) l  (1) l  (2) lL {*thumb1_addsi3}
  Creating newreg=129, assigning class LO_REGS to r129
   48: sfp:SI=r7:SI+r129:SI
  REG_EQUAL r7:SI+r129:SI
Inserting insn reload before:
   82: r129:SI=0xfff0

but it should be:

 Choosing alt 2 in insn 48:  (0) l  (1) l  (2) lL {*thumb1_addsi3}
  Creating newreg=129, assigning class LO_REGS to r129
   48: sfp:SI=r7:SI+r129:SI
  REG_EQUAL r7:SI-0x10
Inserting insn reload before:
   82: r129:SI=0xfff0

and in the next pass this insn is removed because the reg-note
is no longer found.


The reason is the alias between the reg-note and the SET_SRC.
So this would be a more conservative fix:


Index: lra-eliminations.c
===
--- lra-eliminations.c  (revision 240437)
+++ lra-eliminations.c  (working copy)
@@ -981,7 +981,7 @@ eliminate_regs_in_insn (rtx_insn *insn, bool repla
  }
lra_update_insn_recog_data (insn);
/* Add offset note for future updates.  */
-   add_reg_note (insn, REG_EQUAL, src);
+   add_reg_note (insn, REG_EQUAL, copy_rtx (src));
return;
  }
  }