[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[doko at gcc dot gnu.org]

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

--- Comment #9 from Matthias Klose  ---
yes, that's fixing it

[Bug tree-optimization/82291] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 82291
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It should be a recent regression as 7.2.0 does not miscompile the test. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170921 (experimental) [trunk revision 253084] (GCC)
$
$ gcc-7.2.0 -O3 small.c; ./a.out
0
$ gcctk -O2 small.c; ./a.out
0
$
$ gcctk -O3 small.c
$ ./a.out
1
$


---


int printf (const char *, ...);

int a, c, d, *h;
unsigned b;

int *fn1 ()
{ 
  int *f[3], g = 0;
  for (; g < 3; g++)
f[g] = 
  if (--b > a)
{ 
  if (a > b)
d++;
  return f[0];
}
}

void fn2 ()
{ 
  for (; c >= 0; --c)
{ 
  int j[] = { 0, 0, 0, 0, 0 };
  int *k = fn1 ();
  if (!k)
__builtin_abort ();
  h = [4];
}
}

int main ()
{ 
  fn2 ();
  printf ("%d\n", d);
  return 0;
}

[Bug rtl-optimization/82290] New: ICE at -O2 on x86_64-linux-gnu: verify_flow_info failed

[su at cs dot ucdavis.edu]

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

Bug ID: 82290
   Summary: ICE at -O2 on x86_64-linux-gnu: verify_flow_info
failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170921 (experimental) [trunk revision 253084] (GCC)
$
$ gcctk -Os -c small.c
$
$ gcctk -O2 -c small.c
small.c: In function ‘fn1’:
small.c:35:1: error: non-cold basic block 6 reachable only by paths crossing
the cold partition
 }
 ^
during RTL pass: bbro
small.c:35:1: internal compiler error: verify_flow_info failed
0x7f12ce verify_flow_info()
../../gcc-source-trunk/gcc/cfghooks.c:259
0x8080d4 checking_verify_flow_info
../../gcc-source-trunk/gcc/cfghooks.h:198
0x8080d4 cfg_layout_finalize()
../../gcc-source-trunk/gcc/cfgrtl.c:4314
0x13552f9 execute
../../gcc-source-trunk/gcc/bb-reorder.c:2601
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


-


int printf (const char *, ...);

struct
{ 
  int a:2;
} b;

int c, e, h, i;
unsigned j;
long d, g;
volatile int f;

void fn1 ()
{ 
  while (1)
while (1)
  { 
if (h)
  break;
int l;
if (i)
  {
  L:
j = b.a;
g = (g ^ (f && e)) / (c && b.a / (j && d));
e = (g && b.a) & (j || f);
if (!l)
  { 
printf ("%ld\n", g);
goto L;
  }
  }
b.a = j;
  }
}

[Bug tree-optimization/82289] New: ICE at -O3 on x86_64-linux-gnu: in vect_get_num_copies, at tree-vectorizer.h:1093

[su at cs dot ucdavis.edu]

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

Bug ID: 82289
   Summary: ICE at -O3 on x86_64-linux-gnu: in
vect_get_num_copies, at tree-vectorizer.h:1093
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170921 (experimental) [trunk revision 253084] (GCC)
$
$ gcctk -O2 -c small.c
$
$ gcctk -O3 -c small.c
during GIMPLE pass: vect
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: in vect_get_num_copies, at
tree-vectorizer.h:1093
 void fn1 (int *j)
  ^~~
0x14b2236 vect_get_num_copies
../../gcc-source-trunk/gcc/tree-vectorizer.h:1092
0x14b2236 vect_get_data_access_cost
../../gcc-source-trunk/gcc/tree-vect-data-refs.c:1195
0x14b2236 vect_get_peeling_costs_all_drs
../../gcc-source-trunk/gcc/tree-vect-data-refs.c:1339
0x14bf48e vect_enhance_data_refs_alignment(_loop_vec_info*)
../../gcc-source-trunk/gcc/tree-vect-data-refs.c:1797
0xefe706 vect_analyze_loop_2
../../gcc-source-trunk/gcc/tree-vect-loop.c:2018
0xefe706 vect_analyze_loop(loop*, _loop_vec_info*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:2354
0xf170e5 vectorize_loops()
../../gcc-source-trunk/gcc/tree-vectorizer.c:685
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


-


int a, b, c, *d, *f[1];

void fn1 (int *j)
{ 
  int e, g, h = 1;
  for (; e; e++)
{ 
  if (g > 0)
{ 
  d = j;
  return;
}
  if (!h)
while (g)
  ;
  while (h < 1)
if (a)
  { 
fn1 ();
h = 0;
  }
  f[e] = 
}
  while (1)
;
}

[Bug libstdc++/82287] When compiling with O2 or O3, memory model rejected

[geof.sawaya at oculus dot com]

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

Geof Sawaya  changed:

   What|Removed |Added

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

--- Comment #1 from Geof Sawaya  ---
Woops.  I asked for an improper situation, so I withdraw my bug report

[Bug c++/82288] New: Defining a type in a parameter type of a lambda calling an undefined function results in a Segfault

[jasper at mezzo dot de]

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

Bug ID: 82288
   Summary: Defining a type in a parameter type of a lambda
calling an undefined function results in a Segfault
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jasper at mezzo dot de
  Target Milestone: ---

This very simple (though incorrect) piece of code produces a segfault:

-
int main() {
  [](struct {} *arg) { a();};
}
-
$ c++ mnwe.cpp
mnwe.cpp: In function ‘int main()’:
mnwe.cpp:2:13: error: types may not be defined in parameter types
   [](struct {} *arg) { a();};
 ^
c++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The segfault goes away if any one of these are done:
 - define a() somewhere
 - replace the `struct {}` in the parameter list with `int`
 - define a function instead of the lambda



System Information:
System Type: Arch Linux
GCC version: 7.2.0 (package version 7.2.0-3)
Output of c++ -v:
$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (GCC)

[Bug libstdc++/82287] New: When compiling with O2 or O3, memory model rejected

[geof.sawaya at oculus dot com]

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

Bug ID: 82287
   Summary: When compiling with O2 or O3, memory model rejected
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geof.sawaya at oculus dot com
  Target Milestone: ---

g++ testThreadSpawnTime.cpp -o testThreadSpawnTime   -std=c++11 -O3 
In file included from /usr/local/include/c++/4.9.4/atomic:41:0,
 from testThreadSpawnTime.cpp:5:
/usr/local/include/c++/4.9.4/bits/atomic_base.h: In function ‘int main()’:
/usr/local/include/c++/4.9.4/bits/atomic_base.h:478:2: error: invalid memory
model for ‘__atomic_store’
  __atomic_store_n(&_M_i, __i, __m);
  ^
/usr/local/include/c++/4.9.4/bits/atomic_base.h:478:2: error: invalid memory
model for ‘__atomic_store’
  __atomic_store_n(&_M_i, __i, __m);
  ^
/usr/local/include/c++/4.9.4/bits/atomic_base.h:478:2: error: invalid memory
model for ‘__atomic_store’
  __atomic_store_n(&_M_i, __i, __m);
  ^

The memory model is std::memory_order_acquire (used in atomic::store).

[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #9 from Alexander Monakov  ---
Backported to gcc-5 branch, fixed.

[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Author: amonakov
Date: Thu Sep 21 21:56:16 2017
New Revision: 253081

URL: https://gcc.gnu.org/viewcvs?rev=253081=gcc=rev
Log:
PR tree-optimization/71702

Backport r230667
2015-11-20  Jim Wilson  

* tree-vect-data-refs.c (compare_tree): Call STRIP_NOPS.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/tree-vect-data-refs.c

[Bug c/82286] New: Wrong array subscript is above array bounds

[hermantenbrugge at home dot nl]

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

Bug ID: 82286
   Summary: Wrong array subscript is above array bounds
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hermantenbrugge at home dot nl
  Target Milestone: ---

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

The attached testcase reports array bound error if compiled with:

gcc -O3 -Wall -c tst.c -DERROR
tst.c: In function 'mtrx_decompose_matrix':
tst.c:36:17: warning: array subscript is above array bounds [-Warray-bounds]
  sum += tmp.data[row][sub] * tmp.data[col][sub];
 ^

If -DERROR is not given the testcase compiles with no warning.

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon  ---
Created attachment 4
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4=edit
execution traces

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
Created attachment 42221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42221=edit
executable

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
Created attachment 42220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42220=edit
object file

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
Created attachment 42219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42219=edit
assembly file

Compiled with -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
The logs are not very helpful here is what I can see in gfortran.log:
Execution timeout is: 300
spawn [open ...]^M

Program aborted. Backtrace:
qemu: uncaught target signal 6 (Aborted) - core dumped

I am attaching the executable file I have produced, as well as the execution
traces generated by qemu-armeb -d in_asm.

[Bug testsuite/81539] Bad target in new test case gcc.target/powerpc/mmx-packuswb-1.c from r250432

[munroesj at gcc dot gnu.org]

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

Steven Munroe  changed:

   What|Removed |Added

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

--- Comment #1 from Steven Munroe  ---
Fixed with:

2017-08-24  Steven Munroe  

* gcc.target/powerpc/mmx-packuswb-1.c [NO_WARN_X86_INTRINSICS]:
Define.  Suppress warning during tests.

[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to Martin Liška from comment #2)
> > Confirmed, started with r250048.
> 
> Still going wrong, nearly a month later.

Still broken another month later.

[Bug target/43763] segfault when using by -mwarn-cell-microcode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
-mwarn-cell-microcode was removed in r248695 (it's in GCC 7).

No backports planned.

[Bug fortran/82275] gfortran rejects valid & accepts invalid reference to dimension-remapped type SELECT TYPE selector

[damian at sourceryinstitute dot org]

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

--- Comment #3 from Damian Rouson  ---
Thanks for looking at this.  Once there's a fix, it would be great if it could
be back-ported to GCC 7 as well.

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
I had better take it since I am the guilty party but I must echo Thomas's
request for more information.

Cheers

Paul

[Bug c/82285] New: Optimizing error when using enumeration

[hermantenbrugge at home dot nl]

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

Bug ID: 82285
   Summary: Optimizing error when using enumeration
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hermantenbrugge at home dot nl
  Target Milestone: ---

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

The attached code initializes the data array wrong when using enumerations.
If the code is changed to use integers it works.
It also works if during initialization a printf is done.

The code aborts if compiled with: gcc -O3 tst.c -o tst; ./tst
The code works if compiled with: gcc -O3 tst.c -o tst -DPRINT; ./tst
De code also works if compiled with -O2.

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose  ---
starting a build before heading to bed ...

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Probably fixed the bug on trunk.  Want to try the patch I just committed?

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Sep 21 18:44:39 2017
New Revision: 253078

URL: https://gcc.gnu.org/viewcvs?rev=253078=gcc=rev
Log:
PR go/82284
* elf.c (backtrace_initialize): Set pd.exe_filename.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/elf.c

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-21
 CC||pault at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Can you supply any more details, such as any error messages?

It's hard to debug otherwise if the developers do not have
access to the hardware.

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[doko at gcc dot gnu.org]

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

--- Comment #5 from Matthias Klose  ---
I checked with trunk 20170917, but I backported your patch for PR
sanitizer/77631 to the gcc-7-branch. I'm building current trunk now. So sthis
is a 8, not 7 regression.

[Bug tree-optimization/78512] [7 Regression] r242674 miscompiles Linux kernel

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80120] [7/8 Regression] Incorrect error with associate construct and character array

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81903] [OOP] problem with ASSOCIATE and class pointer (Invalid character in name at)

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82121] [7/8 Regression] Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/67543] ICE on associate with improper association

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Thu Sep 21 18:40:21 2017
New Revision: 253077

URL: https://gcc.gnu.org/viewcvs?rev=253077=gcc=rev
Log:
2017-09-21  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-09-21  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

PR fortran/52832
* gfortran.dg/associate_31.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_26.f90
trunk/gcc/testsuite/gfortran.dg/associate_27.f90
trunk/gcc/testsuite/gfortran.dg/associate_28.f90
trunk/gcc/testsuite/gfortran.dg/associate_29.f90
trunk/gcc/testsuite/gfortran.dg/associate_30.f90
trunk/gcc/testsuite/gfortran.dg/associate_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
(Never mind, it's my elf.c that has the local changes.  Sorry.)

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Your line numbers in libbacktrace/elf.c do not match the ones on trunk.  Do you
have local patches to that file?

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
This is most likely due to
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01412.html .

[Bug fortran/82275] gfortran rejects valid & accepts invalid reference to dimension-remapped type SELECT TYPE selector

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

Summary|gfortran rejects valid &|gfortran rejects valid &
   |accepts invalid reference   |accepts invalid reference
   |to dimension-remapped type  |to dimension-remapped type
   |associate selector  |SELECT TYPE selector

--- Comment #2 from Paul Thomas  ---
Sorry I didn't look closely enough at the testcase. Title changed accordingly.

Paul

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
looks like there are no go or libgo specific changes

[Bug target/82242] IRA spills allocno in loop body if it crosses throwing call outside the loop

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

Summary|x86_64 bad optimization |IRA spills allocno in loop
   |with -march |body if it crosses throwing
   ||call outside the loop

--- Comment #4 from Alexander Monakov  ---
FWIW, removing 'if (can_throw_internal (insn)) { ... }' code in
ira-lives.c:process_bb_node_lives introduced by fix for PR 38811 improves this
testcase and doesn't seem to introduce testsuite regressions on both 32 and
64-bit x86, but this might just mean that there's not enough runtime testcases
for catching exceptions. The place for a proper fix may be elsewhere, I don't
know what special considerations are required for throwing calls.

[Bug go/82284] New: [7 Regression] go -version segfaults on big endian architectures

[doko at gcc dot gnu.org]

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

Bug ID: 82284
   Summary: [7 Regression] go -version segfaults on big endian
architectures
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

[forwarded from https://bugs.debian.org/876353]

seen on the gcc-7-branch, last known working version on the branch was r251446.
 works on the gcc-6-branch and trunk.

segmentation fault running `go-7 version` on ppc64 arch (BE).

dmesg is
[1619215.799421] go-7[12079]: unhandled signal 11 at 1010a540 nip
7fff95bfadac lr 7fff9705d458 code 30001


#0  __strrchr_vx () at ../sysdeps/s390/multiarch/strrchr-vx.S:46
#1  0x03fffd622ca2 in elf_find_debugfile_by_debuglink (data=, 
error_callback=, debuglink_name=,
filename=, 
state=) at ../../../src/libbacktrace/elf.c:862
#2  elf_open_debugfile_by_debuglink (data=,
error_callback=, 
debuglink_crc=, debuglink_name=,
filename=, 
state=) at ../../../src/libbacktrace/elf.c:923
#3  elf_add (state=0x3fffdfb1000, 
filename=filename@entry=0x7f7f7f7f7f7f7f7f , descriptor=,
base_address=, 
error_callback=error_callback@entry=0x3fffd161868 ,
data=0x3ffe900, 
fileline_fn=0x3ffde48, found_sym=0x3ffe028,
found_dwarf=0x3ffde44, exe=0, 
debuginfo=0) at ../../../src/libbacktrace/elf.c:1295
#4  0x03fffd623248 in phdr_callback (info=0x3ffdf00, size=, 
pdata=0x3ffe038) at ../../../src/libbacktrace/elf.c:1453
#5  0x03fffc4c0446 in __GI___dl_iterate_phdr (
callback=callback@entry=0x3fffd6231a0 , data=, 
data@entry=0x3ffe038) at dl-iteratephdr.c:76
#6  0x03fffd6233e6 in backtrace_initialize
(state=state@entry=0x3fffdfb1000, 
filename=filename@entry=0x3fffd826964 "/proc/self/exe",
descriptor=, 
error_callback=error_callback@entry=0x3fffd161868 , 
data=data@entry=0x3ffe900, fileline_fn=0x3ffe130)
at ../../../src/libbacktrace/elf.c:1495
#7  0x03fffd6211a0 in fileline_initialize (state=state@entry=0x3fffdfb1000, 
error_callback=error_callback@entry=0x3fffd161868 , 
data=data@entry=0x3ffe900) at ../../../src/libbacktrace/fileline.c:136
#8  0x03fffd621212 in backtrace_pcinfo (state=0x3fffdfb1000,
pc=4397997627705, 
callback=0x3fffd1615d0 , error_callback=0x3fffd161868
, 
data=data@entry=0x3ffe900) at ../../../src/libbacktrace/fileline.c:170
#9  0x03fffd6218c2 in unwind (context=, vdata=0x3ffe828)
at ../../../src/libbacktrace/backtrace.c:91
#10 0x03fffc18a064 in _Unwind_Backtrace () from
/lib/s390x-linux-gnu/libgcc_s.so.1
#11 0x03fffd621964 in backtrace_full (state=0x3fffdfb1000,
skip=skip@entry=0, 
callback=callback@entry=0x3fffd1615d0 , 
error_callback=error_callback@entry=0x3fffd161868 , 
data=data@entry=0x3ffe900) at ../../../src/libbacktrace/backtrace.c:127
#12 0x03fffd16193a in runtime_callers (skip=skip@entry=4,
locbuf=locbuf@entry=0x3ffea10, 
m=m@entry=32, keep_thunks=keep_thunks@entry=false)
at ../../../src/libgo/runtime/go-callers.c:170
#13 0x03fffd588b3a in runtime.callers (skip=4, locbuf=...)
at ../../../src/libgo/go/runtime/traceback_gccgo.go:63
#14 runtime.mProf_Malloc (p=, 
p@entry=,
size=size@entry=1536)
data=data@entry=0x3ffe900) at ../../../src/libbacktrace/fileline.c:136
#8  0x03fffd621212 in backtrace_pcinfo (state=0x3fffdfb1000,
pc=4397997627705, 
callback=0x3fffd1615d0 , error_callback=0x3fffd161868
, 
data=data@entry=0x3ffe900) at ../../../src/libbacktrace/fileline.c:170
#9  0x03fffd6218c2 in unwind (context=, vdata=0x3ffe828)
at ../../../src/libbacktrace/backtrace.c:91
#10 0x03fffc18a064 in _Unwind_Backtrace () from
/lib/s390x-linux-gnu/libgcc_s.so.1
#11 0x03fffd621964 in backtrace_full (state=0x3fffdfb1000,
skip=skip@entry=0, 
callback=callback@entry=0x3fffd1615d0 , 
error_callback=error_callback@entry=0x3fffd161868 , 
data=data@entry=0x3ffe900) at ../../../src/libbacktrace/backtrace.c:127
#12 0x03fffd16193a in runtime_callers (skip=skip@entry=4,
locbuf=locbuf@entry=0x3ffea10, 
m=m@entry=32, keep_thunks=keep_thunks@entry=false)
at ../../../src/libgo/runtime/go-callers.c:170
#13 0x03fffd588b3a in runtime.callers (skip=4, locbuf=...)
at ../../../src/libgo/go/runtime/traceback_gccgo.go:63
#14 runtime.mProf_Malloc (p=, 
p@entry=,
size=size@entry=1536)
---Type  to continue, or q  to quit---
at ../../../src/libgo/go/runtime/mprof.go:254
#15 0x03fffd16fdea in runtime_profilealloc (size=1536, v=)
at ../../../src/libgo/runtime/malloc.goc:308
#16 runtime_mallocgc (size=1536, size@entry=1432, typ=,
typ@entry=4398009200432, 
flag=0) at ../../../src/libgo/runtime/malloc.goc:245

[Bug libquadmath/81848] Add PowerPC support to libquadmath

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Code checked in on September 1st, 2017.

[Bug c/81882] attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81854
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
Wording updated in r253076.

[Bug c/81882] attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Sep 21 17:19:16 2017
New Revision: 253076

URL: https://gcc.gnu.org/viewcvs?rev=253076=gcc=rev
Log:
PR c/81882 - attribute ifunc documentation uses invalid code

gcc/ChangeLog:

PR c/81882
* doc/extend.texi (attribute ifunc): Avoid relying on ill-formed
code (in C++) or code that triggers warnings.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug c/82283] New: Wrong warning with -Wmissing-field-initializers

[etienne.doms at gmail dot com]

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

Bug ID: 82283
   Summary: Wrong warning with -Wmissing-field-initializers
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne.doms at gmail dot com
  Target Milestone: ---

See the following code:

/*
 * gcc bug.c -Wextra -c
 */

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

union B {
struct A a;
};

union B data1 = {
.a.a = & (int) { 0 },
.a.b = 0
};

union B data2 = {
.a.b = 0,
.a.a = & (int) { 0 }
};

This triggers to the following warnings, reported on "data1" initialization:

bug.c:16:5: warning: missing initializer for field 'b' of 'struct A'
[-Wmissing-field-initializers]
 .a.b = 0
 ^
bug.c:7:9: note: 'b' declared here
 int b;
 ^

Interestingly, there is no warning on "data2" initialization, which should be
exactly the same.

Got this issue on the Ubuntu 16.04 stock GCC (5.4.0), the issue is also present
with GCC 7.2.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

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

--- Comment #57 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #56)
> > --- Comment #55 from simon at pushface dot org ---
> > (In reply to Iain Sandoe from comment #54)
> >
> >> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
> >> folks could check it out.
> >
> > bootstrapped r252935 on 10.11.6:
> [...]
> 
> Same here on x86_64-apple-darwin11.4.2 (all languages), where I replaced
> Simon's previous workaround with your patch.
> 
> Now running an i386-apple-darwin11.4.2 bootstrap, which will take
> another day.

thanks all!

Dominique reported OK on Darwin16 and Darwin10 on irc, so I think if the i386
bootstrap is successful - this should be good to go (for now)

[Bug tree-optimization/82282] New: PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

[nunoplopes at sapo dot pt]

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

Bug ID: 82282
   Summary: PRE cannot blindly fold
integer-to-pointer/pointer-to-integer round-trips
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunoplopes at sapo dot pt
CC: gil.hur at sf dot snu.ac.kr, jeehoon.kang at sf dot 
snu.ac.kr,
juneyoung.lee at sf dot snu.ac.kr, regehr at cs dot 
utah.edu,
sanjoy at playingwithpointers dot com
  Target Milestone: ---

The following program gets miscompiled by gcc:

$ cat foo.c
#include 
#include 

int* glb;
int* tmp[10];

void main(int argc, char* argv) {
  int x[1] = { 555 }, y[1] = { 777 };
  uintptr_t u = (uintptr_t) (x + 1);
  uintptr_t v = (uintptr_t) y;
  uintptr_t w;

  int b1 = u != v;
  int b2 = u+1 != v+1;

  int* z;

  if (b1) {
printf("b1 TRUE.\n");
v = u;
  }
  glb = (int*) v;

  for (int i=0; i < 10; i++)
tmp[i] = (int*) v;

  if (b2) {
printf("b2 TRUE.\n");
glb = x;
  }

  w = u;
  for (int i = 0; i < 100; ++i) {
if (w < v) {
  w += 1;
}
  }

  if (v == w) {
z = x;
  } else {
printf("IMPOSSIBLE!\n");
z = y;
  }
  *z = 555;

  *glb = 1;

  printf("x=%d y=%d\n", x[0], y[0]);
}

$ gcc -O3 -fdump-tree-all foo.c
$ ./a
x=555 y=777


We start with:
  u_14 = (uintptr_t) [(void *) + 4B];
  v_15 = (uintptr_t) 

  if (u_14 != v_15)
goto ;
  else
goto ;

  :
  # v_1 = PHI 
  v.0_19 = (int *) v_1
  glb = v.0_19;


Which is then (correctly) transformed by phiopt2 to:
  if (u_14 != v_15)
goto ;
  else
goto ;

  :
  # v_1 = PHI 
  v.0_19 = (int *) v_1;
  glb = v.0_19;


Then PRE incorrectly removes the pointer-to-integer/integer-to-point cast
round-trip through the PHI node:
  glb = [(void *) + 4B];

This is wrong because we've now lost the information that glb may also alias
with y, as seen by the alias analysis report:
glb = { ESCAPED NONLOCAL x }


After a few more rounds of copy propagation and "dom3", "777" is constant
propagated to the printf call, since the store to glb cannot possibly alias 'y'
anymore.
All the subsequent transformations are correct. The bug is that PRE cannot
blindly do a transformation of "int2ptr(ptr2int(x)) -> x".

Test case by Gil Hur.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #56 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #55 from simon at pushface dot org ---
> (In reply to Iain Sandoe from comment #54)
>
>> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
>> folks could check it out.
>
> bootstrapped r252935 on 10.11.6:
[...]

Same here on x86_64-apple-darwin11.4.2 (all languages), where I replaced
Simon's previous workaround with your patch.

Now running an i386-apple-darwin11.4.2 bootstrap, which will take
another day.

Rainer

[Bug target/82274] __builtin_mul_overflow fails to detect overflow for int64_t when compiled with -m32

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
internal-fn.c implements here whatever we have written in libgcc2.c for
__mulvti3 (for 64-bit arches) or __mulvdi3 (for 32-bit arches).
And it seems this is (hopefully the only) incorrectly handled special case.
That routine first handles the case where both operands are within range of
sign-extended half-sized integers (never overflows), then when one of them is
and the other is arbitrary (or vice versa, mul is commutative) - this one needs
2 multiplications and sometimes overflows, sometimes doesn't, then when both of
them are within the range of max signed half type + 1 to max unsigned half
type, then when one of them is in that range and other is in range of minus
(max unsigned half type + 1) to (min signed half type - 1) and finally when
both are of the latter kind (everything else is always overflow).
That last case is:
  if (uu.s.high == (Wtype) -1 && vv.s.high == (Wtype) - 1)
{
  DWunion ww = {.ll = (UDWtype) (UWtype) uu.s.low
* (UDWtype) (UWtype) vv.s.low};

  ww.s.high -= uu.s.low;
  ww.s.high -= vv.s.low;
  if (__builtin_expect (ww.s.high >= 0, 1))
return ww.ll;
}
If both uu.s.low == vv.s.low == 0, then we return 0 even when there is
overflow.
Wonder if ww.s.high >= 0 && ww.ll wouldn't be sufficient.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

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

--- Comment #55 from simon at pushface dot org ---
(In reply to Iain Sandoe from comment #54)

> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
> folks could check it out.

bootstrapped r252935 on 10.11.6:

=== gnat Summary ===

# of expected passes2604
# of unexpected failures1
# of expected failures  24
# of unsupported tests  7

=== acats Summary ===
# of expected passes2320
# of unexpected failures0

[Bug target/82281] New: Bulldozer/Zen tuning: uses XMM for single 64-bit integer AND, even with a simple mask

[peter at cordes dot ca]

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

Bug ID: 82281
   Summary: Bulldozer/Zen tuning: uses XMM for single 64-bit
integer AND, even with a simple mask
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ssemmx
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

long long test_and(long long x) {
return x & 0x77ULL;
}
// https://godbolt.org/g/D6XujV
# -O3 -march=znver1 -m32 -mno-avx
movaps  .LC0, %xmm1
movq4(%esp), %xmm0
andps   %xmm1, %xmm0
movd%xmm0, %eax
pextrd  $1, %xmm0, %edx
ret

# -O3 -m32
movl8(%esp), %edx
movl4(%esp), %eax
andl$119, %edx
ret

We get this with znver1 and bdver1-4, but not barcelona or btver2.

Also not haswell, skylake or knl.

So something is wrong with tunings for recent AMD that make it over-eager to go
to vector registers for 64-bit integers in the most trivial case possible. 
Fortunately it's on when coming from memory:

long long ext();
long long test_and() {
long long x = ext();
return x & 0x77ULL;
}
  # -O3 -march=znver1 -m32
subl$12, %esp
callext()
addl$12, %esp
andl$119, %edx
ret

[Bug demangler/82195] Undemangleable lambda

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Thu Sep 21 15:52:31 2017
New Revision: 253075

URL: https://gcc.gnu.org/viewcvs?rev=253075=gcc=rev
Log:
[demangler PATCH]: Revert and update generic lambda demangling

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01482.html
PR demangler/82195
* cp-demangle.c (d_name): Revert addition of 'toplevel' parm.
(has_return_type): Recurse for DEMANGLE_COMPONENT_LOCAL_NAME.
(d_encoding): Revert d_name change.  Use is_fnqual_component_type
to strip modifiers that do not belong.
(d_special_name, d_class_enum_type): Revert d_name call change.
(d_expresion_1): Commonize DEMANGLE_COMPONENT_UNARY building.
(d_local_name): Revert parsing of a function type.
(d_print_comp_inner): An inner LOCAL_NAME might contain a
TEMPLATE.
* testsuite/demangle-expected: Add & adjust tests

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Invalid as mentioned.

[Bug target/82277] [RISCV] fmv.w.x and fmv.x.w opcodes are not recognised

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
Please report this to binutils since that is the maintainer of the assembler.

https://www.sourceware.org/bugzilla/

[Bug target/81602] Unnecessary zero-extension after 16 bit popcnt

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
Forgot to mention: memory-source popcnt with an indexed addressing mode would
also be worse on SnB/IvB: it can't stay micro-fused, so the front-end
un-laminates it in the issue stage.

Haswell and later can keep  popcnt (%rdi, %rdx), %eax  micro-fused throughout
the pipeline, so it's always 1 fused-domain uop instead of expanding to 2, but
it's still 2 unfused-domain uops so it takes more room in the scheduler than
the reg-reg form.

When Intel fixes the output dependency in some future uarch, it might
un-laminate again with indexed addressing modes.  That's what happens on
Skylake for tzcnt/lzcnt, because SKL fixed their output dependency.  (And
judging from the published errata, they meant to fix popcnt as well.)  But
index addressing modes can only stay micro-fused with an ALU uop with
"traditional" x86-style instructions with 2 operands where the destination is
read/write, not write-only.   (Tested on Haswell and Skylake).  And yes, this
makes indexed addressing modes with AVX instructions worse than with the SSE
equivalent. :/

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

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

--- Comment #6 from Franz Sirl  ---
Actually this is likely triggered by undefined behaviour. The array m_pTemp is
too small for nAccessSize=4096. Increasing the array size to 1024 elements
makes the bug go away.
If you agree, just close the bug and sorry for the noise.

[Bug target/81602] Unnecessary zero-extension after 16 bit popcnt

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #2 from Peter Cordes  ---
(In reply to Uroš Bizjak from comment #1)
> The "xorl %eax, %eax; movw %ax, (%rsi)" pair is just optimized way to 
> implement "movw $0, (%rsi);".

That's questionable on Skylake.  Sandybridge and later Intel CPUs don't have
LCP decode stalls on mov with a 16-bit immediate, only on ALU instructions. 
movw $0, (%rsi)  has no displacement and a 16-bit immediate, so it only takes 1
entry in the uop cache (Agner Fog's microarch pdf, table 9.1).  I don't see any
other downsides for a mov-imm16 to memory on Skylake.

> It just happens that peephole pass found unused %eax as an empty temporary 
> reg when splitting direct move of immediate to memory.

Then it's a missed-optimization to keep re-zeroing inside the loop, instead of
picking %ecx and hoisting the xor so the rest of the loop can keep clobbering
%eax.

Although really doing what Christoph suggested is even better if you do want
the xor-zeroing for something else.  If a peephole pass is introducing
xor-zeroing instructions, then it's a missed optimization if other instructions
can't take advantage.  Having an xor-zeroing inside the loop *instead* of a
movzx is pretty good if the xor-zero is needed for some other reason.

> popcntl has a false dependency on its output in certain situations,

Yes, always on Intel Sandybridge-family, including Skylake.

> where popcntw doesn have this limitation. So, gcc choose this approach for a
> reason.

Intel Haswell/Skylake (and I think IvyBridge) don't rename low16 separately
from the full register
(https://stackoverflow.com/questions/45660139/how-exactly-do-partial-registers-on-haswell-skylake-perform-writing-al-seems-to).
 *Any* write of a 16-bit register has a false dependency on the old value.  So
popcntw isn't a special case of false dependency, it's like other 16-bit
instructions.  Is that what you're thinking of?

The only CPUs where it's even theoretically possible for popcntw to not have an
output dependency are Nehalem and Sandybridge.  All other CPUs don't rename
low16 separately from the full register or are too old to have popcnt.

Do you have a source for your claim that popcntw doesn't have a dependency on
the 16-bit destination register, on Sandybridge?  It's probably true on
Nehalem, because they rename %ax and don't have false dependencies for
popcntl/q, but more likely Sandybridge will treat %ax as an input dependency.

If you don't have an xor-zeroed register you can clobber, movzx-load + popcntl
is pretty clearly better than popcntw mem,%ax;  movzx %ax, %eax on all CPUs, or
at least not worse.  It saves a code byte (no operand-size prefix), guarantees
no false dependency on %eax, and avoids a 16-bit popcnt (slow on
Silvermont/KNL).

It's also fewer total uops for the out-of-order scheduler / execution units:
popcnt (mem), reg  is a micro-fused load + ALU, and movzwl r16,r32 is another
ALU uop.  But a movzx load decodes to just a load uop on Intel CPUs, no ALU uop
needed.


For example, gcc -m32 -O3 -mtune=generic compiles this
int pc_ushort(unsigned short a) { return __builtin_popcount(a); }
// https://godbolt.org/g/nnNYLU
popcntw 4(%esp), %ax# false dep on most CPUs
movzwl  %ax, %eax   # extra ALU uop on the critical path
ret

Much better:

movzwl   4(%esp), %eax  # just as fast as a mov load
popcntl  %eax, %eax # popcntl false dep taken care of by
same,same


Or another -m32 example:
int pcl(unsigned long a) { return __builtin_popcountll(a); }
# -O3 -mpopcnt -m32
xorl%eax, %eax # correctly omitted with -mtune=znver1
popcntl 4(%esp), %eax

extra non-eliminated ALU uop for the execution units on Nehalem and AMD vs.

movl4(%esp), %eax
popcntl %eax, %eax

Also, the load might issue 1 cycle earlier this way, or can even be hoisted
ahead of other surrounding code.  Splitting a micro-fused load+ALU into a
mov-load is always at least as good as xor-zeroing for dep breaking when the
source is in memory.  (A reg-reg mov is not always better; putting a mov on the
critical path is always worse for older CPUs, vs. xor off the critical path.)

Here are some more examples of current gcc 8.0.0 20170920  getting things wrong
for various tunings:

int pcll_uint(unsigned int a) { return __builtin_popcountll(a); }
   # -O3 -march=bdver2
movl%edi, %eax# zero-extend to 64-bit
popcntq %rax, %rax# 64-bit popcntq has 4c throughput, vs. 2c
for 16/32 bit (Agner Fog's table for Piledriver)
ret

Missed optimization to  popcntl %edi, %eax  (without mov) applies to znver1 /
knl / others as well, but especially bad on Bulldozer-family where 

[Bug libquadmath/81848] Add PowerPC support to libquadmath

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Can this be closed?

[Bug testsuite/78421] [7/8 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

[tnfchris at gcc dot gnu.org]

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

--- Comment #7 from Tamar Christina  ---
Author: tnfchris
Date: Thu Sep 21 14:45:03 2017
New Revision: 253073

URL: https://gcc.gnu.org/viewcvs?rev=253073=gcc=rev
Log:
2017-09-21  Tamar Christina  

PR testsuite/78421
* lib/target-supports.exp (check_effective_target_vect_hw_misalign):
Invert arm check.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug tree-optimization/82255] Vectorizer cost model overcounts cost of some vectorized loads

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Created attachment 42217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42217=edit
Test case patch

Here's a test case (and some associated changes to add debug code for the test
case) that can be used to verify a fix.

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

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #12 from Segher Boessenkool  ---
I have a patch.

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Maybe sth for Bin to look at ...

I will investigate it.  Thanks.

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Maybe sth for Bin to look at ...

[Bug ipa/82278] [8 regression] gcc.dg/lto/chkp-ctor-merge fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-21
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, I think I also saw this.

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

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

--- Comment #3 from Franz Sirl  ---
The bug was introduced with r195054:

2013-01-09  Jan Hubicka  

PR tree-optimiation/55875
* tree-ssa-loop-niter.c (number_of_iterations_cond): Add
EVERY_ITERATION parameter.
(number_of_iterations_exit): Check if exit is executed every
iteration.
(idx_infer_loop_bounds): Similarly here.
(n_of_executions_at_most): Simplify
to only test for cases where statement is dominated by the
particular bound; handle correctly the "postdominance"
test.
(scev_probably_wraps_p): Use max loop iterations info
as a global bound first.

BTW, -fno-tree-vrp also suppresses the bug.

[Bug rtl-optimization/82280] New: Missed optimization opportunity constexpr/inline data copy not elided

[matt at godbolt dot org]

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

Bug ID: 82280
   Summary: Missed optimization opportunity constexpr/inline data
copy not elided
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

Consider the C++ code:

```
#include 
#include 

constexpr auto get_tokens()
{
  return std::array{"This is my string of possible tokens to
match."};
}

struct S {
#ifndef LOCAL
  static constexpr auto m_tokens = get_tokens();
#endif

  constexpr bool has_token(const char c) const {
#ifdef LOCAL
const constexpr auto m_tokens = get_tokens();
#endif

for (const auto val : m_tokens) {
  if (val == c) { return true; }
}
return false;
  }
};

int main(const int argc, const char *[]) {
  constexpr S s;
  return s.has_token(char(argc));
}
```

Compiled with `-O3 -std=c++1z`, the `m_tokens` is a struct-level static
constexpr data member. Adding `-DLOCAL` makes it a const constexpr local
variable within the `has_token` routine.

When compiled with local, the result of the `get_tokens()` call is copied to
stack, and is used from there. The copy introduces 10 instructions. Given that
the source is immutable, the copy can be elided and the original data referred
to instead. See, for example: https://godbolt.org/g/ZVZMi6

Clang avoids the copy (see https://godbolt.org/g/j5P8Uv - NB this is clang 5.0
with `-O2` to prevent some of its other optimizations from confusing the issue
further).

[Bug target/81996] powerpc __builtin_return_address(0) fails with -fPIC -fstack-protector-all or -fsanitize=address

[wschmidt at linux dot vnet.ibm.com]

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

--- Comment #12 from wschmidt at linux dot vnet.ibm.com ---
Thanks for sorting this out, Alan!

Bill

> On Sep 21, 2017, at 8:30 AM, amodra at gmail dot com 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81996
> 
> Alan Modra  changed:
> 
>   What|Removed |Added
> 
> Status|ASSIGNED|RESOLVED
> Resolution|--- |FIXED
> 
> --- Comment #11 from Alan Modra  ---
> Fixed all active branches
> 
> -- 
> You are receiving this mail because:
> You are watching someone on the CC list of the bug.

[Bug target/81996] powerpc __builtin_return_address(0) fails with -fPIC -fstack-protector-all or -fsanitize=address

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #11 from Alan Modra  ---
Fixed all active branches

[Bug target/81996] powerpc __builtin_return_address(0) fails with -fPIC -fstack-protector-all or -fsanitize=address

[amodra at gcc dot gnu.org]

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

--- Comment #10 from Alan Modra  ---
Author: amodra
Date: Thu Sep 21 13:25:45 2017
New Revision: 253070

URL: https://gcc.gnu.org/viewcvs?rev=253070=gcc=rev
Log:
PR81996, __builtin_return_address(0) fails

rs6000_return_addr assumes that the stack link is at frame+0, which is
true for count>0.  For count==0, rs6000_return_addr is called with
frame==frame_pointer_rtx and the stack link is *not* at frame+0 if
-fstack-protector-all or -fsanitize=address because rs6000.h sets
FRAME_GROWS_DOWNWARD for those options.

PR target/81996
* gcc/config/rs6000/rs6000.c (rs6000_return_addr): Use
stack_pointer_rtx for count 0.  Update comments.  Break up
large rtl expression.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c

[Bug c++/82279] New: [C++17] ICE in tsubst_pack_expansion, at cp/pt.c:11514

[s.gesemann at gmail dot com]

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

Bug ID: 82279
   Summary: [C++17] ICE in tsubst_pack_expansion, at cp/pt.c:11514
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s.gesemann at gmail dot com
  Target Milestone: ---

The following code reproduces the error:

template
struct foo;

template
struct foo {};

struct bar {
void memfun() {}
};

int main() {
foo<::memfun>();
}

I used g++ with -std=c++17 option and it resulted in:

: In function 'int main()':
12 : :12:23: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:11514
 foo<::memfun>();
   ^
mmap: Cannot allocate memory
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler exited with result code 1

See also https://godbolt.org/g/CMfzHt

[Bug tree-optimization/82255] Vectorizer cost model overcounts cost of some vectorized loads

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bill Schmidt  ---
We've had a conversation about this on-list, starting with
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01280.html.  We're agreed that a
proper solution is going to be complex.  Taking my name off this one for now as
I won't have time for it in the short term.

[Bug target/81996] powerpc __builtin_return_address(0) fails with -fPIC -fstack-protector-all or -fsanitize=address

[amodra at gcc dot gnu.org]

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

--- Comment #9 from Alan Modra  ---
Author: amodra
Date: Thu Sep 21 12:57:24 2017
New Revision: 253068

URL: https://gcc.gnu.org/viewcvs?rev=253068=gcc=rev
Log:
PR81996, __builtin_return_address(0) fails

rs6000_return_addr assumes that the stack link is at frame+0, which is
true for count>0.  For count==0, rs6000_return_addr is called with
frame==frame_pointer_rtx and the stack link is *not* at frame+0 if
-fstack-protector-all or -fsanitize=address because rs6000.h sets
FRAME_GROWS_DOWNWARD for those options.

PR target/81996
* gcc/config/rs6000/rs6000.c (rs6000_return_addr): Use
stack_pointer_rtx for count 0.  Update comments.  Break up
large rtl expression.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c

[Bug target/81996] powerpc __builtin_return_address(0) fails with -fPIC -fstack-protector-all or -fsanitize=address

[amodra at gcc dot gnu.org]

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

--- Comment #8 from Alan Modra  ---
Author: amodra
Date: Thu Sep 21 12:55:37 2017
New Revision: 253067

URL: https://gcc.gnu.org/viewcvs?rev=253067=gcc=rev
Log:
PR81996, __builtin_return_address(0) fails

rs6000_return_addr assumes that the stack link is at frame+0, which is
true for count>0.  For count==0, rs6000_return_addr is called with
frame==frame_pointer_rtx and the stack link is *not* at frame+0 if
-fstack-protector-all or -fsanitize=address because rs6000.h sets
FRAME_GROWS_DOWNWARD for those options.

PR target/81996
* gcc/config/rs6000/rs6000.c (rs6000_return_addr): Use
stack_pointer_rtx for count 0.  Update comments.  Break up
large rtl expression.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c

[Bug ipa/82278] New: [8 regression] gcc.dg/lto/chkp-ctor-merge fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 82278
   Summary: [8 regression] gcc.dg/lto/chkp-ctor-merge fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Since r251333, gcc.dg/lto/chkp-ctor-merge_0.c fails:

during IPA pass: inline
In function '_GLOBAL__I_65535_0_c_lto_chkp_ctor_merge_0.o':
lto1: internal compiler error: Segmentation fault
0xc598b6 crash_signal
gcc/toplev.c:341
0x8b3a86 cgraph_node::get(tree_node const*)
gcc/cgraph.h:1262
0x8b3a86 cgraph_node::get_create(tree_node*)
gcc/cgraph.c:533
0xce8647 chkp_redirect_edge(cgraph_edge*)
gcc/tree-chkp.c:559
0x8b99b7 cgraph_edge::redirect_call_stmt_to_callee()
gcc/cgraph.c:1385
0x1319a51 inline_transform(cgraph_node*)
gcc/ipa-inline-transform.c:670
0x61bda9 execute_one_ipa_transform_pass
gcc/passes.c:2237
0x61bda9 execute_all_ipa_transforms()
gcc/passes.c:2279
0x8c060b cgraph_node::expand()
gcc/cgraphunit.c:2047
0x8c1a42 expand_all_functions
gcc/cgraphunit.c:2190
0x8c1a42 symbol_table::compile()
gcc/cgraphunit.c:2538
0x832c14 lto_main()
gcc/lto/lto.c:3340
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
compiler exited with status 1

FAIL: gcc.dg/lto/chkp-ctor-merge
c_lto_chkp-ctor-merge_0.o-c_lto_chkp-ctor-merge_0.o link,  -O2 -flto
-fcheck-pointer-bounds -mmpx -nodefaultlibs -lc  (internal compiler error)


Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto --with-arch=haswell --with-cpu=haswell

[Bug lto/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||marxin at gcc dot gnu.org
  Component|libstdc++   |lto
   Assignee|redi at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #10 from Jonathan Wakely  ---
Reproducible for any version since 4.6.0, without C++17 or optimization, just
LTO:

#define _GLIBCXX_USE_CXX11_ABI 0
#include 
#undef _GLIBCXX_EXTERN_TEMPLATE
#include 

int main()
{
  std::string s;
  std::cin >> s;
}


$ g++ os.cc -flto
$ echo d | ./a.out
*** Error in `./a.out': free(): invalid pointer: 0x006021a0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7c8dc)[0x7fe1d6f188dc]
/lib64/libc.so.6(+0x87789)[0x7fe1d6f23789]
/lib64/libc.so.6(cfree+0x16e)[0x7fe1d6f290ee]
/lib64/libstdc++.so.6(_ZNSs7reserveEm+0xa5)[0x7fe1d786e465]
/lib64/libstdc++.so.6(_ZStrsIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E+0x217)[0x7fe1d7844787]
./a.out[0x4008c2]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7fe1d6ebc50a]
./a.out[0x40074a]
=== Memory map: 
0040-00402000 r-xp  00:29 43484686  
/tmp/a.out
00601000-00602000 r--p 1000 00:29 43484686  
/tmp/a.out
00602000-00603000 rw-p 2000 00:29 43484686  
/tmp/a.out
0084d000-0087f000 rw-p  00:00 0  [heap]
7fe1d000-7fe1d0021000 rw-p  00:00 0 
7fe1d0021000-7fe1d400 ---p  00:00 0 
7fe1d6e9c000-7fe1d7063000 r-xp  fd:00 1971889   
/usr/lib64/libc-2.25.so
7fe1d7063000-7fe1d7263000 ---p 001c7000 fd:00 1971889   
/usr/lib64/libc-2.25.so
7fe1d7263000-7fe1d7267000 r--p 001c7000 fd:00 1971889   
/usr/lib64/libc-2.25.so
7fe1d7267000-7fe1d7269000 rw-p 001cb000 fd:00 1971889   
/usr/lib64/libc-2.25.so
7fe1d7269000-7fe1d726d000 rw-p  00:00 0 
7fe1d726d000-7fe1d7283000 r-xp  fd:00 1977375   
/usr/lib64/libgcc_s-7-20170915.so.1
7fe1d7283000-7fe1d7482000 ---p 00016000 fd:00 1977375   
/usr/lib64/libgcc_s-7-20170915.so.1
7fe1d7482000-7fe1d7483000 r--p 00015000 fd:00 1977375   
/usr/lib64/libgcc_s-7-20170915.so.1
7fe1d7483000-7fe1d7484000 rw-p 00016000 fd:00 1977375   
/usr/lib64/libgcc_s-7-20170915.so.1
7fe1d7484000-7fe1d7599000 r-xp  fd:00 1971970   
/usr/lib64/libm-2.25.so
7fe1d7599000-7fe1d7798000 ---p 00115000 fd:00 1971970   
/usr/lib64/libm-2.25.so
7fe1d7798000-7fe1d7799000 r--p 00114000 fd:00 1971970   
/usr/lib64/libm-2.25.so
7fe1d7799000-7fe1d779a000 rw-p 00115000 fd:00 1971970   
/usr/lib64/libm-2.25.so
7fe1d779a000-7fe1d7914000 r-xp  fd:00 1977857   
/usr/lib64/libstdc++.so.6.0.24
7fe1d7914000-7fe1d7b14000 ---p 0017a000 fd:00 1977857   
/usr/lib64/libstdc++.so.6.0.24
7fe1d7b14000-7fe1d7b1e000 r--p 0017a000 fd:00 1977857   
/usr/lib64/libstdc++.so.6.0.24
7fe1d7b1e000-7fe1d7b2 rw-p 00184000 fd:00 1977857   
/usr/lib64/libstdc++.so.6.0.24
7fe1d7b2-7fe1d7b23000 rw-p  00:00 0 
7fe1d7b23000-7fe1d7b4a000 r-xp  fd:00 1971811   
/usr/lib64/ld-2.25.so
7fe1d7d0c000-7fe1d7d1 rw-p  00:00 0 
7fe1d7d46000-7fe1d7d49000 rw-p  00:00 0 
7fe1d7d49000-7fe1d7d4a000 r--p 00026000 fd:00 1971811   
/usr/lib64/ld-2.25.so
7fe1d7d4a000-7fe1d7d4c000 rw-p 00027000 fd:00 1971811   
/usr/lib64/ld-2.25.so
7ffc25685000-7ffc256a7000 rw-p  00:00 0 
[stack]
7ffc2576b000-7ffc2576d000 r--p  00:00 0  [vvar]
7ffc2576d000-7ffc2576f000 r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0 
[vsyscall]
Aborted (core dumped)

[Bug target/82277] New: [RISCV] fmv.w.x and fmv.x.w opcodes are not recognised

[asb at lowrisc dot org]

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

Bug ID: 82277
   Summary: [RISCV] fmv.w.x and fmv.x.w opcodes are not recognised
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asb at lowrisc dot org
  Target Milestone: ---

The RISC-V 2.2 user-level ISA specification renamed fmv.s.x and fmv.x.s to
fmv.w.x and fmv.x.w respectively. gas doesn't recognise these mnemonics.
Additionally, objdump should probably prefer to print the new names in
preference to the old.

$ cat f.s 
fmv.x.w a2, fs7
fmv.x.s a2, fs7
fmv.w.x ft1, a6
fmv.s.x ft1, a6

$ ./riscv32-unknown-elf-as -march=rv32if f.s 
f.s: Assembler messages:
f.s:1: Error: unrecognized opcode `fmv.x.w a2,fs7'
f.s:3: Error: unrecognized opcode `fmv.w.x ft1,a6'

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 21 12:26:34 2017
New Revision: 253065

URL: https://gcc.gnu.org/viewcvs?rev=253065=gcc=rev
Log:
PR sanitizer/81715
* tree-inline.c (expand_call_inline): Emit clobber stmts for
VAR_DECLs to which addressable non-volatile parameters are mapped
and for id->retvar after the return value assignment.  Clear
id->retval and id->retbnd after inlining.

* g++.dg/tree-ssa/pr8781.C (noop): Change argument type from
const predicate to const predicate & to avoid UB.
* g++.dg/opt/pr81715.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr81715.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr8781.C
trunk/gcc/tree-inline.c

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #17 from Wilco  ---
Fixed in GCC6, 7 and trunk.

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wilco at gcc dot gnu.org]

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

--- Comment #16 from Wilco  ---
Author: wilco
Date: Thu Sep 21 12:21:18 2017
New Revision: 253064

URL: https://gcc.gnu.org/viewcvs?rev=253064=gcc=rev
Log:
PR71951: Fix unwinding with -fomit-frame-pointer

As described in PR71951, if libgcc is built with -fomit-frame-pointer,
unwinding crashes, for example while doing a backtrace.  The underlying
reason is the Dwarf unwinder does not setup the frame pointer register
in the initialization code.  When later unwinding a function that uses
the frame pointer, it tries to read FP using _Unwind_GetGR, and this
crashes if has never restored FP.  To unwind correctly the first frame
must save and restore FP (it is unwound in a special way so that it
uses SP instead of FP).  This is done by adding -fno-omit-frame-pointer.

gcc/
PR target/71951
* config/aarch64/aarch64.h (LIBGCC2_UNWIND_ATTRIBUTE): Define.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/aarch64/aarch64.h

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wilco at gcc dot gnu.org]

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

--- Comment #15 from Wilco  ---
Author: wilco
Date: Thu Sep 21 12:16:31 2017
New Revision: 253063

URL: https://gcc.gnu.org/viewcvs?rev=253063=gcc=rev
Log:
PR71951: Fix unwinding with -fomit-frame-pointer

As described in PR71951, if libgcc is built with -fomit-frame-pointer,
unwinding crashes, for example while doing a backtrace.  The underlying
reason is the Dwarf unwinder does not setup the frame pointer register
in the initialization code.  When later unwinding a function that uses
the frame pointer, it tries to read FP using _Unwind_GetGR, and this
crashes if has never restored FP.  To unwind correctly the first frame
must save and restore FP (it is unwound in a special way so that it
uses SP instead of FP).  This is done by adding -fno-omit-frame-pointer.

gcc/
PR target/71951
* config/aarch64/aarch64.h (LIBGCC2_UNWIND_ATTRIBUTE): Define.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/aarch64.h

[Bug tree-optimization/82244] [7 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 21 12:12:33 2017
New Revision: 253062

URL: https://gcc.gnu.org/viewcvs?rev=253062=gcc=rev
Log:
2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr82276.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/82276] [8 Regression] -O2: ICE: SSA corruption during RTL pass: expand; at tree-ssa-coalesce.c:1010

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 21 12:12:33 2017
New Revision: 253062

URL: https://gcc.gnu.org/viewcvs?rev=253062=gcc=rev
Log:
2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr82276.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/82244] [7 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

Bug 82276 Summary: [8 Regression] -O2: ICE: SSA corruption during RTL pass: 
expand; at tree-ssa-coalesce.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82276

   What|Removed |Added

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

[Bug tree-optimization/82276] [8 Regression] -O2: ICE: SSA corruption during RTL pass: expand; at tree-ssa-coalesce.c:1010

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wilco at gcc dot gnu.org]

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

--- Comment #14 from Wilco  ---
Author: wilco
Date: Thu Sep 21 12:08:12 2017
New Revision: 253061

URL: https://gcc.gnu.org/viewcvs?rev=253061=gcc=rev
Log:
PR71951: Fix unwinding with -fomit-frame-pointer

As described in PR71951, if libgcc is built with -fomit-frame-pointer,
unwinding crashes, for example while doing a backtrace.  The underlying
reason is the Dwarf unwinder does not setup the frame pointer register
in the initialization code.  When later unwinding a function that uses
the frame pointer, it tries to read FP using _Unwind_GetGR, and this
crashes if has never restored FP.  To unwind correctly the first frame
must save and restore FP (it is unwound in a special way so that it
uses SP instead of FP).  This is done by adding -fno-omit-frame-pointer.

gcc/
PR target/71951
* config/aarch64/aarch64.h (LIBGCC2_UNWIND_ATTRIBUTE): Define.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.h

[Bug libstdc++/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> The bug is that the symbols in lisbtdc++.so are attempting to delete the
> _S_empty_rep_storage object, which suggests that this check is false when it
> should be true:
> 
>   this != &_S_empty_rep()
> 
> That suggests we have multiple definitions of the empty rep symbol, which
> aren't being combined.

Confirmed by making the following change and rebuilding the library:

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3157,6 +3157,7 @@ _GLIBCXX_END_NAMESPACE_CXX11
  // _S_empty_rep_storage is never modified and the punning should
  // be reasonably safe in this case.
  void* __p = reinterpret_cast(&_S_empty_rep_storage);
+ __builtin_printf("%p\n", __p);
  return *reinterpret_cast<_Rep*>(__p);
}

This produces two different addresses, the first one is the address of the
empty rep in the main function, the others are the address inside libstdc++.so
(where the delete happens):

0x6023c0
0x7fe314376100
0x7fe314376100
0x7fe314376100
=
==29064==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x006023c0 in thread T0
#0 0x7fe314457fd0 in operator delete(void*) (/lib64/libasan.so.4+0xe0fd0)
#1 0x7fe3140ba291 in __gnu_cxx::new_allocator::deallocate(char*,
unsigned long)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:125
#2 0x7fe3140b9745 in std::string::_Rep::_M_destroy(std::allocator
const&)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:899
#3 0x7fe3140b96f7 in std::string::_Rep::_M_dispose(std::allocator
const&)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3252
#4 0x7fe3140b635f in std::string::reserve(unsigned long)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:961
#5 0x7fe3140b6c9a in std::string::push_back(char)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:4239
#6 0x7fe3140b66a6 in std::string::operator+=(char)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:4090
#7 0x7fe31408891f in std::basic_istream&
std::getline(std::basic_istream&, std::basic_string&, char)
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++98/istream-string.cc:168
#8 0x40106a in main (/tmp/a.out+0x40106a)
#9 0x7fe3136ec509 in __libc_start_main (/lib64/libc.so.6+0x20509)
#10 0x401389 in _start (/tmp/a.out+0x401389)

0x006023c0 is located 0 bytes inside of global variable
'_S_empty_rep_storage' defined in
'/home/jwakely/gcc/8/include/c++/8.0.0/bits/basic_string.tcc:506:5' (0x6023c0)
of size 32
SUMMARY: AddressSanitizer: bad-free (/lib64/libasan.so.4+0xe0fd0) in operator
delete(void*)
==29064==ABORTING

[Bug target/82158] _Noreturn functions that do return clobber caller's registers on ARM32 (but not other arches)

[peter at cordes dot ca]

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

--- Comment #10 from Peter Cordes  ---
(In reply to Jakub Jelinek from comment #9)
> None of the above options is IMHO acceptable.
> This is UB like any other.

I still think it's a quality-of-implementation bug that could be fixed without
downsides for conforming programs by emitting an illegal instruction instead of
bx lr.  (Thanks for pointing out some cases I hadn't considered, BTW.  That
narrows down the possible good solutions.)

IMO corrupting registers while otherwise working normally is really dangerous. 
That could appear to work in a unit test but fail sometimes with a different
caller, maybe even causing security problems if the clobbered register was only
used in an error-handling case.

If a fix would take too much work to implement, then I'm fine with leaving this
as WONTFIX; there is a warning enabled by default for cases where gcc is sure
that a noreturn function *does* return.  I disagree about INVALID, though.

I'm imagining a codebase where a stray _Noreturn attribute got attached to a
function that was never intended to be _Noreturn.

A buggy _Noreturn function that has a combination of inputs that does return
would always be problematic regardless of clobbering registers, and I guess
that's why you're thinking about sanitize?

> What we could add is -fsanitize=noreturn that would add runtime
> instrumentation

I'm not proposing anything that heavy, just an illegal instruction instead of a
return, or simply no instruction at all.  In a _Noreturn function (that has
clobbered call-preserved registers), I think gcc should never emit instructions
that return.

As you point out, even if gcc can't prove whether that path is/isn't taken, a
correct program *won't* take it, so an illegal instruction is a good thing. 
(For performance, an illegal instruction can stop incorrect speculation down a
wrong path after a mispredicted branch, potentially saving useless prefetch of
code/data and speculative page walks).

There is precedent for trapping with illegal instructions on UB:

int* address_of_local(int v) { return   }
int foo() {
int* p = address_of_local(4);
return *p;
}
   // gcc4.x returns 4
   // x86-64 gcc5 and later.  https://godbolt.org/g/W5vUiA

foo():
movl0, %eax   # load from absolute address 0
ud2   # undefined 2-byte instruction: future-proof way
to raise #UD

Falling through into whatever's next would also be a better option, since it
saves code size instead of generating instructions that a correct program will
never execute.  (gcc does that for foo() on ARM after trying a NULL-pointer
load.  ARM64 gcc uses brk #1000 after trying a NULL-pointer load.)

If the block that would return isn't at the end of the function, then the
fall-through would be into another block of the current function.  This is
potentially hard to debug, so probably an illegal instruction is a good idea,
maybe with an option to omit it.

Anything in a basic block that returns can be assumed not to be executed, so
the example from the original report could be compiled to:

  push {r4, lr}
 #  mov r5, r1# optionally optimize these out, because we know
 #  mov r4, r0# the code that uses them can't be reached.
  bl ext
   # don't emit the store
   # or the pop / bx lr
   # Fall through into padding.
   # Ideally pad with illegal instructions instead of NOPs

Hmm, unless the store faults, and that's what made this function not return. 
But we can definitely replace the pop/bx with an illegal instruction or a
fall-through, because executing them is guaranteed to be the wrong thing.

Making functions that almost works but violate the ABI seems like the worst
possible way to handle this corner case.  Crashing is better than silent
corruption when there's no correct way to continue execution, right?


> Compile time error is undesirable

That's what I thought, too.  -Werror exists for users that want that.

I only mentioned it for completeness, but good point that it's not an option
even when gcc can prove that a function returns, because it might never be
called. 

> , or say the
> return is only conditional and that path doesn't ever happen in a valid
> program, or say there are calls in the noreturn function that just throw
> exceptions or loop forever or abort or don't really return some other way.

That's a good point.  We don't want to save extra registers that a correct
program doesn't need saved, so ignoring the noreturn attribute and emitting
code to save/restore is not a good solution for the general case.

Illegal instruction or fall through into other code is left as the only
solution I think is really good.

[Bug libstdc++/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
The bug is that the symbols in lisbtdc++.so are attempting to delete the
_S_empty_rep_storage object, which suggests that this check is false when it
should be true:

  this != &_S_empty_rep()

That suggests we have multiple definitions of the empty rep symbol, which
aren't being combined.

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |5.5
Summary|loop gets miscompiled on|[5/6/7 Regression] loop
   |powerpc at -O2  |gets miscompiled on powerpc
   ||at -O2

--- Comment #2 from Richard Biener  ---
Can you try bisecting what introduced it?  May be similarly (un-)useful as the
fixing rev. of course.

[Bug libstdc++/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #7 from Jonathan Wakely  ---
Although that doesn't seem to work for the testcase in comment 5

[Bug libstdc++/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-21
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Jonathan Wakely  ---
Another workaround is to disable the explicit instantiation declarations:

// Include a libstdc++ header, so config macros are defined:
#include 
// Disable explicit insantiation declarations in later includes:
#undef _GLIBCXX_EXTERN_TEMPLATE
#include 

int main()
{
std::stringbuf myStringBuf{};
myStringBuf.sputc('a');
return 0;
}

This suggests the explicit instantiations in libstdc++.so are incompatible with
the C++17 declarations in the headers.

[Bug target/82271] loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

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

Franz Sirl  changed:

   What|Removed |Added

  Known to work||4.5.4, 4.6.4, 4.7.4
  Known to fail||4.8.0, 4.8.5, 5.4.0, 6.4.0,
   ||7.2.0

--- Comment #1 from Franz Sirl  ---
I was slightly wrong, 4.7 works. Further testing shows that 4.5.4, 4.6.4 and
4.7.4 are OK, starting with 4.8.0 the loop gets miscompiled.

[Bug target/82274] __builtin_mul_overflow fails to detect overflow for int64_t when compiled with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Testcase that fails also on x86_64 -m64 (again, without optimizations only,
with optimizations we fold it at compile time):

int
main ()
{
#ifdef __SIZEOF_INT128__
  __int128 m = -(((__int128) 1) << (__CHAR_BIT__ * __SIZEOF_INT128__ / 2));
  __int128 r;
#else
  long long m = -(1LL << (__CHAR_BIT__ * __SIZEOF_LONG_LONG__ / 2));
  long long r;
#endif
  if (!__builtin_mul_overflow (m, m, ))
__builtin_abort ();
  return 0;
}

[Bug c/81854] weak alias of an incompatible symbol accepted

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
gcc.target/i386/pr80732.c fails with:

pr80732.c:46:8: warning: ‘f2’ ‘ifunc’ resolver should return a function pointer
[-Wattributes]
 double f2(double a, double b, double c) __attribute__((ifunc("f2_resolve")));
^~
pr80732.c:37:14: note: resolver declaration here
 static void *f2_resolve(void)
  ^~

[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 21 10:08:21 2017
New Revision: 253052

URL: https://gcc.gnu.org/viewcvs?rev=253052=gcc=rev
Log:
2017-09-21  Richard Biener  

PR tree-optimization/71351
* graphite-isl-ast-to-gimple.c (translate_isl_ast_to_gimple::
graphite_create_new_loop_guard): Remove, fold remaining parts
into caller ...
(translate_isl_ast_node_for): ... here and simplify.

* gfortran.dg/graphite/pr71351.f90: New testcase.
* gfortran.dg/graphite/interchange-3.f90: Adjust.

Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr71351.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/graphite/interchange-3.f90

[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] ICE:   |[7 Regression] ICE:
   |Segmentation fault  |Segmentation fault
   |(graphite)  |(graphite)

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

[Bug target/82158] _Noreturn functions that do return clobber caller's registers on ARM32 (but not other arches)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #9 from Jakub Jelinek  ---
None of the above options is IMHO acceptable.
This is UB like any other.

What we could add is -fsanitize=noreturn that would add runtime instrumentation
that noreturn functions don't return, but it certainly shouldn't be the
default, it can be included in -fsanitize=undefined to catch for that UB like
any other UB it catches.
Compile time error is undesirable, it isn't an error if a noreturn function
could return, the error is if it does return at runtime, which you really can't
prove.  Either the function isn't called in the program, or say the return is
only conditional and that path doesn't ever happen in a valid program, or say
there are calls in the noreturn function that just throw exceptions or loop
forever or abort or don't really return some other way.

[Bug target/82274] __builtin_mul_overflow fails to detect overflow for int64_t when compiled with -m32

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-21
 Ever confirmed|0   |1
  Known to fail||5.1.0, 7.2.0

--- Comment #2 from Richard Biener  ---
Confirmed.  Not a regression.

[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to David Binderman from comment #8)
> (In reply to David Binderman from comment #7)
> > Still seems to be broken, over a month later.
> 
> Still broken, a couple of months even later ...

Broken for over four months now.

[Bug target/82260] [x86] Unnecessary use of 8-bit registers with -Os. slightly slower and larger code

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for 8+.
For the rest please file separate PR or PRs.
GCC -Os is something in between llvm -Oz and -Os, we aren't trying to reduce
size at all costs, but are certainly trying more than llvm -Os does.

[Bug tree-optimization/82276] [8 Regression] -O2: ICE: SSA corruption during RTL pass: expand; at tree-ssa-coalesce.c:1010

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-21
 Blocks||82244
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|-O2: ICE: SSA corruption|[8 Regression] -O2: ICE:
   |during RTL pass: expand; at |SSA corruption during RTL
   |tree-ssa-coalesce.c:1010|pass: expand; at
   ||tree-ssa-coalesce.c:1010
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Hmpf, I fear the simplest solution will be to cease inserting ASSERT_EXPRs for
abnormals...  With doing those insertions VRP is breaking SSA form by creating
overlapping life ranges.  By forcefully propagating those out it'll succeed
in restoring valid SSA form but with now propagating into asserts themselves
we've made that impossible.

And the propagation happens because when inserting asserts we have

f_27 = ASSERT_EXPR 
...
f_28(ab) = ASSERT_EXPR 

so propagating zero into f_27 looks valid.

So what works is ensuring the abnormal flag is sticky during the assert chain:

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 253049)
+++ gcc/tree-vrp.c  (working copy)
@@ -4518,7 +4518,9 @@ build_assert_expr_for (tree cond, tree v
  operand of the ASSERT_EXPR.  Create it so the new name and the old one
  are registered in the replacement table so that we can fix the SSA web
  after adding all the ASSERT_EXPRs.  */
-  create_new_def_for (v, assertion, NULL);
+  tree new_def = create_new_def_for (v, assertion, NULL);
+  if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (v))
+SSA_NAME_OCCURS_IN_ABNORMAL_PHI (new_def) = 1;

   return assertion;
 }

and the earlier patch should be revertable.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82244
[Bug 82244] [7 Regression] -O2: ICE: tree check: expected ssa_name, have
integer_cst in replace_uses_by, at tree-cfg.c:1904