[Bug fortran/78062] sinus and cosinus fails

[informatica at ecm dot ub.edu]

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

--- Comment #4 from Miquel  ---
Sorry for the delay.
fortran version:
GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609

Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu



With the -O2 modifier it works, but without it, it produces 

~# ./a.out 
 -0.99440605160172935  -0.99440605160172935

[Bug c/78181] unrecognized option -mcpu=cortex-a73

[airbak.li at huawei dot com]

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

Airbak  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|INVALID |FIXED

--- Comment #3 from Airbak  ---
Thank you very much.
After I update binutils-linaro-2.25.0-2015.01-2 to binutils-2.27, this issue is
solved.

[Bug tree-optimization/78180] Poor optimization of std::array on gcc 4.8/5.4/6.2 as compared to simple raw array

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
By moving the array to be end of struct Rolling, GCC does the correct thing and
optimizing out the load of idx out of the loop.

That is:

template  class Rolling {
  uint32_t idx_;
  const uint32_t size_;
  C times_{};



- CUT---

Basically:
  MEM[(value_type &)&r][_54] = _2;


Is not treated as referencing the array field but rather referencing the whole
struct so SRA thinks it cannot do anything with it.

[Bug tree-optimization/78180] Poor optimization of std::array on gcc 4.8/5.4/6.2 as compared to simple raw array

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #6 from Andrew Pinski  ---
r.idx_ is not optimized away inside the loop for some reason.

NonWorking case:

  _53 = r.idx_;
  _54 = (long unsigned int) _53;
  MEM[(value_type &)&r][_54] = _2;


Working case:

  _52 = r.idx_;
  r.times_[_52] = _2;


std::array operator[]:
  _5 = &MEM[(const long int[128] &)this_2(D)][__n_4(D)];

--

  reference
  operator[](size_type __n) noexcept
  { return _AT_Type::_S_ref(_M_elems, __n); }




  static constexpr _Tp&
  _S_ref(const _Type& __t, std::size_t __n) noexcept
  { return const_cast<_Tp&>(__t[__n]); }



So SRA is not understanding the array being the first field .

[Bug middle-end/78180] Poor optimization of std::array on gcc 4.8/5.4/6.2 as compared to simple raw array

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Does -D_GLIBCXX_USE_CXX11_ABI=0 change the code or not?  I don't know if we
want to change any of the old ABI code ...

[Bug target/78192] extract from vector registers to int results in wrong data order

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
This fails even at -O0 or -O1 optimization:

/home/sawdey/src/gcc/trunk2/build/gcc/xgcc
-B/home/sawdey/src/gcc/trunk2/build/gcc/
/home/sawdey/src/gcc/trunk2/trunk/gcc/testsuite/gcc.c-torture/execute/simd-1.c 
-mcpu=power9 -Wl,-rpath=/tmp/lib64 -fno-diagnostics-show-caret
-fdiagnostics-color=never-O0  -w  -lm  -o ./simd-1.exe

/home/sawdey/src/gcc/trunk2/build/gcc/xgcc
-B/home/sawdey/src/gcc/trunk2/build/gcc/
/home/sawdey/src/gcc/trunk2/trunk/gcc/testsuite/gcc.c-torture/execute/simd-1.c
-mcpu=power9 -Wl,-rpath=/tmp/lib64 -fno-diagnostics-show-caret
-fdiagnostics-color=never -O1 -w -lm -o ./simd-1.exe

[Bug target/78192] New: extract from vector registers to int results in wrong data order

[acsawdey at gcc dot gnu.org]

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

Bug ID: 78192
   Summary: extract from vector registers to int results in wrong
data order
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: meissner at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: rs6000 ppc64le power9

Tested with trunk 241701, running on power8 ppc64le compiling for power9
ppc64le.

gcc.c-torture/execute/simd-1.c is failing and it appears that the extraction
from vector to int registers is not happening in the right order.

  7 typedef int __attribute__((mode(SI))) __attribute__((vector_size (16)))
vecint;
  8 typedef int __attribute__((mode(SI))) siint;
  9
 10 vecint i = { 150, 100, 150, 200 };
 11 vecint j = { 10, 13, 20, 30 };
 12 vecint k;
 13
 14 union {
 15   vecint v;
 16   siint i[4];
 17 } res;
 18
 19 /* This should go away once we can use == and != on vector types.  */
 20 void
 21 verify (siint a1, siint a2, siint a3, siint a4,
 22 siint b1, siint b2, siint b3, siint b4)
 23 {
 24   if (a1 != b1
 25   || a2 != b2
 26   || a3 != b3
 27   || a4 != b4)
 28 abort ();
 29 }
 30
 31 int
 32 main ()
 33 {
 34   k = i + j;
 35   res.v = k;

   0x16f0 :lxv vs63,0(r9)
   0x16f4 :lxv vs62,16(r9)
   0x16f8 :vadduwm v0,v31,v30
   0x16fc :nop
   0x1700 :addir30,r2,-32400
   0x1704 :stxvvs32,0(r30)
   0x1708 :nop
   0x170c :addir31,r2,-32384
   0x1710 :stxvvs32,0(r31)
   0x1714 :xxextractuw vs33,vs32,12
   0x1718 :mfvrwz  r6,v1
   0x171c :mfvrwz  r5,v0
   0x1720 :xxextractuw vs33,vs32,4
   0x1724 :mfvrwz  r4,v1
   0x1728 :   xxextractuw vs32,vs32,0
   0x172c :   mfvrwz  r3,v0
   0x1730 :   li  r10,230
   0x1734 :   li  r9,170
   0x1738 :   li  r8,113
   0x173c :   li  r7,160
   0x1740 :   extsw   r6,r6
   0x1744 :   extsw   r5,r5
   0x1748 :   extsw   r4,r4
   0x174c :   extsw   r3,r3
   0x1750 :   bl  0x1684 

at 0x16fc the vector register results look ok:
(gdb) p $vs32
$22 = {uint128 = 0x00e600aa007100a0, v2_double =
{2.3978552445812627e-312, 4.8805903200600379e-312}, v4_float = {2.24207754e-43,
1.58346726e-43, 2.38220739e-43, 3.22298647e-43}, v4_int32 = {
160, 113, 170, 230}, v8_int16 = {160, 0, 113, 0, 170, 0, 230, 0}, v16_int8
= {-96, 0, 0, 0, 113, 0, 0, 0, -86, 0, 0, 0, -26, 0, 0, 0}}
(gdb) p $vs62
$23 = {uint128 = 0x001e0014000d000a, v2_double =
{2.7585945287489197e-313, 6.3659873738839482e-313}, v4_float = {1.40129846e-44,
1.821688e-44, 2.80259693e-44, 4.20389539e-44}, v4_int32 = {10,
13, 20, 30}, v8_int16 = {10, 0, 13, 0, 20, 0, 30, 0}, v16_int8 = {10, 0, 0,
0, 13, 0, 0, 0, 20, 0, 0, 0, 30, 0, 0, 0}}
(gdb) p $vs63
$24 = {uint128 = 0x00c8009600640096, v2_double =
{2.1219957917063708e-312, 4.2439915826716431e-312}, v4_float = {2.1019477e-43,
1.40129846e-43, 2.1019477e-43, 2.80259693e-43}, v4_int32 = {150,
100, 150, 200}, v8_int16 = {150, 0, 100, 0, 150, 0, 200, 0}, v16_int8 =
{-106, 0, 0, 0, 100, 0, 0, 0, -106, 0, 0, 0, -56, 0, 0, 0}}

at 0x1730 the extraction into gprs is incorrect:
(gdb) p $r3
$14 = 230
(gdb) p $r4
$15 = 170
(gdb) p $r5
$16 = 170
(gdb) p $r6
$17 = 160

[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to gnuBSt from comment #4)
> PS. Any development on this issue?

This is fixed in GCC >= 6.0 and it doesn't seem critical enough to bother
fixing it in GCC 5.4. It should probably be closed.

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
I built the GCC stage1 with and without the tree-vrp.c patch.  Same sources,
same revision, same directory. cc1plus.good and cc1plus.bad.

Then I used both versions of cc1plus to compile tree-ssa-sccvn.c with
-fdump-tree-all-all -frandom-seed=0.

The differences start in 027t.fixup_cfg3, all like:

tree-ssa-sccvn.c.027t.fixup_cfg3
<   _4 =
_ZN2wi10int_traitsI16generic_wide_intI22fixed_wide_int_storageILi128EEE
E13get_precisionERKS4_.isra.113D.101391 ();
---
>   _4 = _ZN2wi10int_traitsI16generic_wide_intI22fixed_wide_int_storageILi128EEE
E13get_precisionERKS4_.isra.114D.101527 ();

tree-ssa-sccvn.c.028t.inline_param1
25946c25946
<   loop depth: 0 freq:1000 size: 3 time: 12 callee size: 5 stack: 0
predica
te: (op0[ref offset: 160] == 0B) && (op0[ref offset: 0] == 1)
---
>   loop depth: 0 freq:1000 size: 3 time: 12 callee size: 4 stack: 0 predica
te: (op0[ref offset: 160] == 0B) && (op0[ref offset: 0] == 1)
26863c26863
<   loop depth: 0 freq:1000 size: 3 time: 12 callee size: 5 stack: 0
predica
te: (op0[ref offset: 0] == 3)
---
>   loop depth: 0 freq:1000 size: 3 time: 12 callee size: 4 stack: 0 predica
te: (op0[ref offset: 0] == 3)
27608c27608
<   loop depth: 0 freq:1000 size: 6 time: 15 callee size: 7 stack: 0
---
>   loop depth: 0 freq:1000 size: 6 time: 15 callee size: 6 stack: 0

tree-ssa-sccvn.c.029t.einline
26729c26729
size:5 time:5
26732c26732
size:5 time:5
26736c26736
size:5 time:5
26739,26740c26739
<   Accounting size:2.00, time:1.66 on predicate:(op0[ref offset:
16
0] == 0B) && (op0[ref offset: 0] == 1)
<   Accounting size:0.50, time:0.40 on predicate:(op0[ref offset:
16
0] == 0B) && (op0[ref offset: 0] == 1)
---
>   Accounting size:0.50, time:0.41 on predicate:(op0[ref offset: 16
0] == 0B) && (op0[ref offset: 0] == 1)
26767,26769c26766,26768
< Merging blocks 13 and 33
< Merging blocks 31 and 26
< Merging blocks 35 and 32
---
> Merging blocks 13 and 32
> Merging blocks 30 and 26
> Merging blocks 34 and 31
26795d26793
< Registering new PHI nodes in block #10
26797c26795
< Registering new PHI nodes in block #11

And more extensive differences in 038t.evrp

The full tree dumps are about 470MB each.

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Eric, if you could try it in your environment to see if it solves the
> problem, it would be helpful.

Will do tomorrow morning.

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-02
 Ever confirmed|0   |1

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Created attachment 39951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39951&action=edit
Patch to disable IFmode if -msoft-float

I believe this patch fixes the problem.  It disables IFmode if -msoft-float was
used.

The problem was some of the insns that support IFmode were enabled if
-msoft-float was used.  Since the 64-bit Linux distributions stopped supporting
-msoft-float some time ago, -msoft-float was no longer built on those systems,
and the bug was not noticed.  However, 32-bit Linux systems and other PowerPC
systems do build software floating point.

IFmode is the __ibm128 type added as part of the __float128/_Float128 support
to allow access to the current IBM extended double support if/when long double
becomes _Float128.

I'm attempting to do a normal bootstrap on 64-bit Linux right now, and it looks
like the build is broken due to other reasons.  So, I'm going back to a
previous version that did build to make sure the patch is ok.

Eric, if you could try it in your environment to see if it solves the problem,
it would be helpful.

[Bug tree-optimization/78190] [7 Regression] ice in get_alias_type_for_stmts

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |7.0
Summary|ice in  |[7 Regression] ice in
   |get_alias_type_for_stmts|get_alias_type_for_stmts

[Bug debug/78191] New: [7 regression] ICE in calc_die_sizes

[ro at gcc dot gnu.org]

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

Bug ID: 78191
   Summary: [7 regression] ICE in calc_die_sizes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.10
Target: *-*-solaris2.10
 Build: *-*-solaris2.10

Created attachment 39950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39950&action=edit
preprocessed input

Between r241708 (ok) and r241723 (bad), Solaris 10 bootstrap started to break
compiling a couple of files in libstdc++ (both sparc and x86, 64-bit only):

/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/c++11/ostream-inst.cc:98:1:
internal compiler error: in calc_die_sizes, at dwarf2out.c:9008
 } // namespace
 ^
0x88a01ba calc_die_sizes
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:9007
0x88a0205 calc_die_sizes
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:9012
0x88a30c6 output_comp_unit
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:10288
0x88d1447 dwarf2out_finish
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:29441

Solaris 11 and 12 are not affected for some reason.

Seen with

$ cc1plus -fpreprocessed ostream-inst.ii -quiet -m64 -g -O2 -o ostream-inst.s

#0  fancy_abort (file=0x99a2108 "/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c", 
line=9008, 
function=0x99a7826 
"calc_die_sizes") at /vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:1447
#1  0x088a01bb in calc_die_sizes (die=0xfeb2e360)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:9007
#2  0x088a0206 in calc_die_sizes (die=0xfea1d030)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:9012
#3  0x088a30c7 in output_comp_unit (die=0xfea1d030, output_if_empty=0, 
dwo_id=0x0) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:10288
#4  0x088d1448 in dwarf2out_finish ()
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:29441
#5  0x08cdb379 in compile_file ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:546
#6  0x08cdd598 in do_compile ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2012
#7  0x08cdd854 in toplev::main (this=0x80475ee, argc=9, argv=0x804761c)
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2146
#8  0x096cb877 in main (argc=9, argv=0x804761c)
at /vol/gcc/src/hg/trunk/local/gcc/main.c:39

(gdb) p die->die_offset
$1 = 262

  Rainer

[Bug debug/78191] [7 regression] ICE in calc_die_sizes

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/78190] ice in get_alias_type_for_stmts

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Created attachment 39949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39949&action=edit
C source code

After creduce

[Bug c/78190] New: ice in get_alias_type_for_stmts

[dcb314 at hotmail dot com]

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

Bug ID: 78190
   Summary: ice in get_alias_type_for_stmts
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 39948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39948&action=edit
C source code

The attached code, when compiled by gcc dated 20161102, with
compiler flag -O2, does this:

$ ../results/bin/gcc -O2 -c bug318.c
proctree.c: In function ‘tree_string’:
proctree.c:245:7: internal compiler error: Segmentation fault
0xc6f467 crash_signal
../../trunk/gcc/toplev.c:338
0x13aad34 vec::operator[](unsigned int)
../../trunk/gcc/vec.h:732
0x13aad34 vec::operator[](unsigned int)
../../trunk/gcc/vec.h:1216
0x13aad34 get_alias_type_for_stmts
../../trunk/gcc/gimple-ssa-store-merging.c:941
0x13aad34 output_merged_store
../../trunk/gcc/gimple-ssa-store-merging.c:1129

I've have a go at reducing the code.

[Bug tree-optimization/78035] Inconsistency between address comparison and alias analysis

[krister.walfridsson at gmail dot com]

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

krister.walfridsson at gmail dot com changed:

   What|Removed |Added

 CC||krister.walfridsson at gmail 
dot c
   ||om

--- Comment #9 from krister.walfridsson at gmail dot com ---
Doesn't this just introduce more inconsistencies in the compiler? For example

extern int a;
extern int b;

int foo(void)
{
a = 1;
b = 5;
a++;
return &a != &b;
}

optimizes to

foo:
movl$a, %eax
movl$5, b(%rip)
movl$2, a(%rip)
cmpq$b, %rax
setne   %al
movzbl  %al, %eax
ret

That is, the accesses to a and b are optimized as if they are distinct, even
though the compiler keeps the comparison of the addresses.

I cannot think of a reasonable use case where you must handle comparisons of
the addresses as currently implemented while allowing other optimizations as if
the objects are distinct, so I'd say the bug from the original description is
that we were "being too conservative in bar"...

[Bug fortran/78187] -fno-automatic does not work with allocatable scalar character result result

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-02
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Seems like allocatable character functions don't work with
-fno-automatic.  The problem is not in the main program:

$ cat mod.f90
module test_module
implicit none

contains
function scalar(a, b) result(c)
character(len=*), intent(in) :: a, b
character(len=:), allocatable :: c

c = trim(a)//trim(b)
print *,c
end function scalar
end module test_module
$ cat a.f90

! built using the following commands
! gfortran-6 -o testscal_f.exe testallocatablescalars.f90
! gfortran-6 -fno-automatic -o testscal_f.exe testallocatablescalars.f90
program test
use test_module
use iso_fortran_env
implicit none

character(len=:), allocatable :: c

c = scalar("abc","def")
write(*,*)"c|", c, "|", allocated(c)

end program test
$ gfortran -c -fno-automatic mod.f90 && gfortran -c a.f90 && gfortran mod.o a.o
&& ./a.out
 abcdef
 c|| T

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[joseph at codesourcery dot com]

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

--- Comment #23 from joseph at codesourcery dot com  ---
On Wed, 2 Nov 2016, txr at alumni dot caltech.edu wrote:

> Seven:  Given that the question is now under serious debate, IMO
> someone involved with gcc development should take the initiative
> and responsibility to submit a defect report in order to clarify
> the issue.  Apparently other compilers don't have this problem -

I thought Martin was going to do that (comment#10).

The various DR responses in this area suffer from (a) only deciding 
particular limited cases at most rather than interpreting things more 
generally, and not being very clear about what they decide, and (b) by not 
looking at exactly what the special guarantee is meant to relate to, and 
the different ways that has been interpreted in the past, thereby 
compounding the confusion from that wording having been written and edited 
over time by people who interpreted it in different ways, probably each 
assuming all the other people had interpreted it the same way.

[Bug fortran/78178] ICE in WHERE statement with diagnostic

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Nov  2 20:54:29 2016
New Revision: 241802

URL: https://gcc.gnu.org/viewcvs?rev=241802&root=gcc&view=rev
Log:
2016-11-02  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* gfortran.dg/where_5.f90:  New test.
* gfortran.dg/where_6.f90:  New test.

2016-11-02  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* match.c (match_simple_where):  Fill in locus for assigment
in simple WHERE statement.
(gfc_match_where):  Likewise.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_6.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/match.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/69544] [5/6/7 Regression] Internal compiler error with -Wall and where

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Nov  2 20:54:29 2016
New Revision: 241802

URL: https://gcc.gnu.org/viewcvs?rev=241802&root=gcc&view=rev
Log:
2016-11-02  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* gfortran.dg/where_5.f90:  New test.
* gfortran.dg/where_6.f90:  New test.

2016-11-02  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* match.c (match_simple_where):  Fill in locus for assigment
in simple WHERE statement.
(gfc_match_where):  Likewise.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_6.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/match.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78186] FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Hi Bin,

Could you try this patch please?

===
diff --git a/gcc/combine.c b/gcc/combine.c
index 7c21fe4..7ed0a62 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -11224,6 +11224,9 @@ change_zero_ext (rtx pat)
   rtx x = gen_rtx_AND (mode, reg, immed_wide_int_const (mask, mode));
   rtx y = simplify_gen_binary (ASHIFT, mode, SET_SRC (pat),
   GEN_INT (offset));
+  wide_int mask2 = wi::shifted_mask (offset, width, false, reg_width);
+  y = simplify_gen_binary (AND, mode, y,
+  immed_wide_int_const (mask2, mode));
   rtx z = simplify_gen_binary (IOR, mode, x, y);
   SUBST (SET_DEST (pat), reg);
   SUBST (SET_SRC (pat), z);
===

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[txr at alumni dot caltech.edu]

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

--- Comment #22 from Tim Rentsch  ---
[responding to comments from rguent...@suse.de in Comment 20]

> GCC already implements this if you specify -fno-strict-aliasing.

The main point of my comments is that the ISO C standard requires
the behavior in this case (and similar cases) be defined and not
subject to any reordering.  In other words the result must be the
same as an unoptimized version.  If a -fstrict-aliasing gcc /does/
transform the code so that the behavior is not the same as an
unoptimized version, then gcc is not a conforming implementation.
Or is it your position that gcc is conforming only when operated
in the -fno-strict-aliasing mode?  That position seems contrary to
the documented description of the -fstrict-aliasing option.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[txr at alumni dot caltech.edu]

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

--- Comment #21 from Tim Rentsch  ---
[responding to comments from jos...@codesourcery.com in Comment 19]

>> Five:  The answer to the question is clearly No.  The example code
>> is very much on point to the "one special guarantee" clause, and
>> so the read access p1->m is permitted.  As the access is permitted,
>
> I maintain that, as I said in comment#9, the textual history
> indicates that the original intent of saying things are permitted
> here is *only* an exception to the general implementation-defined
> nature of type punning, not to any other reason why things might
> be undefined (such as aliasing rules, data races, etc.).

I went back and read through your earlier comments more carefully.
After that I also reviewed C90, N869, C99, N1124, N1256, DR 236,
DR 257, DR 283, and C11 (in the guise of the just-pre-C11 draft
N1570).

Let me say first that I agree with you that the Semantics section
of the member access operators (. and ->) needs at least some
revision and clarification.

Having said that, let me offer several more detailed responses
and/or comments.

One:  IME later versions of the C standard generally do a better
job of expressing what is intended than earlier versions do.

Two:  The "visible union" condition in C99 was viewed not as a
change to C90 but as correcting an oversight;  it was expected
all along that the union type would be in scope, even if the
expectation was not a conscious one originally.  I am sorry I
don't have a reference handy for this, but one can be found
digging around in the historical documents on the open-std.org
website.

Three:  The "one special guarantee" rule is independent of the
rules for effective types.  This observation is obviously right
because effective type rules matter only for access to objects.
The only objects being accessed under the "one special guarantee"
rule are guaranteed to have compatible types, which is always
allowed by effective type rules.

Four:  The "one special guarantee" rule is related to the area of
"type punning" through unions, but seen by WG14 as a separate
issue relative to the general topic.  This is evident from the
committee response in DR 257.

Five:  The footnote added in C99 TC3 about type punning is seen
by WG14 not as a change but just as a clarifying comment noting
what behavior was intended all along.  This is evident from the
text and response in DR 283.  Note that Clark Nelson, the author
of this DR, is a long-standing member of WG14, and the suggested
revision given in the text was adopted verbatim for the TC.

Six:  A key question here is What is the point or purpose of the
"one special guarantee" rule in the first place?  the Standard
doesn't say, but let me propose two likely motivations.

1. Normally objects may be assumed not to overlap unless
they are accessed through an explicit union membership
expression (or through a character type, etc).  The "one
special guarantee" rule identifies a case where an explicit
union membership expression is not needed.

2. The C standard distinctly allows any amount of padding
between consecutive members of a struct.  Without the "one
special guarantee" rule, there would be no way to be sure
that the offsets of the respective members would match in
all cases.  The "one special guarantee" rule has the effect
of forcing offsets of struct members in a common initial
sequence to be the same.  That is important for code
portability.

Seven:  Given that the question is now under serious debate, IMO
someone involved with gcc development should take the initiative
and responsibility to submit a defect report in order to clarify
the issue.  Apparently other compilers don't have this problem -
only gcc does.

Eight:  In the meantime, the most prudent course of action is to
fix gcc so that it does not reorder code in cases like the above.
Whenever there is any doubt, the only sensible choice is to err
on the side of caution, and not perform any code transformations
that might not be allowed in a conforming implementation.  (Of
course it would be okay to perform such transformations under
some non-default compiler option, as long as it is not in force
unless explicitly requested, and clearly flagged as possibly
non-conforming.)

Nine:  Doing a final review, I realized I have not yet responded
directly to your last comment.  I agree with your general
sentiment that the "one special guarantee" rule is not meant as
a "super rule" that trumps all other possible reasons for
undefined behavior.  However, I do not agree with your primary
point that it is meant to be limited to the "type punning" area.
The example I previously mentioned in the C standard, and the
committee discussion in DR 257, both show that there are other
factors involved here beyond just those related to type punning.

I hope the above has helped clarify the matter.  I look forward
to reading your responding comment

[Bug tree-optimization/78189] New: movaps generated for unaligned store in aligned struct, when struct is referenced via unaligned member.

[jwyatt at feralinteractive dot com]

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

Bug ID: 78189
   Summary: movaps generated for unaligned store in aligned
struct, when struct is referenced via unaligned
member.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwyatt at feralinteractive dot com
  Target Milestone: ---

The code below, when compiled with -O2 -ftree-slp-vectorize -Wall -Wextra,
generates:

  pxor   %xmm0,%xmm0
  movaps %xmm0,0x10(%rdi)

for NullB. This causes a segfault, as rdi contains the address of the 8-byte
aligned "misaligned" member of struct B.

This does not happen if NullB uses reinterpret_cast instead of
uint8_t*, if "misaligned" and "pad" are swapped (so that "misaligned" is in
fact aligned). B::Null() is also fine.

// Impl.h

#include 

struct A
{
void * a;
void * b;
};

struct alignas(16) B
{
void * pad;
void * misaligned;
void * pad2;

A a;

void Null();
};

static_assert((offsetof(B, a) % 16) == 8, "A should be misaligned for this
test");

void NullB(void * misalignedPtr);

// Impl.cpp
#include 

#include "Impl.h"

void B::Null()
{
a.a = nullptr;
a.b = nullptr;
}

void NullB(void * misalignedPtr)
{
B* b = reinterpret_cast(reinterpret_cast(misalignedPtr)
- offsetof(B, misaligned));
b->Null();
}

// main.cpp
#include "Impl.h"

int main()
{
B b;
NullB(&b.misaligned);
return 0;
}


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)

[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases

[ext-borislav.stoyanov at here dot com]

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

gnuBSt  changed:

   What|Removed |Added

 CC||ext-borislav.stoyanov@here.
   ||com

--- Comment #4 from gnuBSt  ---
PS. Any development on this issue?

[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> > Fixed.
> 
> Really? I still see the error
> 
> Error: size of variable 'A.0' is too large

As Richard noted, the code is invalid because n(1) 
is reference but never defined.  n(1) likely contains
garbage.  -Wuninitialized and.or -Wall should probably
catch this, but it currently doesn't.

[Bug rtl-optimization/78186] FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Hmm, looks like it also causes below failures:

aarch64_be-none-elf:
FAIL: gcc.c-torture/execute/pr57130.c   -O1  execution test
FAIL: g++.dg/torture/vshuf-v8si.C -O2 execution test

arm-none-eabi/-marm -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp:
FAIL: c-c++-common/torture/vector-compare-1.c   -O1  execution test
FAIL: c-c++-common/torture/vector-compare-1.c   -O2  execution test
FAIL: c-c++-common/torture/vector-compare-1.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/vector-compare-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/vector-compare-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/vector-compare-1.c   -O3 -g  execution test
FAIL: c-c++-common/torture/vector-compare-1.c   -Os  execution test

I guess bf64-1.c is easier to debug, I can verify these tests once you got a
patch.

Thanks,
bin

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
Regarding arpcom, the syscall package is not really intended to include
everything that seems useful.  That is the goal of the external package
golang.org/x/sys/unix.  The syscall package only includes everything needed by
the standard library, and some functions and types that were there historically
and are now hard to remove.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[tony.reix at atos dot net]

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

--- Comment #8 from Tony Reix  ---
Created attachment 39947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39947&action=edit
Patch for mksysinfo for ucred and in6_addr

Here is the patch I talked about in the previous comment, now as a file.
It is a work-around for enabling me to go further building GCC Go. Probably
that a cleaner and generic solution is required.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Thanks.  Does a patch like this fix the immediate ucred problem?

diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 3640476..6c457b6 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -268,7 +268,7 @@ fi
 # is not empty, the structure or type is renamed to $2.
 upcase_fields () {
   name="$1"
-  def=`grep "^type $name" gen-sysinfo.go`
+  def=`grep "^type $name " gen-sysinfo.go`
   fields=`echo $def | sed -e 's/^[^{]*{\(.*\)}$/\1/'`
   prefix=`echo $def | sed -e 's/{.*//'`
   if test "$2" != ""; then

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[tony.reix at atos dot net]

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

--- Comment #6 from Tony Reix  ---
Created attachment 39946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39946&action=edit
Original sysinfo.go file

Hi Ian

Here is the sysinfo.go file that was generated at first.
The previous sysinfo.go file provided in this bug was the result of a patch in
order to fix some issue and go further.

The faulty line is:
type Ucred struct { Cr_ref int32; Cr_ruid uint32; Cr_uid uint32; Cr_suid
uint32; Cr_luid uint32; Cr_acctid uint32; Cr_gid uint32; Cr_rgid uint32;
Cr_sgid uint32; Cr_ngrps int16; Cr_caps int16; Cr_groupset _groupset_t;
Cr_mpriv _priv_t; Cr_ipriv _priv_t; Cr_epriv _priv_t; Cr_bpriv _priv_t; Cr_pag
int32; } type _ucred_43 struct { ocr_ref int32; Ocr_ruid uint32; Ocr_uid
uint32; Ocr_suid uint32; Ocr_luid uint32; Ocr_acctid uint32; Ocr_gid uint32;
Ocr_rgid uint32; Ocr_sgid uint32; Ocr_ngrps int16; Ocr_groups [31+1]uint32;
Ocr_mpriv _priv_t; Ocr_ipriv _priv_t; Ocr_epriv _priv_t; Ocr_bpriv _priv_t;
Ocr_pag int32; } type _ucred_ext struct { crx_ruid uint32; Crx_uid uint32;
Crx_suid uint32; Crx_luid uint32; Crx_acctid uint32; Crx_gid uint32; Crx_rgid
uint32; Crx_sgid uint32; Crx_ngrps int32; Crx_groups [127+1]uint32;
Crx_reserved_1 int32; Crx_caps ___cap_t; Crx_mpriv _priv_t; Crx_ipriv _priv_t;
Crx_epriv _priv_t; Crx_bpriv _priv_t; Crx_npags int32; Crx_pagids [15+1]uint8;
Crx_pags [15+1]int32; Crx_reserved_2 int32; Crx_roles [7+1]uint32; Crx_nroles
int16; Crx_reserved_3 int16; Crx_flags uint32; Crx_effpriv _privg_t;
Crx_maxpriv _privg_t; Crx_inhpriv _privg_t; Crx_limpriv _privg_t; Crx_usedpriv
_privg_t; Crx_pad [31+1]int32; } type _ucred_ext2_t struct { crx2_labels
_sec_labels_t; Crx_pad [147+1]int32; }

This line contains several definitions, like:
type Ucred struct { ... } type _ucred_43 struct { ... } type _ucred_ext
struct { ... } type _ucred_ext2_t struct { ... }

It appears that, on AIX, there are several ucred* definitions and the tool does
not handle them correctly.

I've written the following patch for working-around the issue:

--- old/libgo/mksysinfo.sh  2016-10-21 10:45:35 +0200
+++ new/libgo/mksysinfo.sh  2016-10-21 11:03:34 +0200
@@ -532,7 +532,8 @@
   field="$f$r"
   nfields="$nfields $field;"
 done
-echo "${prefix} {$nfields }"
+# AIX: For ucred case, split joined lines "...} type ..." into several lines
+echo "${prefix} {$nfields }" | sed -e "s/} type/}\\ntype/g"
   fi
 }

@@ -816,7 +817,12 @@
   sed -e 's/^\(const \)_\(SCM_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}

 # The ucred struct.
-upcase_fields "_ucred" "Ucred" >> ${OUT} || true
+# AIX: In addition to: _ucred , -fdump-go-spec finds also: _ucred_43
_ucred_ext _ucred_ext2
+# AIX: For ucred, several types after first one are duplicated. Print only
first one.
+upcase_fields "_ucred"  "Ucred"  | awk '{print $0; exit}' >> ${OUT} ||
true
+upcase_fields "_ucred_43"   "Ucred_43"   | awk '{print $0; exit}' >> ${OUT} ||
true
+upcase_fields "_ucred_ext"  "Ucred_ext"  | awk '{print $0; exit}' >> ${OUT} ||
true
+upcase_fields "_ucred_ext2" "Ucred_ext2" | awk '{print $0; exit}' >> ${OUT} ||
true

 # The ip_mreq struct.
 grep '^type _ip_mreq ' gen-sysinfo.go | \
@@ -1466,6 +1472,7 @@
 fi

 # Struct sizes.
+# AIX: This generates several ucred lines
 set cmsghdr Cmsghdr ip_mreq IPMreq ip_mreqn IPMreqn ipv6_mreq IPv6Mreq \
 ifaddrmsg IfAddrmsg ifinfomsg IfInfomsg in_pktinfo Inet4Pktinfo \
 in6_pktinfo Inet6Pktinfo inotify_event InotifyEvent linger Linger \


I've found also another issue within mksysinfo.sh on AIX:

The "grep -v 'in6_addr'" command removes definition that seem useful.

--- old/libgo/mksysinfo.sh  2016-10-21 10:45:35 +0200
+++ new/libgo/mksysinfo.sh  2016-10-21 11:03:34 +0200
@@ -299,6 +299,15 @@
   -e 's/\([^a-zA-Z0-9_]\)_timestruc_t\([^a-zA-Z0-9_]\)/\1Timestruc\2/g' \
 >> ${OUT}

+# AIX: The _arpcom struct, removed by previous "grep -v 'in6_addr'"
+grep '^type _arpcom ' gen-sysinfo.go | \
+  sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1Timeval\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timespec\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timestruc_t\([^a-zA-Z0-9_]\)/\1Timestruc\2/g' \
+  -e 's/_in6_addr/[16]byte/' \
+>> ${OUT}
+
 # The errno constants.  These get type Errno.
 echo '#include ' | ${CC} -x c - -E -dM | \
   egrep '#define E[A-Z0-9_]+ ' | \

[Bug bootstrap/78188] New: [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

Bug ID: 78188
   Summary: [7 Regression] AIX Bootstrap broken by tree-vrp.c
change
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

With the tree-vrp.c change of r241774, I encounter the following error during
stage2:

In file included from /nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.c:58:0:
/nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.h: In function 'tree_node*
vn_valueize(tree)':
/nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.h:249:1: error: tree_node*
vn_valueize(tree) causes a section type conflict with tree_node**
gimple_ops(gimple*)
 vn_valueize (tree name)
 ^~~
In file included from /nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.c:27:0:
/nasfarm/edelsohn/src/sandbox/gcc/gimple.h:2360:1: note: 'tree_node**
gimple_ops(gimple*)' was declared here
 gimple_ops (gimple *gs)
 ^~

Analysis continuing...

[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Author: segher
Date: Wed Nov  2 17:06:04 2016
New Revision: 241799

URL: https://gcc.gnu.org/viewcvs?rev=241799&root=gcc&view=rev
Log:
rs6000: Disable shrink-wrap-separate for abi=spe (PR78168)

With the SPE ABI, if we wrap GPRs we need to handle the upper half of the
extended 64-bit registers as well, which we cannot easily do.  So, this
patch disables separate shrink-wrapping for the SPE ABI.


PR target/78168
* config/r6000/rs6000.c (rs6000_get_separate_components): Return
NULL if TARGET_SPE_ABI.

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

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
Thanks.  I do not see any problem in that file you attached.  I also don't see
anything like the line in the original error message.

Looking more closely at that line, I see now that it appears to have several
separate statements stuck together.  Each "type" keyword should appear at the
beginning of a line (this is not required by the Go language, but it is a
result of how sysinfo.go is generated).  And indeed in the sysinfo.go file that
you attached that is what I see.  I think we need to understand why that is not
true in the original report.

sysinfo.go is generated by the script libgo/mksysinfo.sh from the generated
file gen-sysinfo.go.  The file gen-sysinfo.go is generated by running gcc
-fdump-go-spec on sysinfo.c.  Where did things go wrong?

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to fail||5.4.1

--- Comment #3 from Thomas Preud'homme  ---
Bug was introduced in r175605 and thus affect all releases from 4.7 onwards

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED

--- Comment #38 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 7

[Bug other/16996] [meta-bug] code size improvements

[ktkachov at gcc dot gnu.org]

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

Bug 22141 Summary: [5/6/7 Regression] Missing optimization when storing 
structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141

   What|Removed |Added

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

[Bug target/69616] optimization of 8 movb

[ktkachov at gcc dot gnu.org]

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

Bug 22141 Summary: [5/6/7 Regression] Missing optimization when storing 
structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141

   What|Removed |Added

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

[Bug fortran/78187] New: -fno-automatic does not work with allocatable scalar character result result

[nuclearlee at gmail dot com]

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

Bug ID: 78187
   Summary: -fno-automatic does not work with allocatable scalar
character result result
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nuclearlee at gmail dot com
  Target Milestone: ---

Created attachment 39945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39945&action=edit
test.f90 contains a module and a test program to demonstrate described bug.

Summary:
The attached code should returns an allocatable scalar character as a "result".
If I compile without -fno-automtic I get the correct result, if I compile with
-fno-automatic, I get an empty string that is allocated (for gfortran 6.2.0,
5.4.1, and 4.9.4. 4.8.5 gives close to the correct result with some garbage
appended to it). If I instead use the function name to return the result
(instead of using the keyword "result"), the function works with
-fno-automatic).

More details below.

Thanks,
Lee

Detail:
If I compile in Ubuntu using gcc-6.2 (gcc version 6.2.0 20160901 (Ubuntu
6.2.0-3ubuntu11~14.04) using the following command 
$ gfortran-6 -o test.exe test.f90
I get the correct result:
$ ./test.exe
 c|abcdef| T

If I compile using -fno-automatic, however, I get the folowing
$ gfortran-6 -fno-automatic -o test.exe test.f90
I get the correct result:
$ ./test.exe
 c|| T

Also, If I change the function scalar in test_module so that I'm not using
"result", and instead declaring scalar and setting it, it returns the *correct*
result using -fno-automatic, i.e.,
function scalar(a, b) result(c)
character(len=*), intent(in) :: a, b
character(len=:), allocatable :: scalar

scalar = trim(a)//trim(b)

end function scalar


I used a few different versions and -fno-automatic has the same result in all
of them (4.9.4, 5.4.1 and 4.8.5). gfortran 4.8.5 returns the closest to a
correct result (though still incorrect):
$ gfortran-4.8 -fno-automatic -o test.exe test.f90 
$ ./test.exe
 c|abcdef�q�abcdef��| T

[Bug rtl-optimization/78186] FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
Lto is unnecessary to reproduce it:
./gcc bf64-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -w -lm
-o ./bf64-1.exe -march=armv7-a

Thanks,
bin

[Bug fortran/78152] [6/7 Regression] coarray and associate

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Wed, Nov 02, 2016 at 03:39:58PM +, physiker at toast2 dot net wrote:
> 
> Ifort version 17 (linux) supports coarrays as selectors in an associate
> construct: 
> >ifort -o bug bug.f90 -warn all -check all -coarray
> >./bug
> >echo $?
> 0
> >ifort -v
> ifort version 17.0
> 

According the standard (at least under my interpretation
of the standard) it should only support coarray as a
selector under very limited conditions.  I have been in
contact with a member of J3 and sent him an interpretation
request.  Your code should compile because entities in a
main program implicitly have the SAVE attribute.  Changing
your code to a subroutine removes the implicit SAVE.  In
that case, none of the conditions in F2008 C526 are met,
and ifort is required to issue an error.

[Bug gcov-profile/65831] gcov does not output 0% coverage files

[pleskav at ya dot ru]

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

--- Comment #5 from Alex K.  ---
(In reply to Martin Liška from comment #4)
> (In reply to Alex K. from comment #3)
> > I noticed that this bug was fixed on trunk.
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L916
> > 
> > But in branch gcc-4_9-branch
> > https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/gcc/gcov.c#L728
> > gcov.c-file 
> > does not contain this bug fix.
> > 
> > What newest version of GCC  will contain this bug fix?
> 
> GCC 4.9 is not going to have a release. If you are interested, I can
> back-port that to 5 and 6 branch. Are you?

Yes, I am interested.
Please, back-port that to 5 and 6 branch.
Thank you!

[Bug fortran/78152] [6/7 Regression] coarray and associate

[physiker at toast2 dot net]

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

--- Comment #9 from physiker at toast2 dot net ---
(In reply to vehre from comment #8)
> Hi Steve,
> 
> you asked what other compilers have to say to the code (the one in the
> description).
> 
> Ifort:
> 
> > ifort bug.f90 -o bug -coarray
> bug.f90: catastrophic error: **Internal compiler error: segmentation
> violation signal raised** Please report this error along with the
> circumstances in which it occurred in a Software Problem Report.  Note: File
> and line given may not be explicit cause of this error.
> compilation aborted for bug.f90 (code 1)
> > ifort -v
> ifort version 15.0.1
> 


Ifort version 17 (linux) supports coarrays as selectors in an associate
construct: 
>ifort -o bug bug.f90 -warn all -check all -coarray
>./bug
>echo $?
0
>ifort -v
ifort version 17.0

[Bug rtl-optimization/78186] New: FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664

[amker at gcc dot gnu.org]

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

Bug ID: 78186
   Summary: FAIL: gcc.c-torture/execute/bf64-1.c execution test
because of revision 241664
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Hi, below commit

commit 17fc6eeba9352b97ba16d64fd1de9a5bdc081062
Author: segher 
Date:   Fri Oct 28 20:56:28 2016 +

combine: Improve change_zero_ext (fixes PR71847)

This improves a few things in change_zero_ext.  Firstly, it should use
the passed in pattern in recog_for_combine, not the pattern of the insn
(they are not the same if the whole pattern was replaced).  Secondly,
it handled zero_ext of a subreg, but with hard registers we do not get
a subreg, instead the mode of the reg is changed.  So this handles that.
Thirdly, after changing a zero_ext to an AND, the resulting RTL may become
non-canonical, like (ior (ashift ..) (and ..)); the AND should be first,
it is commutative.  And lastly, zero_extract as a set_dest wasn't handled
at all, but now it is.

This fixes the testcase in PR71847, and improves code generation in some
other edge cases too.


PR target/71847
* combine.c (change_zero_ext): Handle zero_ext of hard registers.
Swap commutative operands in new RTL if needed.  Handle zero_ext
in the set_dest.
(recog_for_combine): Pass *pnewpat to change_zero_ext instead of
PATTERN (insn).


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241664
138bc75d-0d04-0410-961f-82ee72b054a4

causes test case failure on arm-none-linux-gnueabihf target:
FAIL: gcc.c-torture/execute/bf64-1.c -O1 execution test

GCC is configured as:
../gcc/configure --prefix=... --enable-languages=c,c++,fortran
--disable-bootstrap --disable-libsanitizer --disable-libgomp --disable-libitm
--disable-libssp --with-tune=cortex-a15 --with-fpu=neon --with-float=hard

Test is compiled as:
./gcc bf64-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects -w -lm -o ./bf64-1.exe -march=armv7-a

also fails with -O1 optimization level.

Thanks,
bin

[Bug gcov-profile/65831] gcov does not output 0% coverage files

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Alex K. from comment #3)
> I noticed that this bug was fixed on trunk.
> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L916
> 
> But in branch gcc-4_9-branch
> https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/gcc/gcov.c#L728
> gcov.c-file 
> does not contain this bug fix.
> 
> What newest version of GCC  will contain this bug fix?

GCC 4.9 is not going to have a release. If you are interested, I can back-port
that to 5 and 6 branch. Are you?

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to fail||6.2.1

--- Comment #4 from Thomas Preud'homme  ---
Add known fail for older releases and wrong-code tag.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #54 from Bernd Edlinger  ---
(In reply to richard.earnshaw from comment #53)
> On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
> > 
> > --- Comment #52 from Bernd Edlinger  ---
> > (In reply to wilco from comment #51)
> >>
> >> Indeed, that's the reason behind the existing check. However it disables 
> >> all
> >> profitable bswap cases while still generating unaligned accesses if no 
> >> bswap
> >> is needed. So I am looking for a callback that gives the correct answer. It
> >> would need to check -mno-unaligned-access and the target capabilities (eg.
> >> if unaligned accesses are supported in hardware but really expensive we 
> >> want
> >> to avoid them).
> > 
> > Yes.  I think ARM is becoming a non-strict-alignment platform.
> > While x86_64 is moving in the opposite direction.
> 
> It can never be a non-strict alignment platform while some memory access
> instructions do not support unaligned accesses.
> 
> However, it is progressively becoming a less slow unaligned access platform.
> 


But isn't that exactly the same situation for x86_64:
Most instructions support unaligned memory accesses,
and a few data types need a movmisalign_optab ?

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> I suppose the easiest would be to simply not try moving trapping invariants
> in RTL invariant motion, it looks hardly useful after GIMPLE was here...

IIRC last time someone tried, this badly regressed gzip.

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

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

--- Comment #5 from Will Schmidt  ---
Patches committed to trunk, and backported to both gcc-5 and gcc-6 branches.  
all fixed. :-)

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to fail||4.7.4, 4.8.5, 4.9.3

--- Comment #4 from Thomas Preud'homme  ---
Add known to fail version for unsupported releases as well.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
Created attachment 39944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39944&action=edit
sysinfo.go

Generated sysinfo.go file attached.

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Better patch (question answered, we walk all BBs of each loop, thus BBs in
sub-loop multiple times, and no, finite_loop_p would not catch infinite
subloops):

diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 463db04..0524e57 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "trans-mem.h"
 #include "gimple-fold.h"
 #include "tree-scalar-evolution.h"
+#include "tree-ssa-loop-niter.h"

 /* TODO:  Support for predicated code motion.  I.e.

@@ -2369,8 +2370,16 @@ fill_always_executed_in_1 (struct loop *loop, sbitmap
contains_call)
break;

  FOR_EACH_EDGE (e, ei, bb->succs)
-   if (!flow_bb_inside_loop_p (loop, e->dest))
- break;
+   {
+ /* If there is an exit from this BB.  */
+ if (!flow_bb_inside_loop_p (loop, e->dest))
+   break;
+ /* Or we enter a possibly non-finite loop.  */
+ if (flow_loop_nested_p (bb->loop_father,
+ e->dest->loop_father)
+ && ! finite_loop_p (e->dest->loop_father))
+   break;
+   }
  if (e)
break;

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So for RTL the same issue exists - the always_reached computation is wrong.

I suppose the easiest would be to simply not try moving trapping invariants in
RTL invariant motion, it looks hardly useful after GIMPLE was here...

diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
index 551103f..deb5be6 100644
--- a/gcc/loop-invariant.c
+++ b/gcc/loop-invariant.c
@@ -1076,7 +1076,7 @@ pre_check_invariant_p (bool simple, rtx dest)
unless the program ends due to a function call.  */

 static void
-find_invariant_insn (rtx_insn *insn, bool always_reached, bool
always_executed)
+find_invariant_insn (rtx_insn *insn, bool, bool always_executed)
 {
   df_ref ref;
   struct def *def;
@@ -1108,8 +1108,8 @@ find_invariant_insn (rtx_insn *insn, bool always_reached,
bool always_executed)
   if (can_throw_internal (insn))
 return;

-  /* We cannot make trapping insn executed, unless it was executed before.  */
-  if (may_trap_or_fault_p (PATTERN (insn)) && !always_reached)
+  /* We cannot make trapping insn executed.  */
+  if (may_trap_or_fault_p (PATTERN (insn)))
 return;

   depends_on = BITMAP_ALLOC (NULL);


dead code removal possible here (always_reached computation, eventually
always_executed as well).

Now have to devise a testcase... (raise a timeout signal, verify it is
catched?)

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 463db04..a89cabf 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "trans-mem.h"
 #include "gimple-fold.h"
 #include "tree-scalar-evolution.h"
+#include "tree-ssa-loop-niter.h"

 /* TODO:  Support for predicated code motion.  I.e.

@@ -2369,8 +2370,17 @@ fill_always_executed_in_1 (struct loop *loop, sbitmap
contains_call)
break;

  FOR_EACH_EDGE (e, ei, bb->succs)
-   if (!flow_bb_inside_loop_p (loop, e->dest))
- break;
+   {
+ /* If there is an exit from this BB.  */
+ if (!flow_bb_inside_loop_p (loop, e->dest))
+   break;
+ /* Or we enter a possibly non-finite loop.
+???  Does that reliably detect infinite child loops
+inside the child loop?  */
+ if (e->dest->loop_father != loop
+ && ! finite_loop_p (e->dest->loop_father))
+   break;
+   }
  if (e)
break;


fixes the invariant motion on the GIMPLE level (at quite some cost generally
I would assume, finite_loop_p is quite conservative).  RTL invariant motion
still messes things up then though...  (CCing rtl opt maintainer)

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Nope.

  if (TREE_CODE (lhs) != SSA_NAME
  || gimple_could_trap_p (stmt))
return MOVE_PRESERVE_EXECUTION;

But then LIM fails to check whether the exit of the nested loop is ever taken
(it infinitely loops).

Thus that LIM logic has a flaw.  It marks that block as always executed in the
outer loop.  Thus the bug is in fill_always_executed_in[_1].

A tiny bit academic as it requires a never terminating inner loop, but well.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[richard.earnshaw at arm dot com]

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

--- Comment #53 from richard.earnshaw at arm dot com ---
On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
> 
> --- Comment #52 from Bernd Edlinger  ---
> (In reply to wilco from comment #51)
>>
>> Indeed, that's the reason behind the existing check. However it disables all
>> profitable bswap cases while still generating unaligned accesses if no bswap
>> is needed. So I am looking for a callback that gives the correct answer. It
>> would need to check -mno-unaligned-access and the target capabilities (eg.
>> if unaligned accesses are supported in hardware but really expensive we want
>> to avoid them).
> 
> Yes.  I think ARM is becoming a non-strict-alignment platform.
> While x86_64 is moving in the opposite direction.

It can never be a non-strict alignment platform while some memory access
instructions do not support unaligned accesses.

However, it is progressively becoming a less slow unaligned access platform.

R.

Re: [Bug target/77308] surprisingly large stack usage for sha512 on arm

[Richard Earnshaw (lists)]

On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
> 
> --- Comment #52 from Bernd Edlinger  ---
> (In reply to wilco from comment #51)
>>
>> Indeed, that's the reason behind the existing check. However it disables all
>> profitable bswap cases while still generating unaligned accesses if no bswap
>> is needed. So I am looking for a callback that gives the correct answer. It
>> would need to check -mno-unaligned-access and the target capabilities (eg.
>> if unaligned accesses are supported in hardware but really expensive we want
>> to avoid them).
> 
> Yes.  I think ARM is becoming a non-strict-alignment platform.
> While x86_64 is moving in the opposite direction.

It can never be a non-strict alignment platform while some memory access
instructions do not support unaligned accesses.

However, it is progressively becoming a less slow unaligned access platform.

R.

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

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

--- Comment #4 from Will Schmidt  ---
Author: willschm
Date: Wed Nov  2 14:13:07 2016
New Revision: 241793

URL: https://gcc.gnu.org/viewcvs?rev=241793&root=gcc&view=rev
Log:
[gcc]

2016-11-02  Will Schmidt 

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* gimplify.c (gimplify_init_constructor): Move emit of constructor
assignment to earlier in the if/else logic.

[gcc/testsuite]

2016-11-02  Will Schmidt  

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* c-c++-common/pr72747-1.c: New test.
* c-c++-common/pr72747-2.c: Likewise.


Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr72747-1.c
branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr72747-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimplify.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[willschm at gcc dot gnu.org]

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

--- Comment #3 from Will Schmidt  ---
Author: willschm
Date: Wed Nov  2 14:12:23 2016
New Revision: 241792

URL: https://gcc.gnu.org/viewcvs?rev=241792&root=gcc&view=rev
Log:
[gcc]

2016-11-02  Will Schmidt 

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* gimplify.c (gimplify_init_constructor): Move emit of constructor
assignment to earlier in the if/else logic.

[gcc/testsuite]

2016-11-02  Will Schmidt  

Backport from trunk
2016-10-26  Will Schmidt 

PR middle-end/72747
* c-c++-common/pr72747-1.c: New test.
* c-c++-common/pr72747-2.c: Likewise.


Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr72747-1.c
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr72747-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-02
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
lim2 not checking that the statement may trap before pulling it?

[Bug gcov-profile/65831] gcov does not output 0% coverage files

[pleskav at ya dot ru]

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

Alex K.  changed:

   What|Removed |Added

 CC||pleskav at ya dot ru

--- Comment #3 from Alex K.  ---
I noticed that this bug was fixed on trunk.
https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L916

But in branch gcc-4_9-branch
https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/gcc/gcov.c#L728
gcov.c-file 
does not contain this bug fix.

What newest version of GCC  will contain this bug fix?

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org

--- Comment #3 from Thomas Preud'homme  ---
Working on a patch.

[Bug tree-optimization/78185] New: Wrong branch optimization with -O1 on x86/x86_64

[mdaniels at qnx dot com]

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

Bug ID: 78185
   Summary: Wrong branch optimization with -O1 on x86/x86_64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdaniels at qnx dot com
  Target Milestone: ---

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

The attached test case is being incorrectly optimized on x86/x86_64 with -O1 or
above.

$ gcc -O1 -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -Wall
-Wextra -o /tmp/test /tmp/test.c 
$ /tmp/test
Floating point exception (core dumped)

The test case is reduced from csmith output.

Looking at the resulting assembly, it seems like the wrong branch is being
optimized away. Since it takes the wrong branch it ends up trying to divide by
zero.

I had also tried with armv7 and aarch64, which kept both branches so the
problem was not seen on those archs.

Tested on a Linux x86_64 host with GCC 5.4 and ToT.

[Bug c++/78184] New: std::call_once freezes on second execution if the callable threw an exception on first execution

[simon.heybrock at esss dot se]

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

Bug ID: 78184
   Summary: std::call_once freezes on second execution if the
callable threw an exception on first execution
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.heybrock at esss dot se
  Target Milestone: ---

=== Overview ===

If the callable in std::call_once throws an exception, a subsequent execution
of std::call_once causes a freeze.

Error observed with:
- gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)
- g++ (GCC) 6.2.1 20160830

Works with:
- g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)


=== Example 1 ===

Compiled with: g++ --std=c++11 -fopenmp


#include 
#include 
#include 

struct Cache {
  mutable std::once_flag flag;
  void cache() const {
std::cout << "caching...\n";
throw std::runtime_error("error");
  }
  void freeze() const {
std::cout << "freeze?\n";
std::call_once(flag, &Cache::cache, this);
  }
};

int main() {
  Cache cache;
  try {
cache.freeze();
  } catch (std::runtime_error &) {
  }
  try {
cache.freeze();
  } catch (std::runtime_error &) {
  }
}


# Expected output:
freeze?
caching...
freeze?
caching...

# Actual output:
freeze?
caching...
freeze?
^C


=== Example 2 ===

A similar, slightly longer example can be found at
http://en.cppreference.com/w/cpp/thread/call_once.

# Expected output:
Simple example: called once
throw: call_once will retry
throw: call_once will retry
Didn't throw, call_once will not attempt again

# Actual output:
Simple example: called once
throw: call_once will retry
^C


=== Details ===

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

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.1
 Resolution|--- |FIXED

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

[Bug tree-optimization/77839] [6 Regression] Memory- and compile time hog at -O1 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.1
 Resolution|--- |FIXED
  Known to fail||6.2.0

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

[Bug tree-optimization/77879] [5/6 Regression] mpd gets miscompiled since r235622

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  2 12:47:10 2016
New Revision: 241788

URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev
Log:
2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-pre.c
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug middle-end/78047] [5/6 Regression] Chromium apparently gets miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  2 12:47:10 2016
New Revision: 241788

URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev
Log:
2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-pre.c
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  2 12:47:10 2016
New Revision: 241788

URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev
Log:
2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-pre.c
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug tree-optimization/77839] [6 Regression] Memory- and compile time hog at -O1 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  2 12:47:10 2016
New Revision: 241788

URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev
Log:
2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-pre.c
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug tree-optimization/77745] [5/6 Regression] Inconsistent application of aliasing rules

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  2 12:47:10 2016
New Revision: 241788

URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev
Log:
2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-pre.c
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug tree-optimization/77648] [5/6 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  2 12:47:10 2016
New Revision: 241788

URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev
Log:
2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-pre.c
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug fortran/78152] [6/7 Regression] coarray and associate

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Hi Steve,

you asked what other compilers have to say to the code (the one in the
description).

Ifort:

> ifort bug.f90 -o bug -coarray
bug.f90: catastrophic error: **Internal compiler error: segmentation violation
signal raised** Please report this error along with the circumstances in which
it occurred in a Software Problem Report.  Note: File and line given may not be
explicit cause of this error.
compilation aborted for bug.f90 (code 1)
> ifort -v
ifort version 15.0.1

While Cray say:

>ftn bug.f90 -o bug
>ftn -V
Cray Fortran : Version 8.5.1  Wed Nov 02, 2016  05:35:28

I can't run the resulting executable though, because some runtime library is
reported missing (I don't get how to setup it up correctly).

Changing the program to subroutine has no effect.

- Andre

[Bug c/78183] New: Silence warnings about alternate forms of custom format specifiers

[drazen.kacar at tereo dot hr]

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

Bug ID: 78183
   Summary: Silence warnings about alternate forms of custom
format specifiers
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drazen.kacar at tereo dot hr
  Target Milestone: ---

Glibc allows writing custom printf format conversions, so I've implemented a
conversion which takes char * and prints the string with all non-printable
characters in \xxx notation. This is very useful for printing debugging
output (I'm currently writing a lot of unit tests) and logging.

However, if I register it with unused conversion specifier (eg. %W) then gcc
produces a warning. This has already been reported in bug 47781, but doesn't
look like it will be resolved soon.

Another option is to use %s and implement my version as an alternate form,
so it would be used with the %#s specifier. Then the compiler would now how to
check arguments without any code modifications. However, if I do this gcc
warns about '#' flag being used with %s.

For example (function which implements conversion not shown):

prompt> tail -17 myprintf.c 
int
main()
{
char *str = "burek\r\n";

printf("Before registering: %#s\n", str);
if(register_printf_specifier ('s', str_log, str_log_arginfo))
{
fputs("Cannot register %s specifier", stderr);
exit(1);
}

printf("%s\n", str);
printf("%#s\n", str);

return 0;
}

prompt> gcc -o myprintf myprintf.c
myprintf.c: In function 'main':
myprintf.c:94:12: warning: '#' flag used with '%s' gnu_printf format
[-Wformat=]
 printf("Before registering: %#s\n", str);
^
myprintf.c:102:12: warning: '#' flag used with '%s' gnu_printf format
[-Wformat=]
 printf("%#s\n", str);
^

prompt> ./myprintf 
Before registering: burek

burek

burek\r\n

=== End example ===

While we're waiting for the full implementation of the problem from bug 47781
would it be possible to implement something that would silence warnings for
alternate forms which aren't specified by a standard?

I can see two approaches:
a) Don't produce warning about this by default and introduce a compiler flag to
turn it on.
b) Introduce another compiler flag (eg. -Wno-format-alt-flag) which would
silence this specific warning.

I tried to find command line option which would disable specific warning
identified by a number or a name, but couldn't find it.

[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Wed, 2 Nov 2016, dominiq at lps dot ens.fr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77679
> 
> --- Comment #8 from Dominique d'Humieres  ---
> > Fixed.
> 
> Really? I still see the error
> 
> Error: size of variable 'A.0' is too large

The ICE is gone and the testcase is invalid (well, the reporter says so).

Maybe the FE can better diagnose this but this wouldn't be a regression.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #52 from Bernd Edlinger  ---
(In reply to wilco from comment #51)
> 
> Indeed, that's the reason behind the existing check. However it disables all
> profitable bswap cases while still generating unaligned accesses if no bswap
> is needed. So I am looking for a callback that gives the correct answer. It
> would need to check -mno-unaligned-access and the target capabilities (eg.
> if unaligned accesses are supported in hardware but really expensive we want
> to avoid them).

Yes.  I think ARM is becoming a non-strict-alignment platform.
While x86_64 is moving in the opposite direction.

Would it be possible to handle the STRICT_ALIGNMENT switchable
like int the rs6000, in that case you have also more flexibility
in the handling of SLOW_UNALIGNED_ACCESS macro ?

[Bug fortran/78062] sinus and cosinus fails

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Dominique d'Humieres  ---
No feedback. Closing as WORKSFORME.

[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Fixed.

Really? I still see the error

Error: size of variable 'A.0' is too large

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #12)
> (In reply to Markus Trippelsdorf from comment #11)
> > js/src/jit/BaselineCompiler.cpp
> 
> Hm, I see the R0 defined as:
> 
> # 1
> "/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/
> SharedICRegisters-x64.h" 1
> # 12
> "/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/
> SharedICRegisters-x64.h"
> namespace js {
> namespace jit {
> 
> static constexpr Register BaselineFrameReg = rbp;
> static constexpr Register BaselineStackReg = rsp;
> 
> static constexpr ValueOperand R0(rcx);
> 
> not as an ASM statement.

Yes, you're right. I only took a cursory look and got confused by all these
masm. statements.
Not sure how to debug this further.

[Bug tree-optimization/61056] strchr (x, 0) is not converted to strlen (x)

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from wilco at gcc dot gnu.org ---
Fixed in r240568.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[wilco at gcc dot gnu.org]

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

--- Comment #51 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #49)
> (In reply to Bernd Edlinger from comment #48)
> > (In reply to wilco from comment #22)
> > > 
> > > Anyway, there is another bug: on AArch64 we correctly recognize there are 
> > > 8
> > > 1-byte loads, shifts and orrs which can be replaced by a single 8-byte 
> > > load
> > > and a byte reverse. Although it is recognized on ARM and works correctly 
> > > if
> > > it is a little endian load, it doesn't perform the optimization if a byte
> > > reverse is needed. As a result there are lots of 64-bit shifts and orrs
> > > which create huge register pressure if not expanded early.
> > 
> > Hmm...
> > 
> > I think the test case does something invalid here:
> > 
> > const SHA_LONG64 *W = in;
> > 
> > T1 = X[0] = PULL64(W[0]);
> > 
> > 
> > in is not aligned, but it is cast to a 8-byte aligned type.
> > 
> > If the bswap pass assumes with your proposed patch
> > it is OK to merge 4 byte accesses into an aligned word access,
> > it may likely break openssl on -mno-unaligned targets.
> > Even on our cortex-a9 the O/S will trap on unaligned accesses.
> > I have checked that openssl still works on arm-none-eabi 
> > with my patch, but I am not sure about your patch.
> 
> I tried it out.  Although the code is bogus the code generation
> does not use the wrong alignment.
> 
> With -mno-unaligned-access the ldr is split out into 4 ldb and
> the result is fed into the rev.
>
> At least in this configuration that is not profitable though.

Indeed, that's the reason behind the existing check. However it disables all
profitable bswap cases while still generating unaligned accesses if no bswap is
needed. So I am looking for a callback that gives the correct answer. It would
need to check -mno-unaligned-access and the target capabilities (eg. if
unaligned accesses are supported in hardware but really expensive we want to
avoid them).

[Bug tree-optimization/78182] Missed optimizations: "fused" byte stores

[rureclonic at thraml dot com]

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

--- Comment #3 from Rurec Lonic  ---
Fantastic. Thanks for this, and next time I'll make sure to pull the very
latest revision!.

[Bug tree-optimization/78182] Missed optimizations: "fused" byte stores

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Heh, please try r241649 or later.
I now get:
movabsq $3472328296227680304, %rax
movl$825241648, text+8(%rip)
movq%rax, text(%rip)
ret

[Bug debug/49775] [5/6/7 Regression] on AVR ICE in based_loc_descr

[saaadhu at gcc dot gnu.org]

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |4.9.0

--- Comment #15 from Senthil Kumar Selvaraj  ---
Fixed by r208045 a while back. 4.9.0 onwards has the fix

[Bug tree-optimization/78182] Missed optimizations: "fused" byte stores

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Richard Biener  ---
They are now:

_Z3foov:
.LFB0:
.cfi_startproc
movabsq $3472328296227680304, %rax
movl$825241648, text+8(%rip)
movq%rax, text(%rip)
ret

since store-merging was merged (Oct 28)

[Bug tree-optimization/78182] New: Missed optimizations: "fused" byte stores

[rureclonic at thraml dot com]

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

Bug ID: 78182
   Summary: Missed optimizations: "fused" byte stores
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rureclonic at thraml dot com
  Target Milestone: ---

Consider the following program, which writes '0001' in `text`.

  constexpr unsigned long Size = 12;
  char text[Size];

  void foo() {
auto value = 1u;

for (auto i = 0ul; i < Size; ++i) {
  text[Size - i - 1] = (value % 10) + '0';
  value /= 10;
}
  }

The codegen for foo with `g++-7 -std=c++1z -O3 -march=corei7-avx` is:

  foo():
mov BYTE PTR text[rip+11], 49
mov BYTE PTR text[rip+10], 48
mov BYTE PTR text[rip+9], 48
mov BYTE PTR text[rip+8], 48
mov BYTE PTR text[rip+7], 48
mov BYTE PTR text[rip+6], 48
mov BYTE PTR text[rip+5], 48
mov BYTE PTR text[rip+4], 48
mov BYTE PTR text[rip+3], 48
mov BYTE PTR text[rip+2], 48
mov BYTE PTR text[rip+1], 48
mov BYTE PTR text[rip], 48
ret

Why can't the 9 last movs be combined into wider stores?

[Bug target/63752] avr ICE at reload1.c:2128 building newlib

[saaadhu at gcc dot gnu.org]

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

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

--- Comment #1 from Senthil Kumar Selvaraj  ---
Couldn't reproduce this on 5.1.0 or trunk

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #11)
> js/src/jit/BaselineCompiler.cpp

Hm, I see the R0 defined as:

# 1
"/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/SharedICRegisters-x64.h"
1
# 12
"/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/SharedICRegisters-x64.h"
namespace js {
namespace jit {

static constexpr Register BaselineFrameReg = rbp;
static constexpr Register BaselineStackReg = rsp;

static constexpr ValueOperand R0(rcx);

not as an ASM statement.

[Bug c/78181] unrecognized option -mcpu=cortex-a73

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
The error message comes from the assembler, not the compiler, you need to
update your assembler binaries.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[rearnsha at gcc dot gnu.org]

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

--- Comment #50 from Richard Earnshaw  ---
(In reply to wilco from comment #47)
> (In reply to Richard Earnshaw from comment #46)
> > (In reply to wilco from comment #44)
> > > (In reply to Bernd Edlinger from comment #38)
> > > > Created attachment 39939 [details]
> > > > proposed patch, v2
> > > > 
> > > 
> > > > Unlike the previous patch, thumb1 stack usage stays at 1588 bytes,
> > > > because thumb1 cannot split the adddi3 pattern, once it is emitted.
> > > 
> > > We can split into a new pattern that contains adds/adc together. Splitting
> > > should help Thumb-1 the most as it has just 3 allocatable DI mode
> > > registers...
> > 
> > Not on Thumb-1 we can't.  Because of register allocation limitations, we
> > cannot expose the flags until after register allocation has completed. 
> > (Since the register allocator needs to be able to insert loads, adds and
> > copy instructions between any two insns.  The add and copy instructions
> > clobber the flags, making early splitting impossible.
> 
> What I meant is splitting into a single new instruction using SI mode
> registers rather than DI mode registers so that register allocation is more
> efficient.

You couldn't do that before combine, since the pattern would have to describe
setting both 'result' registers independently.  That would create a pattern
that combine couldn't handle (more than one non-flag result) and so that in
turn would stop the compiler being able to optimize such a pattern properly. 
Note the pattern would probably end up looking like a parallel that set high
and low parts to the result of the 64-bit operation.

It might help to rewrite the pattern that way after combine, but before
register allocation.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
js/src/jit/BaselineCompiler.cpp

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #49 from Bernd Edlinger  ---
(In reply to Bernd Edlinger from comment #48)
> (In reply to wilco from comment #22)
> > 
> > Anyway, there is another bug: on AArch64 we correctly recognize there are 8
> > 1-byte loads, shifts and orrs which can be replaced by a single 8-byte load
> > and a byte reverse. Although it is recognized on ARM and works correctly if
> > it is a little endian load, it doesn't perform the optimization if a byte
> > reverse is needed. As a result there are lots of 64-bit shifts and orrs
> > which create huge register pressure if not expanded early.
> 
> Hmm...
> 
> I think the test case does something invalid here:
> 
> const SHA_LONG64 *W = in;
> 
> T1 = X[0] = PULL64(W[0]);
> 
> 
> in is not aligned, but it is cast to a 8-byte aligned type.
> 
> If the bswap pass assumes with your proposed patch
> it is OK to merge 4 byte accesses into an aligned word access,
> it may likely break openssl on -mno-unaligned targets.
> Even on our cortex-a9 the O/S will trap on unaligned accesses.
> I have checked that openssl still works on arm-none-eabi 
> with my patch, but I am not sure about your patch.

I tried it out.  Although the code is bogus the code generation
does not use the wrong alignment.

With -mno-unaligned-access the ldr is split out into 4 ldb and
the result is fed into the rev.

At least in this configuration that is not profitable though.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #9)
> (In reply to Martin Liška from comment #8)
> > (In reply to Markus Trippelsdorf from comment #7)
> > > BTW Firefox trunk fails to build for me:
> > > 
> > > ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32
> > > reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile
> > > with -fPIC
> > > ld: error: read-only segment has dynamic relocations
> > > /tmp/ccsbLieS.ltrans29.ltrans.o::function
> > > js::jit::BaselineCompiler::emitCheckThis(js::jit::ValueOperand) [clone
> > > .constprop.20226]: error: undefined reference to 'js::jit::R0'
> > > 
> > > Haven't looked into it yet. Could well be a Firefox bug.
> > 
> > This looks known to me, I used to see this unresolved symbol, but currently
> > it's gone on x86_64-linux-gnu.
> 
> Not for me. I hit the issue yesterday with gcc trunk and mozilla trunk.
> js::jit::R0 is an asm statement, that could end up in the wrong partition.

Ah, I see. Can you please name the source file where's it's defined? Can't grep
the symbol.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #8)
> (In reply to Markus Trippelsdorf from comment #7)
> > BTW Firefox trunk fails to build for me:
> > 
> > ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32
> > reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile
> > with -fPIC
> > ld: error: read-only segment has dynamic relocations
> > /tmp/ccsbLieS.ltrans29.ltrans.o::function
> > js::jit::BaselineCompiler::emitCheckThis(js::jit::ValueOperand) [clone
> > .constprop.20226]: error: undefined reference to 'js::jit::R0'
> > 
> > Haven't looked into it yet. Could well be a Firefox bug.
> 
> This looks known to me, I used to see this unresolved symbol, but currently
> it's gone on x86_64-linux-gnu.

Not for me. I hit the issue yesterday with gcc trunk and mozilla trunk.
js::jit::R0 is an asm statement, that could end up in the wrong partition.

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed.
Thanks for the report

[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Nov  2 09:28:35 2016
New Revision: 241779

URL: https://gcc.gnu.org/viewcvs?rev=241779&root=gcc&view=rev
Log:
PR tree-optimization/78170: Truncate sign-extended padding when encoding
bitfields

PR tree-optimization/78170
* gimple-ssa-store-merging.c (encode_tree_to_bitpos): Truncate padding
introduced by native_encode_expr on little-endian as well.

* gcc.c-torture/execute/pr78170.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr78170.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78162] [7 Regression] ICE on invalid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Fixed. Thanks for the report