[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-09
 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
I am testing a patch.

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #13 from Jeffrey A. Law  ---
Richard Sandiford's patch  fixed this issue and Uros removed rth's hacks. 
Closing.

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[anlauf at gmx dot de]

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

--- Comment #8 from Harald Anlauf  ---
Proposed patch posted here:

https://gcc.gnu.org/ml/fortran/2016-02/msg00026.html

[Bug target/69738] New: PowerPC built-in __builtin_addg6s should be enabled on 64-bit

[meissner at gcc dot gnu.org]

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

Bug ID: 69738
   Summary: PowerPC built-in __builtin_addg6s should be enabled on
64-bit
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The __builtin_addg6s function is listed as 32-bit, but it should be enabled for
64-bit.

[Bug other/69554] [6 Regression] Multi-location diagnostics writes too many lines

[dmalcolm at gcc dot gnu.org]

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

--- Comment #17 from David Malcolm  ---
Candidate patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00646.html

[Bug c++/69730] problem with references and templates when using O2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
I wonder if it would be possible to warn about this.  -Wreturn-local-addr does
not trigger because the reference is ok. It is the object which is temporary,
but that may be hard to detect.

[Bug target/68532] [ARM] Incorrect code result on arm big endian

[cbaylis at gcc dot gnu.org]

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

--- Comment #4 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Tue Feb  9 18:49:05 2016
New Revision: 233252

URL: https://gcc.gnu.org/viewcvs?rev=233252=gcc=rev
Log:
[ARM] PR68532 Fix up vzip recognition for big endian

gcc/ChangeLog:

2016-02-09  Charles Baylis  

PR target/68532
* config/arm/arm.c (arm_evpc_neon_vzip): Allow for big endian lane
order.
* config/arm/arm_neon.h (vzipq_s8): Adjust shuffle patterns for big
endian.
(vzipq_s16): Likewise.
(vzipq_s32): Likewise.
(vzipq_f32): Likewise.
(vzipq_u8): Likewise.
(vzipq_u16): Likewise.
(vzipq_u32): Likewise.
(vzipq_p8): Likewise.
(vzipq_p16): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm_neon.h

[Bug target/68532] [ARM] Incorrect code result on arm big endian

[cbaylis at gcc dot gnu.org]

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

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from cbaylis at gcc dot gnu.org ---
Fixed by these patches

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00630.html
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00632.html

[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #16 from Jeffrey A. Law  ---
I verified Bernd's committed patch fixes the issue (by going back to a Dec
compiler to reproduce the runtime failure, then applying Bernd's patch and
verifying the runtime behaviour is correct).  Closing...

[Bug c++/69723] pre-post-increment/decrement and reading the same variable that is assigned should not be considered uses for Wunused-but-set-variable

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #7)
> As for the missed -Wuninitialized at -O0, wonder if we couldn't do something
> about it for GCC 7.

Sounds good to me, but perhaps it is better to open a new PR. This one is a bit
messy (and closed as a duplicate).

[Bug target/68532] [ARM] Incorrect code result on arm big endian

[cbaylis at gcc dot gnu.org]

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

--- Comment #3 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Tue Feb  9 18:47:55 2016
New Revision: 233251

URL: https://gcc.gnu.org/viewcvs?rev=233251=gcc=rev
Log:
[ARM] PR68532: Fix up vuzp for big endian

gcc/ChangeLog:

2016-02-09  Charles Baylis  

   PR target/68532
   * config/arm/arm.c (neon_endian_lane_map): New function.
   (neon_vector_pair_endian_lane_map): New function.
   (arm_evpc_neon_vuzp): Allow for big endian lane order.
   * config/arm/arm_neon.h (vuzpq_s8): Adjust shuffle patterns for big
   endian.
   (vuzpq_s16): Likewise.
   (vuzpq_s32): Likewise.
   (vuzpq_f32): Likewise.
   (vuzpq_u8): Likewise.
   (vuzpq_u16): Likewise.
   (vuzpq_u32): Likewise.
   (vuzpq_p8): Likewise.
   (vuzpq_p16): Likewise.

gcc/testsuite/ChangeLog:
2016-02-09  Charles Baylis  

   PR target/68532
   * gcc.c-torture/execute/pr68532.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68532.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm_neon.h
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/69725] profiledbootstrap failure due to unsats for isl functions

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I wondered if the system ISL (isl-0.14-4.fc23) was being picked up instead of
the one in my tree (isl-0.15), or some combination of both at different times. 
So I tried --with-isl thinking that might be enough to avoid a potential mixup
but the errors are the same as in the comment #0.

I then tried reconfiguring --without-isl expecting it to disable Graphite and
thus obviate the need to use ISL for anything but got a different error this
time (see below).  But since this was still with the isl/ directory in my tree,
I then removed the directory and redid the same step again, with the same
errors:

$ /src/gcc/trunk/configure --enable-languages=c,c++,fortran,go,lto,obj-c++
--enable-checking=release --without-isl
...
$ make -j10 BOOT_CFLAGS='-O2 -flto -fuse-linker-plugin' profiledbootstrap
...
checking for __gmpz_init in -lgmp... no
configure: error: libgmp not found or uses a different ABI.
Please read the INSTALL file -- see "In case of problem".
Makefile:5929: recipe for target 'configure-stageprofile-mpfr' failed
make[2]: *** [configure-stageprofile-mpfr] Error 1
make[2]: Leaving directory '/home/msebor/build/gcc-trunk-profiledbootstrap'
Makefile:26140: recipe for target 'stageprofile-bubble' failed
make[1]: *** [stageprofile-bubble] Error 2
make[1]: Leaving directory '/home/msebor/build/gcc-trunk-profiledbootstrap'
Makefile:26308: recipe for target 'profiledbootstrap' failed
make: *** [profiledbootstrap] Error 2

[Bug c++/69736] [4.9/5/6 Regression] "error: too few arguments to function" in c++14 but not c++11

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
In some contexts yes, but 5.1.1 [expr.prim.general] p6 says:

  A parenthesized expression is a primary expression whose type and value are
  identical to those of the enclosed expression. The presence of parentheses
  does not affect whether the expression is an lvalue. The parenthesized
  expression can be used in exactly the same contexts as those where the
  enclosed expression can be used, and with the same meaning, except as
  otherwise indicated.

I don't see anything indicating otherwise in [conf.func] or [expr.call] or
[dcl.fct.default].

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Mon, 8 Feb 2016, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
> 
> --- Comment #23 from Jeffrey A. Law  ---
> I don't think it's worth the effort to try and keep that list sorted.  I think
> we can get what we want with a single walk over the IL just before 
> coalescing. 
>  That addresses the stability issue.
> 
> Then we will obviously want to look at whether or not there's something we're
> missing in the coalescer.  Maybe there's a reasonable tie-breaker that needs 
> to
> be added or some such. But until we have stability in the coalescing phase,
> it's rather pointless to spend much effort on the coalescing algorithm as the
> results may easily be skewed by the instabilities.

Well, the results are only skewed for equal cost candidates due to SSA 
name allocation instabilities.  If we'd address this bug properly the
important case to catch would have a higher cost.

[Bug c++/69731] New: Inconsistent SFINAE in interaction with variable templates

[lucdanton at free dot fr]

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

Bug ID: 69731
   Summary: Inconsistent SFINAE in interaction with variable
templates
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

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

It appears that GCC behaves differently depending on how SFINAE is performed
(e.g. how a trait is written), and how a trait is used(!) at the constraint
site (using regular enable_if_t techniques). In one particular case one of the
techniques loops until the instantiation limit depth is reached, but only if
the
short form is used on the site. Regardless of what /should/ happen (which I
have no idea about), I believe GCC should consistently either loop or
terminate.
For what it's worth Clang accepts all cases for both forms.

I am using 6.0.0 20160208, the testcase is compiled with alternatively:
g++-trunk -std=c++1z -DSHORT testcase.cpp
g++-trunk -std=c++1z testcase.cpp

The first command results in constraints that use trait_v variable
templates
and succeeds. The second command results in constraints that use the
trait::value static members and hits the limit.

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #8 from Dominik Vogt  ---
gfortran.dg/coarray_allocate_3.f08 crashed with an invalid free() on s390 and
s390x.

(gdb) run
Starting program: .../gcc/build/gcc/testsuite/coarray_allocate_3.exe 

Program received signal SIGSEGV, Segmentation fault.
0x03fff7cb6814 in free () from /lib64/libc.so.6
(gdb) bt
#0  0x03fff7cb6814 in free () from /lib64/libc.so.6
#1  0x8cae in MAIN__ ()
at .../gcc/testsuite/gfortran.dg/coarray_allocate_3.f08:26
#2  main (argc=, argv=)
at .../gcc/testsuite/gfortran.dg/coarray_allocate_3.f08:27
#3  0x03fff7c4e0a2 in __libc_start_main () from /lib64/libc.so.6
#4  0x8866 in _start ()

[Bug libstdc++/68515] std::result_of<F(X)> doesn't work when F is abstract (with pure virtual functions)

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
FWIW, I don't see a bug here. The note in [temp.deduct]/8 explicitly calls out
"Attempting to create a function type in which a parameter type or the return
type is an abstract class type" as a cause for deduction failure. What one
plans to do with the type is irrelevant; deduction fails as soon as you attempt
to form one.

In any event, the only reason this is an issue for the original example is
because it uses result_of incorrectly. The actual call is 'f(x[i])' - i.e., it
is calling a const F lvalue with the result of vector's const operator[], which
returns 'typename vector::const_reference' (which is const T& except for
vector). The correct result_of invocation is therefore 'typename
std::result_of::const_reference)>::type'
(which should probably be then decayed since the example creates a vector of
it).

[Bug libstdc++/68515] std::result_of<F(X)> doesn't work when F is abstract (with pure virtual functions)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
Yes, the function type is definitely invalid. And you're right that the
result_of usage is wrong: if you can't create an object of the abstract type
then you also can't invoke it, so the result_of should always use const F& or
F&& or some reference type.

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> gfortran.dg/coarray_allocate_3.f08 crashed with an invalid free()
> on s390 and s390x.

If the test is compiled with -fsanitize=address, I get

==19013==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00010ef2e1d8 at pc 0x00010ef2d1dd bp 0x7fff50cd32f0 sp 0x7fff50cd32e8
WRITE of size 8 at 0x00010ef2e1d8 thread T0
#0 0x10ef2d1dc in MAIN__ (a.out+0x111dc)
#1 0x10ef2d79e in main (a.out+0x1179e)
#2 0x7fff8c7695ac in start (libdyld.dylib+0x35ac)
#3 0x0  ()

0x00010ef2e1d8 is located 0 bytes to the right of global variable
'some_local_object' defined in
'/opt/gcc/_clean/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08:15'
(0x10ef2e1a0) of size 56
SUMMARY: AddressSanitizer: global-buffer-overflow (a.out+0x111dc) in MAIN__
Shadow bytes around the buggy address:
  0x100021de5be0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
  0x100021de5c20: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 f9 f9
=>0x100021de5c30: f9 f9 f9 f9 00 00 00 00 00 00 00[f9]f9 f9 f9 f9
  0x100021de5c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100021de5c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...

[Bug tree-optimization/69726] [6 Regression] Bogus warnings with -O3 -Wuninitialized because dead code after if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
Summary|Bogus warnings with -O3 |[6 Regression] Bogus
   |-Wuninitialized because |warnings with -O3
   |dead code after |-Wuninitialized because
   |if-conversion   |dead code after
   ||if-conversion

[Bug bootstrap/69725] profiledbootstrap failure due to unsats for isl functions

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Not sure if LTO bootstrap with in-tree ISL is properly tested.  Which ISL
version
did you choose?  Anything suspicious in closure.c?

[Bug middle-end/69729] [6 regression] [CHKP] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from vries at gcc dot gnu.org ---
patch with test-cases committed, marking resolved-fixed.

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Feb  9 08:52:26 2016
New Revision: 233240

URL: https://gcc.gnu.org/viewcvs?rev=233240=gcc=rev
Log:
Fix GOMP/GOACC_parallel optimization in ipa-pta

2016-02-09  Tom de Vries  

PR tree-optimization/69599
* tree-ssa-structalias.c (fndecl_maybe_in_other_partition): New
function.
(find_func_aliases_for_builtin_call, find_func_clobbers)
(ipa_pta_execute):  Handle case that foo and foo._0 are not in same lto
partition.

* testsuite/libgomp.c/omp-nested-3.c: New test.
* testsuite/libgomp.c/pr46032-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/kernels-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/parallel-2.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/omp-nested-3.c
trunk/libgomp/testsuite/libgomp.c/pr46032-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c
trunk/libgomp/ChangeLog

[Bug other/69722] [6 Regression] gcc/doc/extend.texi:7526: warning: node `Constraints' is next for `Extended Asm' in menu but not in sectioning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug c++/69730] problem with references and templates when using O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
I suspect it's because x() returns an rvalue B (a copy) which you then instruct
to
return a reference to its member which you bind to x.  But that copy of B dies
after

const double & x = a.x().value();

and thus the content of what x refers to is gone.

[Bug c++/69730] New: problem with references and templates when using O2

[prevot at cervval dot com]

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

Bug ID: 69730
   Summary: problem with references and templates when using O2
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prevot at cervval dot com
  Target Milestone: ---

Created attachment 37640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37640=edit
sample code to trigger the bug

This is kind of hard to describe, so I will refer to the code sample.

Compiling with "g++ -o bug_gcc bug_gcc.cpp && ./bug_gcc" gives the expected
result (outputs twice 0.1), but compiling with "g++ -o bug_gcc -O2 bug_gcc.cpp
&& ./bug_gcc" gives a wrong result (second value is 0).

As a side note compiling with "g++ -o bug_gcc -O2 -fsanitize=undefined
bug_gcc.cpp && ./bug_gcc" gives the expected result.

Version details:
On archlinux using multilib/gcc-multilib 5.3.0-3

$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux prevot 4.3.3-3-ARCH #1 SMP PREEMPT Wed Jan 20 08:12:23 CET 2016 x86_64
GNU/Linux

As I don't know how to exactly describe this bug, sorry if this is a
duplicate...

[Bug middle-end/69729] New: [6 regression] [CHKP] internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

Bug ID: 69729
   Summary: [6 regression] [CHKP] internal compiler error:
Segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Here is a test which fails when compiled with both LTO and CHKP enabled:

>cat test.i
class cl1
{
 public:
  virtual ~cl1();
};

class cl2
{
 public:
  virtual ~cl2();
};

class cl3 : cl1, cl2
{
};

class cl4 : cl3
{
  ~cl4();
};

cl4::~cl4 ()
{
}
>g++ -fcheck-pointer-bounds -mmpx -flto -flto-partition=max -shared -fPIC test.i
lto1: internal compiler error: Segmentation fault
0xccfd22 crash_signal
/export/users/ienkovic/issues/mpx/gcc/gcc/toplev.c:335
0x3b21c3567f ???
   
/home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7cfabd cgraph_node::get_untransformed_body()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraph.c:3326
0x7da835 cgraph_node::expand_thunk(bool, bool)
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphunit.c:1604
0x7dbf1f cgraph_node::assemble_thunks_and_aliases()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphunit.c:1906
0x7dbfc9 cgraph_node::assemble_thunks_and_aliases()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphunit.c:1924
0x7dc584 cgraph_node::expand()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphunit.c:2036
0x7dcc44 output_in_order
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphunit.c:2211
0x7dd310 symbol_table::compile()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphunit.c:2459
0x7183f3 lto_main()
/export/users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:3327
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /export/users/ienkovic/issues/mpx/gcc-build/bin/g++
returned 1 exit status
compilation terminated.
/gnumnt/msticlxl7_users/ienkovic/binutils-gdb-build/bin/ld: error: lto-wrapper
failed
collect2: error: ld returned 1 exit status

Regression starts from r232551

[Bug tree-optimization/69726] [6 Regression] Bogus warnings with -O3 -Wuninitialized because dead code after if-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
It solved itself with

2016-02-08  Richard Biener  

PR tree-optimization/69719
* tree-vect-data-refs.c (vect_prune_runtime_alias_test_list):
Properly use absolute of the difference of the two offsets to
compare or adjust the segment length.

and no longer vectorizing (too many versioning for alias checks - another
missed optimization).

The following patch would have avoided the warning:

Index: gcc/tree-ssa-uninit.c
===
--- gcc/tree-ssa-uninit.c   (revision 233239)
+++ gcc/tree-ssa-uninit.c   (working copy)
@@ -231,6 +231,24 @@ warn_uninitialized_vars (bool warn_possi
  || is_global_var (base))
continue;

+ /* Do not confuse ourselves with dead code.  See PR69726.  */
+ bool dont_warn = false;
+ gimple *use_stmt = stmt;
+ use_operand_p use_p;
+ tree lhs;
+ do
+   {
+ lhs = gimple_assign_lhs (use_stmt);
+ if (TREE_CODE (lhs) != SSA_NAME)
+   break;
+ if (has_zero_uses (lhs))
+   {
+ dont_warn = true;
+ continue;
+   }
+   }
+ while (single_imm_use (lhs, _p, _stmt));
+
  if (always_executed)
warn_uninit (OPT_Wuninitialized, use,
 gimple_assign_rhs1 (stmt), base,

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[amker at gcc dot gnu.org]

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

--- Comment #15 from amker at gcc dot gnu.org ---
Though the previous patch can work, I am testing another patch less intrusive.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

--- Comment #11 from Václav Zeman  ---
Created attachment 37638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37638=edit
logs of compilation with -fno-lto

(In reply to H.J. Lu from comment #8)
> Your compiler doesn't have proper LTO support.  Please turn it
> off with -fno-lto.

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #13 from Markus Trippelsdorf  ---
Created attachment 37639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37639=edit
reduced testcase

With today's trunk I've hit the ICE in the boost testsuite:

 % g++ -c -w -mcpu=power8 -O3 -mlra test_fixed_containers.ii
test_fixed_containers.ii: In function ‘void test_matrix(std::B) [with T =
std::complex]’:
test_fixed_containers.ii:203:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 1206 1205 1207 2 (set (reg:DI 108 31)
(reg:DI 9 9 [970])) test_fixed_containers.ii:171 540
{*movdi_internal64}
 (expr_list:REG_DEAD (reg:DI 9 9 [970])
(nil)))
test_fixed_containers.ii:203:1: internal compiler error: in
extract_constrain_insn, at recog.c:2190

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||powerpc64
   Target Milestone|--- |6.0
Summary|ICE in profiledbootstrap in |[6 Regression] ICE in
   |reg_save_code at|profiledbootstrap in
   |../../gcc/caller-save.c:141 |reg_save_code at
   ||../../gcc/caller-save.c:141

[Bug tree-optimization/69726] Bogus warnings with -O3 -Wuninitialized because of if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-09
 CC||rguenth at gcc dot gnu.org
Summary|Bogus warnings with -O3 |Bogus warnings with -O3
   |-Wuninitialized |-Wuninitialized because of
   ||if-conversion
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So at uninit time we have

  :
  vect__117.6_137 = MEM[(const int32_t *)block_8(D) + 32B];
  vect__118.9_138 = MEM[(const int32_t *)block_8(D) + 64B];
  vect__119.10_139 = vect__117.6_137 | vect__118.9_138;
  vect__120.13_140 = MEM[(const int32_t *)block_8(D) + 96B];
  vect__121.14_141 = vect__119.10_139 | vect__120.13_140;
  vect__122.17_142 = MEM[(const int32_t *)block_8(D) + 128B];
  vect__123.18_143 = vect__121.14_141 | vect__122.17_142;
  vect__124.21_144 = MEM[(const int32_t *)block_8(D) + 160B];
  vect__125.22_145 = vect__123.18_143 | vect__124.21_144;
  vect__126.25_146 = MEM[(const int32_t *)block_8(D) + 192B];
  vect__127.26_147 = vect__125.22_145 | vect__126.25_146;
  vect__128.29_148 = MEM[(const int32_t *)block_8(D) + 224B];
  vect__129.30_149 = vect__127.26_147 | vect__128.29_148;
  vect__130.33_150 = MEM[(const int32_t *)block_8(D)];
  vect__ifc__525.36_152 = MEM[(int *) + 224B];
  vect__ifc__523.38_154 = VEC_COND_EXPR ;
  vect__ifc__522.43_157 = MEM[(int *) + 192B];
  vect__ifc__520.45_159 = VEC_COND_EXPR ;
  vect__ifc__519.50_499 = MEM[(int *) + 160B];
  vect__ifc__517.52_161 = VEC_COND_EXPR ;
  vect__ifc__516.57_497 = MEM[(int *) + 128B];
  vect__ifc__514.59_163 = VEC_COND_EXPR ;
  vect__ifc__513.64_495 = MEM[(int *) + 96B];
  vect__ifc__511.66_493 = VEC_COND_EXPR ;
  vect__ifc__510.71_492 = MEM[(int *) + 64B];
  vect__ifc__508.73_486 = VEC_COND_EXPR ;
  vect__ifc__507.78_484 = MEM[(int *) + 32B];
...

which means they are used conditional on vect__129.30_149 != { 0, 0, 0, 0 }.

But temp itself is never initialized.

This is caused by if-conversion which transforms

  :
  # i_199 = PHI 
  # ivtmp_624 = PHI 
  _6 = (long unsigned int) i_199;
  _7 = _6 * 4;
  _9 = block_8(D) + _7;
  _10 =  + _7;
  _117 = MEM[(const int32_t *)_9 + 32B];
  _118 = MEM[(const int32_t *)_9 + 64B];
  _119 = _117 | _118;
  _120 = MEM[(const int32_t *)_9 + 96B];
  _121 = _119 | _120;
  _122 = MEM[(const int32_t *)_9 + 128B];
  _123 = _121 | _122;
  _124 = MEM[(const int32_t *)_9 + 160B];
  _125 = _123 | _124;
  _126 = MEM[(const int32_t *)_9 + 192B];
  _127 = _125 | _126;
  _128 = MEM[(const int32_t *)_9 + 224B];
  _129 = _127 | _128;
  if (_129 == 0)
goto ;
  else
goto ;

  :
  _130 = MEM[(const int32_t *)_9];
  MEM[(int *)_10 + 224B] = _130;
  MEM[(int *)_10 + 192B] = _130;
  MEM[(int *)_10 + 160B] = _130;
  MEM[(int *)_10 + 128B] = _130;
  MEM[(int *)_10 + 96B] = _130;
  MEM[(int *)_10 + 64B] = _130;
  MEM[(int *)_10 + 32B] = _130;
  MEM[(int *)][i_199] = _130;
  goto ;

  :
  _131 = MEM[(const int32_t *)_9];
  a0_132 = _122 + _131;
  a1_133 = _131 - _122;
  a2_134 = _118 + _126;
  _135 = _118 - _126;
  _136 = _135 * 2896;
  a3_137 = _136 >> 11;
  a4_138 = _120 + _124;
  a5_139 = _124 - _120;
  a6_140 = _117 + _128;
  a7_141 = _117 - _128;
  b0_142 = a4_138 + a6_140;
  _143 = a5_139 + a7_141;
  _144 = _143 * 3784;
  b1_145 = _144 >> 11;
  _146 = a5_139 * -5352;
  _147 = _146 >> 11;
  _148 = _147 - b0_142;
  b2_149 = b1_145 + _148;
  _150 = a6_140 - a4_138;
  _151 = _150 * 2896;
  _152 = _151 >> 11;
  b3_153 = _152 - b2_149;
  _154 = a7_141 * 2217;
  _155 = _154 >> 11;
  _156 = b3_153 + _155;
  b4_157 = _156 - b1_145;
  _158 = a0_132 + a2_134;
  _159 = b0_142 + _158;
  MEM[(int *)][i_199] = _159;
  _160 = a1_133 + a3_137;
  _161 = _160 - a2_134;
  _162 = b2_149 + _161;
  MEM[(int *)_10 + 32B] = _162;
  _163 = a1_133 - a3_137;
  _164 = a2_134 + _163;
  _165 = b3_153 + _164;
  MEM[(int *)_10 + 64B] = _165;
  _166 = a0_132 - a2_134;
  _167 = _166 - b4_157;
  MEM[(int *)_10 + 96B] = _167;
  _168 = b4_157 + _166;
  MEM[(int *)_10 + 128B] = _168;
  _169 = _164 - b3_153;
  MEM[(int *)_10 + 160B] = _169;
  _170 = _161 - b2_149;
  MEM[(int *)_10 + 192B] = _170;
  _171 = _158 - b0_142;
  MEM[(int *)_10 + 224B] = _171;

  :
  i_12 = i_199 + 1;
  ivtmp_623 = ivtmp_624 - 1;
  if (ivtmp_623 != 0)
goto ;
  else
goto ;

  :
  goto ;

into

  :
  # i_199 = PHI 
  # ivtmp_624 = PHI 
  _6 = (long unsigned int) i_199;
  _7 = _6 * 4;
  _9 = block_8(D) + _7;
  _10 =  + _7;
  _117 = MEM[(const int32_t *)_9 + 32B];
  _118 = MEM[(const 

[Bug tree-optimization/69726] Bogus warnings with -O3 -Wuninitialized because of if-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Ok, so forwprop fixes things up but nothing removes dead code before uninit
and it is confused by

  vect__ifc__525.36_152 = MEM[(int *) + 224B];
  vect__ifc__523.38_154 = VEC_COND_EXPR ;

where only _154 is dead.  That's forwprop not cleaning up after itself (it
is not expected to do that).

[Bug tree-optimization/69728] New: [6 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[ktkachov at gcc dot gnu.org]

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

Bug ID: 69728
   Summary: [6 Regression] internal compiler error: in
outer_projection_mupa, at graphite-sese-to-poly.c:1175
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: spop at gcc dot gnu.org
  Target Milestone: ---

The following testcase ICEs for me on aarch64 with -O3 -floop-interchange.

int a[1];
int b, c, d, e;
void
fn1 ()
{
  d = 9;
  for (; c; c++)
{
  ++d;
  b = 8;
  for (; b; b--)
{
  if (d)
break;
  a[b] = e;
}
}
}

mycrash.c:4:1: internal compiler error: in outer_projection_mupa, at
graphite-sese-to-poly.c:1175
 fn1 ()
 ^~~
0x1068f68 outer_projection_mupa
$SRC/gcc/graphite-sese-to-poly.c:1175
0x1068f68 add_loop_schedule
$SRC/gcc/graphite-sese-to-poly.c:1223
0x106af92 build_schedule_loop
$SRC/gcc/graphite-sese-to-poly.c:1263
0x106aeae build_schedule_loop_nest
$SRC/gcc/graphite-sese-to-poly.c:1319
0x106af71 build_schedule_loop
$SRC/gcc/graphite-sese-to-poly.c:1257
0x106aeae build_schedule_loop_nest
$SRC/gcc/graphite-sese-to-poly.c:1319
0x106bd2f build_original_schedule
$SRC/gcc/graphite-sese-to-poly.c:1337
0x106bd2f build_poly_scop(scop*)
$SRC/gcc/graphite-sese-to-poly.c:1368
0x105582c graphite_transform_loops()
$SRC/gcc/graphite.c:319
0x10559a4 graphite_transforms
$SRC/gcc/graphite.c:356
0x10559a4 execute
$SRC/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This is with ISL 0.15

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt  ---
I.e. free(0x1) is called:

Load foobar.1497 to r12

   0x8998 <+40>:larl%r12,0x80002408 

   (gdb) p /x $r12
   0x80002408

First malloc call, store mem pointer in foobar.1497

   0x89c6 <+86>:brasl   %r14,0x8788 
   0x89cc <+92>:stg %r2,0(%r12)

Second malloc call, store mem pointer in some_local_object.1511

   0x8ae8 <+376>:   brasl   %r14,0x8788 
   0x8aee <+382>:   stgrl   %r2,0x800023d0 

Load address of some_local_object.1511 to r1

   0x8afa <+394>:   larl%r1,0x800023d0 

Write something to r1 + 16, r1 + 32, r1 + 40, r1 + 24

   0x8b00 <+400>:   mvghi   16(%r1),297
   0x8b06 <+406>:   stg %r11,32(%r1)
   0x8b0c <+412>:   stg %r8,40(%r1)
   0x8b12 <+418>:   mvghi   24(%r1),1

This overwrites foobar.1497 with the value 1:

   0x8b18 <+424>:   mvghi   56(%r1),1

   (gdb) p /x $r1 + 56
   0x80002408   <-- address of foobar.1497

[Bug middle-end/69715] [4.9/5 regression] ICE: in store_bit_field_1, at expmed.c:839

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 regression] ICE:   |[4.9/5 regression] ICE: in
   |in store_bit_field_1, at|store_bit_field_1, at
   |expmed.c:839|expmed.c:839
  Known to fail|6.0 |

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Feb  9 08:35:22 2016
New Revision: 233239

URL: https://gcc.gnu.org/viewcvs?rev=233239=gcc=rev
Log:
2016-02-09  Richard Biener  

PR tree-optimization/69715
* tree-ssa.c (execute_update_addresses_taken): Mark non-decl
LHS on calls as non-rewritable.

* gcc.dg/torture/pr69715.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69715.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug middle-end/69715] [4.9/5 regression] ICE: in store_bit_field_1, at expmed.c:839

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 regression] ICE:   |[4.9/5 regression] ICE: in
   |in store_bit_field_1, at|store_bit_field_1, at
   |expmed.c:839|expmed.c:839
  Known to fail|6.0 |

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Feb  9 08:35:22 2016
New Revision: 233239

URL: https://gcc.gnu.org/viewcvs?rev=233239=gcc=rev
Log:
2016-02-09  Richard Biener  

PR tree-optimization/69715
* tree-ssa.c (execute_update_addresses_taken): Mark non-decl
LHS on calls as non-rewritable.

* gcc.dg/torture/pr69715.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69715.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug tree-optimization/69732] [6 Regression] Missed vectorization due to failed dependence analysis

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|Missed vectorization due to |[6 Regression] Missed
   |failed dependence analysis  |vectorization due to failed
   ||dependence analysis

--- Comment #1 from Richard Biener  ---
This is a regression due to a fix for alias check merging.

[Bug c++/69733] New: -Wignored-qualifiers points to wrong const

[trippels at gcc dot gnu.org]

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

Bug ID: 69733
   Summary: -Wignored-qualifiers points to wrong const
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat const.ii
class A {
 private:
   double val;
 public:
   const double value() const {return val;}
};

markus@x4 tmp % clang++ -c -Wall -Wextra const.ii
const.ii:5:4: warning: 'const' type qualifier on return type has no effect
[-Wignored-qualifiers]
   const double value() const {return val;}
   ^~
1 warning generated.

markus@x4 tmp % icpc -c -Wall -Wextra const.ii
const.ii(5): warning #858: type qualifier on return type is meaningless
 const double value() const {return val;}
 ^

markus@x4 tmp % g++ -c -Wall -Wextra const.ii
const.ii:5:25: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
const double value() const {return val;}
 ^

[Bug tree-optimization/69732] New: Missed vectorization due to failed dependence analysis

[rguenth at gcc dot gnu.org]

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

Bug ID: 69732
   Summary: Missed vectorization due to failed dependence analysis
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We now fail to vectorize the testcase in PR69726 which exhibits the pattern

 p = [i];
 *(p + 0) = ...
 *(p + 1) = ...
 *(p + 2) = ...
...

where p is forward-propagated into *(p + 0) only, leading to

 a[i] = ...
 *(p + 1) = ...
...

which then results in

base_address: 
offset from base address: 0
constant offset from base address: 0
step: 32
aligned to: 128
base_object: temp
Access function 0: {0, +, 8}_2

vs.

base_address: 
offset from base address: 0
constant offset from base address: 16
step: 32
aligned to: 128
base_object: MEM[(int *)]
Access function 0: {16B, +, 32}_2

which have different base objects and thus are not handled by dependence
analysis.  This results in bogus runtime alias checks.

[Bug tree-optimization/69732] [6 Regression] Missed vectorization due to failed dependence analysis

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-09
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug libgomp/69625] S/390 deadlock in libgomp.c/doacross-1.c test (vararg function trashes r6)

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #3 from Dominik Vogt  ---
Fixed with above patch.

[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|Weird clash with same names |[6 Regression] Weird clash
   |in different scopes |with same names in
   ||different scopes

--- Comment #33 from Jakub Jelinek  ---
So, with

#include 

template  class A {
  struct B { long exp; };
  void m_fn1();
};

template  void A::m_fn1() {
  long insert_exp = 1;
  B q;
  (q->exp < insert_exp);
}

we now have a regression from 5 to 6, right?

[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes

[redi at gcc dot gnu.org]

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

--- Comment #34 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #33)
> we now have a regression from 5 to 6, right?

Right.

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[amker at gcc dot gnu.org]

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

--- Comment #12 from amker at gcc dot gnu.org ---
Patch sent for review at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00612.html
It works for the reduced test case, could you please help me to check if it
works for you original case?
Thanks,
bin

[Bug c++/69723] pre-post-increment/decrement and reading the same variable that is assigned should not be considered uses for Wunused-but-set-variable

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
As for the missed -Wuninitialized at -O0, wonder if we couldn't do something
about it for GCC 7.

volatile int v;
void bar (void)
{
  int x;
  v++;
  for (; x < 100; x++) v++;
  v++;
}

Here, we have
  # x_1 = PHI 
  if (x_1 <= 99)
in an always_executed basic block, normally we don't look at PHIs in the early
uninit pass at all, but wonder if for always_executed bbs we couldn't make an
exception - if the uninited value is from the immediate dominator of the bb and
the PHI result is used in an always_executed basic block, it IMHO means a clear
case where the use is always uninitialized (if the function is ever called, but
other must uninitialized warnings are making the same assumption).

[Bug tree-optimization/69735] New: [6 Regression] internal compiler error: in harmful_loop_in_region, at graphite-scop-detection.c:1045

[ktkachov at gcc dot gnu.org]

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

Bug ID: 69735
   Summary: [6 Regression] internal compiler error: in
harmful_loop_in_region, at
graphite-scop-detection.c:1045
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: spop at gcc dot gnu.org
  Target Milestone: ---

The following testcase ICEs on aarch64 with -O3 -floop-interchange:
int a[1], d[1];
int b, c, e, f, g, h;
void
fn1 ()
{
  if (g)
{
  for (; e; e++)
a[e] = 6;
  for (; f; f++)
{
  b = 0;
  for (; b <= 1; b++)
h = d[b];
}
  c = 5;
}
  for (;;)
;
}

mycrash.c:4:1: internal compiler error: in harmful_loop_in_region, at
graphite-scop-detection.c:1045
 fn1 ()
 ^~~
0x10670f4 harmful_loop_in_region
$SRC/gcc/graphite-scop-detection.c:1045
0x10670f4 merge_sese
$SRC/gcc/graphite-scop-detection.c:849
0x10678b1 build_scop_breadth
$SRC/gcc/graphite-scop-detection.c:902
0x10678b1 build_scop_depth
$SRC/gcc/graphite-scop-detection.c:880
0x1067872 build_scop_depth
$SRC/gcc/graphite-scop-detection.c:873
0x106782a build_scop_depth
$SRC/gcc/graphite-scop-detection.c:866
0x1067fa0 build_scops(vec*)
$SRC/gcc/graphite-scop-detection.c:2000
0x105590d graphite_transform_loops()
$SRC/gcc/graphite.c:307
0x1055988 graphite_transforms
$SRC/gcc/graphite.c:356
0x1055988 execute
$SRC/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I'm using ISL 0.15.

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 37645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37645=edit
caller-save.ii.bz2

caller-save.ii.bz2

[Bug c++/59627] ICE with OpenMP "declare reduction" and -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vries at gcc dot gnu.org ---
Do we consider porting this to 4.9/5 branches, or are we done here?

[Bug target/69614] [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #11 from ktkachov at gcc dot gnu.org ---
I think this is a regalloc bug.
I tried reducing the number of RTL passes needed to trigger this and I can
disable pretty much every disable-able post-reload pass and still trigger this.
So the bug still triggers with:
-Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame
-fira-algorithm=priority -march=armv7-a -mfloat-abi=hard -marm -mfpu=vfpv4
-mtune=cortex-a8 -fno-schedule-insns2 -fno-cprop-registers -fno-if-conversion2
-fno-dse -fno-reorder-blocks -fno-reorder-blocks-and-partition
-fno-auto-inc-dec -fno-if-conversion

Disabling various pre-reload passes leads to changes in register pressure that
end up affecting IRA/LRA and end up masking the bug

[Bug rtl-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[dave.anglin at bell dot net]

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

--- Comment #14 from dave.anglin at bell dot net ---
On 2016-02-09 7:32 AM, bernds at gcc dot gnu.org wrote:
> (In reply to John David Anglin from comment #0)
>
>> >-   ldh 2(%r31),%r20
> Could you verify whether the test works if you replace the 2(%r31) with 
> 0(%r31)
> ?
It works.

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That is not that easy, because it is apparently caller-save.c that is
miscompiled with -fprofile-use.
I can attach caller-save.ii and caller-save.gcda.

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 37646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37646=edit
caller-save.gcda

caller-save.gcda

[Bug c++/59627] ICE with OpenMP "declare reduction" and -flto

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Eventually.  I have dozens of changes (mostly non-OpenMP related) I have
committed to trunk only in the past few months, need to find time and backport
those that should be backported to the older branches.  This would be one of
them.

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The ICE is around
140   ok = (cached_reg_save_code[reg][mode] != -1
141 && cached_reg_restore_code[reg][mode] != -1);
   0x10e84a24 :   stw
r10,1792(r6)
   0x10e84a28 :   stw
r10,-21428(r8)
   0x10e84a2c :   b  
0x10e849e4 
   0x10e84a30 :   addis   r9,r9,1
=> 0x10e84a34 :   lwz
r9,-21428(r9)
   0x10e84a38 :   cmpwi   r9,-1
   0x10e84a3c :   beq-   
0x10e849c8 
   0x10e84a40 :   addis   r3,r2,1
   0x10e84a44 :   ld 
r3,-29144(r3)
   0x10e84a48 :   bl 
0x109149d0 
   0x10e84a4c :   nop
   0x10e84a50 :   addis   r3,r2,1
End of assembler dump.
(gdb) p/x $r9
$2 = 0x1dd90
(gdb) p this_target_reload
$3 = (target_reload *) 0x117060d8 
(gdb) p _target_reload
$4 = (target_reload **) 0x11586948 

The addis r9,r9,1;lwz r9,-21428(r9) is in *.final:
(insn:TI 366 165 169 (set (reg:DI 9 9)
(unspec:DI [
(zero_extend:DI (mem:SI (plus:DI (plus:DI (reg/f:DI 9 9
[orig:199 _98 ] [199])
(const_int 65536 [0x1]))
(const_int -21428 [0xac4c])) [79
MEM[(struct target_reload *)_98 + 44108B]+0 S4 A32]))
] UNSPEC_FUSION_GPR)) ../../gcc/caller-save.c:141 858
{fusion_gpr_load_di}
 (nil))
(insn 169 366 170 (set (reg:CC 68 0 [270])
(compare:CC (reg:SI 9 9 [orig:268 MEM[(struct target_reload *)_98 +
44108B] ] [268])
(const_int -1 [0x]))) ../../gcc/caller-save.c:141
720 {*cmpsi_signed}
 (expr_list:REG_DEAD (reg:SI 9 9 [orig:268 MEM[(struct target_reload *)_98
+ 44108B] ] [268])
(nil)))
but that assumes that r9 contains at that point probably this_target_reload
value, i.e. should be 0x117060d8.
In the code that branches to this spot we have right after reload:
(insn 146 141 144 14 (set (reg/f:DI 9 9 [orig:258 this_target_reload ] [258])
(mem/f/c:DI (reg/f:DI 28 28 [299]) [80 this_target_reload+0 S8 A64]))
550 {*movdi_internal64}
 (expr_list:REG_EQUIV (mem/f/c:DI (reg/f:DI 28 28 [299]) [80
this_target_reload+0 S8 A64])
(expr_list:REG_EQUAL (mem/f/c:DI (symbol_ref:DI ("this_target_reload")
[flags 0xc0]  ) [80 this
(nil
...
(insn 147 144 148 14 (set (reg/f:DI 9 9 [orig:199 _98 ] [199])
(plus:DI (reg/f:DI 9 9 [orig:258 this_target_reload ] [258])
(reg:DI 30 30 [orig:196 _89 ] [196]))) 81 {*adddi3}
 (nil))
(insn 148 147 150 14 (set (reg:SI 10 10 [orig:259 MEM[(struct target_reload
*)_98 + 1792B] ] [259])
(mem:SI (plus:DI (reg/f:DI 9 9 [orig:199 _98 ] [199])
(const_int 1792 [0x700])) [79 MEM[(struct target_reload *)_98 +
1792B]+0 S4 A32])) ../../gcc/caller-save.c:141 438 {*movsi_internal
 (expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 9 9 [orig:199 _98 ] [199])
(const_int 1792 [0x700])) [79 MEM[(struct target_reload *)_98 +
1792B]+0 S4 A32])
(nil)))
(insn 150 148 151 14 (set (reg:CC 75 7 [261])
(compare:CC (reg:SI 10 10 [orig:259 MEM[(struct target_reload *)_98 +
1792B] ] [259])
(const_int -1 [0x]))) ../../gcc/caller-save.c:141
720 {*cmpsi_signed}
 (nil))
(jump_insn 151 150 171 14 (set (pc)
(if_then_else (ne (reg:CC 75 7 [261])
(const_int 0 [0]))
(label_ref 164)
(pc))) ../../gcc/caller-save.c:141 756 {*rs6000.md:11629}
 (int_list:REG_BR_PROB 3226 (nil))
 -> 164)
but in *.final that doesn't set reg 9 anymore:
(insn 146 138 139 (set (reg/f:DI 8 8 [orig:258 this_target_reload ] [258])
(mem/f/c:DI (reg/f:DI 28 28 [299]) [80 this_target_reload+0 S8 A64]))
550 {*movdi_internal64}
 (expr_list:REG_EQUIV (mem/f/c:DI (reg/f:DI 28 28 [299]) [80
this_target_reload+0 S8 A64])
(expr_list:REG_EQUAL (mem/f/c:DI (symbol_ref:DI ("this_target_reload")
[flags 0xc0]  ) [80 this
(nil
...
(insn 147 141 144 (set (reg/f:DI 3 3 [orig:199 _98 ] [199])
(plus:DI (reg/f:DI 8 8 [orig:258 this_target_reload ] [258])
(reg:DI 30 30 [orig:196 _89 ] [196]))) 81 {*adddi3}
 (expr_list:REG_DEAD (reg/f:DI 8 8 [orig:258 this_target_reload ] [258])
(nil)))
(insn:TI 144 147 148 (set (mem:SI (plus:DI (reg:DI 10 10 [254])
(const_int 12 [0xc])) [4

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to Kirill Yukhin from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > So do you want to use reg_or_0_operand?  I don't think we usually tie output
> > with input already in the predicates, except when match_dup is used.
> 
> That is the issue. reg_or_0_operand won't work (although it is better than
> "vector_move_operand" since it is prohibits memory)
> 
> We want 2nd operand to be either:
> 1. const0_rtx
> 2. match_dup 0

You can add additional conditions to insn enable condition. There are many
examples, e.g. ix86_binary_operator_ok in "*add_1".

[Bug middle-end/69729] [6 regression] [CHKP] internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Here is a patch which caused the regression:

diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 0cefc15..6bb76cc 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2320,7 +2320,8 @@ lto_output (void)
   if (cgraph_node *node = dyn_cast  (snode))
{
  if (lto_symtab_encoder_encode_body_p (encoder, node)
- && !node->alias)
+ && !node->alias
+ && (!node->thunk.thunk_p || !node->instrumented_version))
{
  if (flag_checking)
{


It was meant to disable streaming of instrumentation thunks but instead it
disable streaming of thunks for instrumented functions.  When original function
has thunks, we create similar thunks for instrumented version.  These thunks
are linked with original ones via 'instrumented_version'.  In this patch we
just skip such thunks but these thunks are to be streamed out similar to
regular thunks.  It causes function in ltrans unit with no its thunk and
results in ICE.

I suppose this patch is a part of chkp thunks refactoring so I propose to
revert it for now and delay until whole refactoring series is ready.

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 37647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37647=edit
auto-host.h

auto-host.h

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-09
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
Steps to reproduce on non-powerpc host (no need for ppc64 binutils):
../configure --target powerpc64-linux --enable-languages=c,c++
--disable-bootstrap
make -j16
Ctrl^C it early, after it configures stuff in gcc/ subdir and starts building
there
copy over the attached auto-host.h into gcc/ subdir
cd gcc
touch auto-host.h
make -j16 cc1 cc1plus
copy over the attached caller-save.{ii,gcda} into a new subdirectory
/cc1plus -fpreprocessed caller-save.ii -msecure-plt -quiet -dumpbase
caller-save.ii -auxbase-strip caller-save.s -g -O2 -version -fno-PIE
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fprofile-use -o
caller-save.s
This generates (besides debug info) the same assembly as the one in native
profiledbootstrap that ICEs on the 
typedef float TFtype __attribute__ ((mode (TF)));
typedef _Complex float TCtype __attribute__ ((mode (TC)));
TCtype
__multc3 (TFtype a, TFtype b, TFtype c, TFtype d)
{
  TFtype ac, bd, ad, bc, x, y;
  TCtype res;

  ac = a * c;
  bd = b * d;
  ad = a * d;
  bc = b * c;

  __asm__ ("" : "=m"(ac) : "m"(ac));
  __asm__ ("" : "=m"(bd) : "m"(bd));
  __asm__ ("" : "=m"(ad) : "m"(ad));
  __asm__ ("" : "=m"(bc) : "m"(bc));

  x = ac - bd;
  y = ad + bc;

  if (__builtin_expect ((x) != (x), 0) && __builtin_expect ((y) != (y), 0))
{

  _Bool recalc = 0;
  if (__builtin_expect (!__builtin_expect ((a) != (a), 0) &
!__builtin_expect (!__builtin_expect (((a) - (a)) != ((a) - (a)), 0), 1), 0) ||
__builtin_expect (!__builtin_expect ((b) != (b), 0) & !__builtin_expect
(!__builtin_expect (((b) - (b)) != ((b) - (b)), 0), 1), 0))
 {


   a = __builtin_copysignl (__builtin_expect (!__builtin_expect ((a) != (a), 0)
& !__builtin_expect (!__builtin_expect (((a) - (a)) != ((a) - (a)), 0), 1), 0)
? 1 : 0, a);
   b = __builtin_copysignl (__builtin_expect (!__builtin_expect ((b) != (b), 0)
& !__builtin_expect (!__builtin_expect (((b) - (b)) != ((b) - (b)), 0), 1), 0)
? 1 : 0, b);
   if (__builtin_expect ((c) != (c), 0)) c = __builtin_copysignl (0, c);
   if (__builtin_expect ((d) != (d), 0)) d = __builtin_copysignl (0, d);
  recalc = 1;
 }
 if (__builtin_expect (!__builtin_expect ((c) != (c), 0) &
!__builtin_expect (!__builtin_expect (((c) - (c)) != ((c) - (c)), 0), 1), 0) ||
__builtin_expect (!__builtin_expect ((d) != (d), 0) & !__builtin_expect
(!__builtin_expect (((d) - (d)) != ((d) - (d)), 0), 1), 0))
 {


   c = __builtin_copysignl (__builtin_expect (!__builtin_expect ((c) != (c), 0)
& !__builtin_expect (!__builtin_expect (((c) - (c)) != ((c) - (c)), 0), 1), 0)
? 1 : 0, c);
   d = __builtin_copysignl (__builtin_expect (!__builtin_expect ((d) != (d), 0)
& !__builtin_expect (!__builtin_expect (((d) - (d)) != ((d) - (d)), 0), 1), 0)
? 1 : 0, d);
   if (__builtin_expect ((a) != (a), 0)) a = __builtin_copysignl (0, a);
   if (__builtin_expect ((b) != (b), 0)) b = __builtin_copysignl (0, b);
   recalc = 1;
 }
 if (!recalc
   && (__builtin_expect (!__builtin_expect ((ac) != (ac), 0) &
!__builtin_expect (!__builtin_expect (((ac) - (ac)) != ((ac) - (ac)), 0), 1),
0) || __builtin_expect (!__builtin_expect ((bd) != (bd), 0) & !__builtin_expect
(!__builtin_expect (((bd) - (bd)) != ((bd) - (bd)), 0), 1), 0)
   || __builtin_expect (!__builtin_expect ((ad) != (ad), 0) &
!__builtin_expect (!__builtin_expect (((ad) - (ad)) != ((ad) - (ad)), 0), 1),
0) || __builtin_expect (!__builtin_expect ((bc) != (bc), 0) & !__builtin_expect
(!__builtin_expect (((bc) - (bc)) != ((bc) - (bc)), 0), 1), 0)))
 {

   if (__builtin_expect ((a) != (a), 0)) a = __builtin_copysignl (0, a);
   if (__builtin_expect ((b) != (b), 0)) b = __builtin_copysignl (0, b);
   if (__builtin_expect ((c) != (c), 0)) c = __builtin_copysignl (0, c);
   if (__builtin_expect ((d) != (d), 0)) d = __builtin_copysignl (0, d);
   recalc = 1;
 }
  if (recalc)
 {
   x = __builtin_huge_vall () * (a * c - b * d);
   y = __builtin_huge_vall () * (a * d + b * c);
 }
}

  __real__ res = x;
  __imag__ res = y;
  return res;
}

testcase.

[Bug target/69614] [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
You're right.
Any change in the flags or to the code that appears to makes the failure go
away just happens to reduce register pressure.

In the failing case the reload dump shows that LRA does much more work than in
the non-failing case.

I'm not very familiar with the operation of LRA so it's hard to figure out
exactly what's going on but it calculates pseudo live ranges more times and
tries more coalescing attempts

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
Please provide the output of "objdump -r use.o".

[Bug target/69734] no_caller_saved_registers attribute doesn't work with -mavx512f -g

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
This is on hjl/interrupt/stage1 branch.  Trunk never spills mask
registers.

[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #6 from amker at gcc dot gnu.org ---
I will have a look at this one.

[Bug target/69734] New: no_caller_saved_registers attribute doesn't work with -mavx512f -g

[hjl.tools at gmail dot com]

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

Bug ID: 69734
   Summary: no_caller_saved_registers attribute doesn't work with
-mavx512f -g
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com, vaalfreja at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 interrupt-2]$ cat y.c
extern void bar (void);

 __attribute__((no_caller_saved_registers))
void
foo (void *frame)
{
  bar ();
}
[hjl@gnu-6 interrupt-2]$ /export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -c -O -g  y.c -mavx512f
/tmp/cc47JCJ0.s: Assembler messages:
/tmp/cc47JCJ0.s:79: Error: register save offset not a multiple of 8
/tmp/cc47JCJ0.s:80: Error: register save offset not a multiple of 8
/tmp/cc47JCJ0.s:81: Error: register save offset not a multiple of 8
/tmp/cc47JCJ0.s:83: Error: register save offset not a multiple of 8
/tmp/cc47JCJ0.s:84: Error: register save offset not a multiple of 8
/tmp/cc47JCJ0.s:85: Error: register save offset not a multiple of 8
[hjl@gnu-6 interrupt-2]$

[Bug middle-end/65702] [5 Regression] ICE (tree check: expected ssa_name, have var_decl in expand_gimple_basic_block, at cfgexpand.c:5506) on arm-linux-gnueabihf

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #13 from Bernd Schmidt  ---
Fixed.

[Bug c++/69733] -Wignored-qualifiers points to wrong const

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #1 from Bernd Schmidt  ---
Having a go.

[Bug tree-optimization/69732] [6 Regression] Missed vectorization due to failed dependence analysis

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The solution here is to have another set of base / access function forcibly
using the pointer representation as a backup for dependence analysis.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

--- Comment #13 from Václav Haisman  ---
Created attachment 37643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37643=edit
objdump -r use.o log

(In reply to H.J. Lu from comment #12)
> Please provide the output of "objdump -r use.o".

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[ysrumyan at gmail dot com]

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

--- Comment #13 from Yuri Rumyantsev  ---
I checked that performance is back for the whole benchmark. Thanks a lot.

Yuri.

2016-02-09 14:17 GMT+03:00 amker at gcc dot gnu.org :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
>
> --- Comment #12 from amker at gcc dot gnu.org ---
> Patch sent for review at
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00612.html
> It works for the reduced test case, could you please help me to check if it
> works for you original case?
> Thanks,
> bin
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug debug/69705] [5/6 Regression] segfault in libgomp.fortran/task1.f90 with -flto -fno-use-linker-plugin -fno-toplevel-reorder -O1 -g

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin15.

[Bug rtl-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
The referenced debian bug suggests that there is both an aliasing violation and
unaligned access.

[Bug rtl-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[bernds at gcc dot gnu.org]

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

--- Comment #11 from Bernd Schmidt  ---
(In reply to John David Anglin from comment #0)

> -   ldh 2(%r31),%r20

Could you verify whether the test works if you replace the 2(%r31) with 0(%r31)
?

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
I didn't realize Windows linker uses ELF relocation names.
I don't know what is wrong.

[Bug target/69734] no_caller_saved_registers attribute doesn't work with -mavx512f -g

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-09
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Mask registers are spilled with

kmovw   %k0, -88(%rbp)
kmovw   %k1, -86(%rbp)
kmovw   %k2, -84(%rbp)
kmovw   %k3, -82(%rbp)
kmovw   %k4, -80(%rbp)
kmovw   %k5, -78(%rbp)
kmovw   %k6, -76(%rbp)
kmovw   %k7, -74(%rbp)
...
.cfi_offset 118, -104
.cfi_offset 119, -102
.cfi_offset 120, -100
.cfi_offset 121, -98
.cfi_offset 122, -96
.cfi_offset 123, -94
.cfi_offset 124, -92
.cfi_offset 125, -90

But the minimum stack slot for spill is 4 byte for 32-bit target
and 8 byte for 64-bit target.

[Bug target/69734] no_caller_saved_registers attribute doesn't work with -mavx512f -g

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
A simpler testcase:

[hjl@gnu-6 interrupt-2]$ cat k.c
void
__attribute__((interrupt))
fn (void *frame)
{
  asm ("#"
   :
   :
   : "k1");
}
[hjl@gnu-6 interrupt-2]$ make k.o
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -c -O2 -march=knl k.c
/tmp/cceKHse9.s: Assembler messages:
/tmp/cceKHse9.s:13: Error: register save offset not a multiple of 8
Makefile:29: recipe for target 'k.o' failed
make: *** [k.o] Error 1
[hjl@gnu-6 interrupt-2]$

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  ---
Is there a .i file and compiler command line that can reproduce this with a
cross?

[Bug target/69614] [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Created attachment 37642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37642=edit
Reload pass dump

[Bug debug/69705] [5/6 Regression] segfault in libgomp.fortran/task1.f90 with -flto -fno-use-linker-plugin -fno-toplevel-reorder -O1 -g

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.9.3
   Target Milestone|--- |5.4
Summary|segfault in |[5/6 Regression] segfault
   |libgomp.fortran/task1.f90   |in
   |with -flto  |libgomp.fortran/task1.f90
   |-fno-use-linker-plugin  |with -flto
   |-fno-toplevel-reorder -O1   |-fno-use-linker-plugin
   |-g  |-fno-toplevel-reorder -O1
   ||-g

[Bug rtl-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[bernds at gcc dot gnu.org]

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

--- Comment #10 from Bernd Schmidt  ---
(In reply to Jakub Jelinek from comment #9)
> The referenced debian bug suggests that there is both an aliasing violation
> and unaligned access.

In their source code you mean? There's type punning going on in the crc
testcase as well, but I think there's some sort of big-endian confusion in the
bswap code.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

--- Comment #14 from Václav Haisman  ---
Created attachment 37644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37644=edit
objdump -Ttr def.o log

`objdump -Ttr def.o` in advance, just in case it is relevant.

[Bug middle-end/65702] [5 Regression] ICE (tree check: expected ssa_name, have var_decl in expand_gimple_basic_block, at cfgexpand.c:5506) on arm-linux-gnueabihf

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
Author: bernds
Date: Tue Feb  9 13:10:39 2016
New Revision: 233242

URL: https://gcc.gnu.org/viewcvs?rev=233242=gcc=rev
Log:
PR middle-end/65702
* varasm.c (make_decl_rtl): Mark invalid register vars as
DECL_EXTERNAL.

testsuite/
PR middle-end/65702
* c-c++-common/pr67639.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr67639.c
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/varasm.c

[Bug rtl-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
If the problem is in bswap, then the most suspect branches/gcc-5-branch commit
is r232664.

[Bug rtl-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[bernds at gcc dot gnu.org]

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

--- Comment #13 from Bernd Schmidt  ---
Yes, that's the one I've been zeroing in on. It does look wrong, but it was
intended as a fix, so I guess I'll be reinvestigating the original bug.

[Bug target/63206] Gcc 4.9.1 Generated code needlessly stacks r3

[pype_1999.geo at yahoo dot com]

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

--- Comment #2 from Pype  ---
reproduced with tail-call + r3 stack bug on 
 4.8.3
 4.8.4
 4.9.2
 5.1
appears fixed in 
 5.3

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #35 from Thomas Koenig  ---
(In reply to rguent...@suse.de from comment #34)

> >So if this is Fortran-only, we probably have to hook off --std=legacy,
> >right?
> 
> Yes.

Ouch.

This is not really in line to what std=legacy does.  Maybe
using a separate Fortran-only option, something like
-fbroken-common-blocks, would be better.

On the other hand, it might be a good idea to warn if such stores
are removed.  I suspect that such a warning will catch many
bugs in the existing codebase, if it is found in SPEC...

[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Hmm, the first problem is the two iv uses from dy load/store are not recognized
as having same base address/object.  This may caused by my patch disabling
expansion of iv base.  Or it exists all the time.  This isn't critical, we can
transform it on aaarch64 anyway.
Another problem is more important that dx mem ref is not recognized as address
type.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek  ---
As Richard said, you can do similar (invalid too) stuff in C too, say:
struct S { int a[1]; } s;
in one TU and
struct S { int a[1]; } s;

int
foo (int x)
{
  return s.a[x];
}

int
bar (int x)
{
  return s.a[1 + x] + s.a[0] + s.a[x];
}

GCC 5 would compile it to what the author might have meant, while GCC 6 will
optimize bar into s.a[0] * 3;

[Bug bootstrap/69725] profiledbootstrap failure due to unsats for isl functions

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I used the download_prerequistes script to download isl-0.15.  I have
gmp-4.3.2, mpc-0.8.1, and mpfr-2.4.2.  I didn't know that in-tree ISL wasn't
being tested.  Let me see if I get farther by either disabling it or using the
system ISL.

[Bug target/63206] Gcc 4.9.1 Generated code needlessly stacks r3

[pype_1999.geo at yahoo dot com]

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

Pype  changed:

   What|Removed |Added

 CC||pype_1999.geo at yahoo dot com

--- Comment #1 from Pype  ---
Created attachment 37648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37648=edit
test case: tail-call + r3 stack bug => wrong function called.

last instructions of the produced machine code :

  74:   e59f3014ldr r3, [pc, #20]   ; 90

  78:   e586300cstr r3, [r6, #12]
  7c:   e1a4mov r0, r4
  80:   e8bd40f8pop {r3, r4, r5, r6, r7, lr}
  84:   e12fff13bx  r3

[Bug target/63206] Gcc 4.9.1 Generated code needlessly stacks r3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
This seems familiar. PR 67226?
Can you try a recent snapshot from the 4.9 branch?

[Bug other/67552] [meta] x86 interrupt attribute

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
Bug 67552 depends on bug 69734, which changed state.

Bug 69734 Summary: no_caller_saved_registers attribute doesn't work with 
-mavx512f -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69734

   What|Removed |Added

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

[Bug target/69734] no_caller_saved_registers attribute doesn't work with -mavx512f -g

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Blocks||67552
 Resolution|--- |FIXED

--- Comment #4 from H.J. Lu  ---
Fixed on hjl/interrupt/stage1 and hjl/interrupt/gcc-5-branch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
[Bug 67552] [meta] x86 interrupt attribute

[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)

[gang.chen.5i5j at gmail dot com]

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

--- Comment #4 from Chen Gang  ---
(In reply to Chen Gang from comment #3)
> Created attachment 37625 [details]
> Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas
> for long wide type will cause issue.

Oh, sorry, it is my misunderstanding.

I shall try the "make check" for this patch under Darwin with gcc 6.0.0.

Thanks.

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[jakub at jermar dot eu]

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

--- Comment #7 from Jakub Jermar  ---
Thank you, I will get back to you once I am done with the test.

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
*** Bug 69727 has been marked as a duplicate of this bug. ***

[Bug c++/69736] New: [4.9/5/6 Regression] "error: too few arguments to function" in c++14 but not c++11

[mpolacek at gcc dot gnu.org]

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

Bug ID: 69736
   Summary: [4.9/5/6 Regression] "error: too few arguments to
function" in c++14 but not c++11
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

void fn1(bool = true) { (fn1)(); }

Is accepted with c++11 but not with c++14.  This is what creduce came up with. 
clang++ accepts this code though it warns:
q.cc:1:23: warning: all paths through this function will call itself
[-Winfinite-recursion]

[Bug bootstrap/69727] [6 Regression] ICE in profiledbootstrap in reg_save_code at ../../gcc/caller-save.c:141

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Jakub Jelinek  ---
Ah, this is a dup of PR68404, at least the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404#c19 fix seems to fix the
issue (just tested the assembly, haven't tried profiledbootstrap yet).

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

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[msebor at gcc dot gnu.org]

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

--- Comment #22 from Martin Sebor  ---
After applying the patch from comment #19 my profiledbootstrap also just
completed on the big-endian powerpc64-redhat-linux-gnu (it failed before due to
the duplicate bug 69727).