[Bug tree-optimization/84746] New: ICE on valid code at -O2 and -O3: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 84746
   Summary: ICE on valid code at -O2 and -O3: Segmentation fault
   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.1/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.1 20180307 (experimental) [trunk revision 258312] (GCC) 
$ 
$ gcctk -Os -c small.c
$ gcc-7.2.0 -O2 -c small.c
$ 
$ gcctk -O2 -c small.c
during GIMPLE pass: pre
small.c: In function ‘fn1’:
small.c:4:6: internal compiler error: Segmentation fault
 void fn1 ()
  ^~~
0xca7f6f crash_signal
../../gcc-source-trunk/gcc/toplev.c:325
0xedd700 update_dep_bb
../../gcc-source-trunk/gcc/tree-ssa-tail-merge.c:402
0xedfbf9 same_succ_hash
../../gcc-source-trunk/gcc/tree-ssa-tail-merge.c:506
0xedfbf9 find_same_succ_bb
../../gcc-source-trunk/gcc/tree-ssa-tail-merge.c:717
0xee00ff find_same_succ
../../gcc-source-trunk/gcc/tree-ssa-tail-merge.c:748
0xee00ff init_worklist
../../gcc-source-trunk/gcc/tree-ssa-tail-merge.c:767
0xee00ff tail_merge_optimize(unsigned int)
../../gcc-source-trunk/gcc/tree-ssa-tail-merge.c:1733
0xe7c6b6 execute
../../gcc-source-trunk/gcc/tree-ssa-pre.c:4196
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


int a, b, c, d, e;
char f, g;

void fn1 ()
{
  while (1)
{
  if (d)
goto L1;
  if (e)
goto L3;
  int q = (c && a) % (f * (d || a)) && b;
  e = q;
  if (b)
break;
L1:
L2:
  c = f;
L3:
  f = g;
  while (a)
goto L2;
}
}

[Bug c++/84684] inserting random code / flags produces wrong code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #19 from Marek Polacek  ---
Fixed.

[Bug c++/84684] inserting random code / flags produces wrong code

[mpolacek at gcc dot gnu.org]

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

--- Comment #18 from Marek Polacek  ---
Author: mpolacek
Date: Wed Mar  7 07:50:57 2018
New Revision: 258313

URL: https://gcc.gnu.org/viewcvs?rev=258313=gcc=rev
Log:
PR c++/84684
* constexpr.c (cxx_bind_parameters_in_call): Unshare evaluated
arguments.

* g++.dg/cpp1z/constexpr-84684.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-84684.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[developm...@faf-ltd.com]

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

--- Comment #6 from Peter VARGA  ---
(In reply to Marc Glisse from comment #5)
> That's not how you use a different glibc. If you look at the include order
> printed by -v, it has to remain in that order (libstdc++ before glibc, in
> particular), whereas you are adding your glibc in front. Best would be to
> recompile gcc, which has the added advantage that it will be able to take
> advantage of the new features in the new glibc this way.

May be for you all is clear but I am not in the gnu gcc developer team and I am
using only gcc. Therefore I don't really understand what I should do. You all
give just half of some hints and they don't even work.

What should I do different when I recompile gcc?

This works - but why should I do it? Why is g++ using the path /usr/include
BEFORE the others and this is the problem! gcc does NOT keep the include order.

g++ foo.cpp -o foo -nostdinc -I /FaF/include/c++/7.3 -I
/FaF/include/c++/7.3/x86_64-suse-linux/ -I /FaF/glibc/include/ -I
/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include

In /FaF is my gcc 7.3 and in /FaF/glibc is glibc 2.27

[Bug c++/84745] New: internal compiler error: Segmentation fault (main_block_label())

[vegard.nossum at gmail dot com]

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

Bug ID: 84745
   Summary: internal compiler error: Segmentation fault
(main_block_label())
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---

Input:

void a() {
  alignof(({
b: 0;
  }));
  goto b;
}

Output:

$ xgcc -x c++ -S -
during GIMPLE pass: cfg
: In function 'void a()':
:1:6: internal compiler error: Segmentation fault
0x3152ce9 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x32834db main_block_label
/home/vegard/git/gcc/gcc/tree-cfg.c:1496
0x3292fff cleanup_dead_labels()
/home/vegard/git/gcc/gcc/tree-cfg.c:1679
0x32f0b70 build_gimple_cfg
/home/vegard/git/gcc/gcc/tree-cfg.c:240
0x32f0b70 execute_build_cfg
/home/vegard/git/gcc/gcc/tree-cfg.c:410
0x32f0b70 execute
/home/vegard/git/gcc/gcc/tree-cfg.c:446

$ xgcc --version
xgcc (GCC) 8.0.1 20180306 (experimental)

Built from git 11a93d7a09b871b3b9a2eb108eb91ad83d94e070 (r258271).

Funnily, clang also segfaults on this exact input.

Test case was minimised by C-Reduce.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
That's not how you use a different glibc. If you look at the include order
printed by -v, it has to remain in that order (libstdc++ before glibc, in
particular), whereas you are adding your glibc in front. Best would be to
recompile gcc, which has the added advantage that it will be able to take
advantage of the new features in the new glibc this way.

[Bug fortran/57197] [Fortran-Dev][Regression] ICE in record_reference, at cgraphbuild.c:66

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Blocks||56818
 Resolution|--- |FIXED

--- Comment #4 from Dominique d'Humieres  ---
> The code in comment one compiles without a problem.
> Can this be closed as fixed.

It even compiles with fortran-dev revision 240290 (2016-09-19).
Closing.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56818
[Bug 56818] [meta-bug] fortran-dev bugs

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominiq at lps dot ens.fr]

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

Bug 57197 Summary: [Fortran-Dev][Regression] ICE in record_reference, at 
cgraphbuild.c:66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57197

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/57197] [Fortran-Dev][Regression] ICE in record_reference, at cgraphbuild.c:66

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
The code in comment one compiles without a problem.
Can this be closed as fixed.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

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

--- Comment #13 from Kevin Buettner  ---
(In reply to Kevin Buettner from comment #11)

> This code, which is in find_pc_partial_function_gnu_ifunc(), incorrectly
> identifies this address, 0x400590, as belonging to qux:
> 
>   if (mapped_pc >= cache_pc_function_low
>   && mapped_pc < cache_pc_function_high
>   && section == cache_pc_function_section)
> goto return_cached_value;

I've determined that if this code is disabled, then things work.  I'm not
suggesting this as a fix, just adding another data point.

[Bug fortran/64107] [F95] Pure function as array size

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Closing as fixed on trunk.  Thanks for bug report.

[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures

[kargl at gcc dot gnu.org]

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

Bug 64107 Summary: [F95] Pure function as array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64107

   What|Removed |Added

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

[Bug fortran/64107] [F95] Pure function as array size

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Mar  7 00:25:30 2018
New Revision: 258311

URL: https://gcc.gnu.org/viewcvs?rev=258311=gcc=rev
Log:
2018-03-06  Steven G. Kargl  

PR fortran/64107
* gfortran.dg/pr64107.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr64107.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

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

--- Comment #12 from Kevin Buettner  ---
I'll note, too, that just setting a breakpoint on qux and then looking at the
locations reveals another problem...

(gdb) b qux
Breakpoint 1 at 0x400460: qux. (2 locations)
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y
1.1 y 0x00400460 in qux(C*) at vau2.c:24
1.2 y 0x004005b0 in qux(C*) at vau2.c:24
(gdb) x/4i 0x400460
   0x400460 :  callq  0x400430 
   0x400465:nopw   %cs:0x0(%rax,%rax,1)
   0x40046f:nop
   0x400470 :   sub$0x28,%rsp
(gdb) x/4i 0x4005b0
   0x4005b0 <_Z3quxP1C>:push   %rbx
   0x4005b1 <_Z3quxP1C+1>:  mov(%rdi),%rax
   0x4005b4 <_Z3quxP1C+4>:  test   %rax,%rax
   0x4005b7 <_Z3quxP1C+7>:  je 0x400460 

Placing a breakpoint on 0x400460 is incorrect since this is not an actual entry
point to the function.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

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

--- Comment #11 from Kevin Buettner  ---
I've simplified Jakub's example slightly:

--- vau2.c ---
struct A { int a; };
struct B { struct A *b; };
struct C { struct B *c; };

__attribute__((noipa)) bool
foo (struct A *p)
{
  return false;
}

__attribute__((noipa)) int
baz (int x)
{
  return 0;
}

__attribute__((noipa)) void
qux (struct C *p)
{
  struct A *a;
  bool b;
  int c;

  if (!p->c) __builtin_abort ();
  a = p->c->b;

  b = (a->a == 4)
&& (foo (a));

  c = baz (0);
  baz (b);
}

int
main ()
{
  struct A a = { 4 };
  struct B b = {  };
  struct C c = {  };
  qux ();
  return 0;
}
--- end vau2.c ---

When I compile this via "g++ -O2 -g vau2.c -o vau2", and load it into gdb, it
exhibits the same behavior shown by Jakub.  I.e. the following sequence...

b qux
run
s
s
s

... does not stop in foo as expected.  The program instead exits.

It turns out that qux consists of two disjoint pieces which, for some reason,
are separated by a lot of other code, e.g. main, _start, foo, baz, and a lot of
other stuff too.  Here's what it looks like:

   0x400460 :  callq  0x400430 
   0x400465:nopw   %cs:0x0(%rax,%rax,1)
   0x40046f:nop
   0x400470 :   sub$0x28,%rsp
   0x400474 : lea0xc(%rsp),%rax
   0x400479 : lea0x18(%rsp),%rdi
   0x40047e :movl   $0x4,0xc(%rsp)
   0x400486 :mov%rax,0x10(%rsp)
   0x40048b :lea0x10(%rsp),%rax
   0x400490 :mov%rax,0x18(%rsp)
   0x400495 :callq  0x4005b0 <_Z3quxP1C>
   0x40049a :xor%eax,%eax
   0x40049c :add$0x28,%rsp
   0x4004a0 :retq   
   0x4004a1:nopw   %cs:0x0(%rax,%rax,1)
   0x4004ab:nopl   0x0(%rax,%rax,1)
   0x4004b0 <_start>:   xor%ebp,%ebp
   0x4004b2 <_start+2>: mov%rdx,%r9
   0x4004b5 <_start+5>: pop%rsi
   0x4004b6 <_start+6>: mov%rsp,%rdx
   0x4004b9 <_start+9>: and$0xfff0,%rsp
   0x4004bd <_start+13>:push   %rax
   0x4004be <_start+14>:push   %rsp
   0x4004bf <_start+15>:mov$0x400660,%r8
   0x4004c6 <_start+22>:mov$0x4005f0,%rcx
   0x4004cd <_start+29>:mov$0x400470,%rdi
   0x4004d4 <_start+36>:callq  0x400440 <__libc_start_main@plt>
   0x4004d9 <_start+41>:hlt
...
   0x400590 :  xor%eax,%eax
   0x400592 :retq   
   0x400593:nopl   (%rax)
   0x400596:nopw   %cs:0x0(%rax,%rax,1)
   0x4005a0 : xor%eax,%eax
   0x4005a2 :   retq   
   0x4005a3:nopl   (%rax)
   0x4005a6:nopw   %cs:0x0(%rax,%rax,1)
   0x4005b0 <_Z3quxP1C>:push   %rbx
   0x4005b1 <_Z3quxP1C+1>:  mov(%rdi),%rax
   0x4005b4 <_Z3quxP1C+4>:  test   %rax,%rax
   0x4005b7 <_Z3quxP1C+7>:  je 0x400460 
   0x4005bd <_Z3quxP1C+13>: mov(%rax),%rdi
   0x4005c0 <_Z3quxP1C+16>: xor%ebx,%ebx
   0x4005c2 <_Z3quxP1C+18>: cmpl   $0x4,(%rdi)
   0x4005c5 <_Z3quxP1C+21>: je 0x4005d8 <_Z3quxP1C+40>
   0x4005c7 <_Z3quxP1C+23>: xor%edi,%edi
   0x4005c9 <_Z3quxP1C+25>: callq  0x4005a0 
   0x4005ce <_Z3quxP1C+30>: mov%ebx,%edi
   0x4005d0 <_Z3quxP1C+32>: pop%rbx
   0x4005d1 <_Z3quxP1C+33>: jmp0x4005a0 
   0x4005d3 <_Z3quxP1C+35>: nopl   0x0(%rax,%rax,1)
   0x4005d8 <_Z3quxP1C+40>: callq  0x400590 
   0x4005dd <_Z3quxP1C+45>: xor%edi,%edi
   0x4005df <_Z3quxP1C+47>: movzbl %al,%ebx
   0x4005e2 <_Z3quxP1C+50>: callq  0x4005a0 
   0x4005e7 <_Z3quxP1C+55>: mov%ebx,%edi
   0x4005e9 <_Z3quxP1C+57>: pop%rbx
   0x4005ea <_Z3quxP1C+58>: jmp0x4005a0 
   0x4005ec:nopl   0x0(%rax)

Within GDB, this is where things go wrong:

top-gdb> bt 4
#0  find_pc_partial_function_gnu_ifunc (pc=4195728, name=0x7fffdd28, 
address=0x7fffdd18, endaddr=0x7fffdd20, is_gnu_ifunc_p=0x0)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/blockframe.c:213
#1  0x00553281 in find_pc_partial_function (pc=4195728, 
name=0x7fffdd28, address=0x7fffdd18, endaddr=0x7fffdd20)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/blockframe.c:323
#2  0x006b6aec in fill_in_stop_func (gdbarch=0x1249170, 
ecs=0x7fffdcd0)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/infrun.c:4303
#3  0x006baf13 in process_event_stop_test (ecs=0x7fffdcd0)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/infrun.c:6494

That pc value is actually the first address for foo(), which is what we want:

top-gdb> p/x pc
$22 = 0x400590

(Refer to my 

[Bug fortran/84697] [8 Regression] minloc/maxloc not simplified with zero size

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[tkoenig at gcc dot gnu.org]

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

Bug 84697 Summary: [8 Regression] minloc/maxloc not simplified with zero size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84697

   What|Removed |Added

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

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Mar  6 23:50:01 2018
New Revision: 258305

URL: https://gcc.gnu.org/viewcvs?rev=258305=gcc=rev
Log:
2017-03-06  Thomas Koenig  

PR fortran/84697
PR fortran/66128
* expr.c (simplify_parameter_variable): If p is a size zero array
and not an ARRAY_EXPR insert an empty array constructor and
return.
* gfortran.h: Add prototype for gfc_is_size_zero_array.
* simplify.c (is_size_zero_array): Make non-static and rename into
(gfc_is_size_zero_array):  Check for parameter arrays of zero
size by comparing shape and absence of constructor.
(gfc_simplify_all): Use gfc_is_size_zero_array instead of
is_size_zero_array.
(gfc_simplify_count): Likewise.
(gfc_simplify_iall): Likewise.
(gfc_simplify_iany): Likewise.
(gfc_simplify_iparity): Likewise.
(gfc_simplify_minval): Likewise.
(gfc_simplify_maxval): Likewise.
(gfc_simplify_product): Likewise.
(gfc_simplify_sum): Likewise.

2017-03-06  Thomas Koenig  

PR fortran/84697
PR fortran/66128
* gfortran.dg/minmaxloc_zerosize_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/minmaxloc_zerosize_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84697] [8 Regression] minloc/maxloc not simplified with zero size

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Mar  6 23:50:01 2018
New Revision: 258305

URL: https://gcc.gnu.org/viewcvs?rev=258305=gcc=rev
Log:
2017-03-06  Thomas Koenig  

PR fortran/84697
PR fortran/66128
* expr.c (simplify_parameter_variable): If p is a size zero array
and not an ARRAY_EXPR insert an empty array constructor and
return.
* gfortran.h: Add prototype for gfc_is_size_zero_array.
* simplify.c (is_size_zero_array): Make non-static and rename into
(gfc_is_size_zero_array):  Check for parameter arrays of zero
size by comparing shape and absence of constructor.
(gfc_simplify_all): Use gfc_is_size_zero_array instead of
is_size_zero_array.
(gfc_simplify_count): Likewise.
(gfc_simplify_iall): Likewise.
(gfc_simplify_iany): Likewise.
(gfc_simplify_iparity): Likewise.
(gfc_simplify_minval): Likewise.
(gfc_simplify_maxval): Likewise.
(gfc_simplify_product): Likewise.
(gfc_simplify_sum): Likewise.

2017-03-06  Thomas Koenig  

PR fortran/84697
PR fortran/66128
* gfortran.dg/minmaxloc_zerosize_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/minmaxloc_zerosize_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[developm...@faf-ltd.com]

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

--- Comment #4 from Peter VARGA  ---
(In reply to Andrew Pinski from comment #1)
> >-I /FaF/glibc/include
> 
> Use -isystem instead or a true sysroot instead.

Can you post the full g++ command line options how you mean it?

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[developm...@faf-ltd.com]

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

--- Comment #3 from Peter VARGA  ---
(In reply to Andrew Pinski from comment #1)
> >-I /FaF/glibc/include
> 
> Use -isystem instead or a true sysroot instead.

Sorry, but this does not help.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[developm...@faf-ltd.com]

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

--- Comment #2 from Peter VARGA  ---
Sorry, but this does not help.

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>-I /FaF/glibc/include

Use -isystem instead or a true sysroot instead.

[Bug c++/84744] New: cannot use glibc 2.27 with gcc 7.3

[developm...@faf-ltd.com]

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

Bug ID: 84744
   Summary: cannot use glibc 2.27 with gcc 7.3
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: developm...@faf-ltd.com
  Target Milestone: ---

Created attachment 43581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43581=edit
error messages

I have installed gcc 7.3 in the /FaF directory and glibc 2.27 in the /FaF/glibc
directory.

Compiling this code
---

#include 
#include 
int main( int argc, char * argv [] )
{
if ( argc != 2 )
{
return 1;
}
return std::abs(std::atoi(argv[1]));
}

with g++ -c foo.cpp works fine.

Adding the glibc 2.27 include path fails horrible: g++ -c foo.cpp -I
/FaF/glibc/include

Here the full error list: https://gofile.io/?c=J2Zwlv or see the attached file.

Compiling it with the system gcc 4.8.5 works fine even the glibc 2.27 include
path is added.

Output for g++ -xc++ -E -v - -I /FaF/glibc/include/
---

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-suse-linux
Configured with: ../gcc-7.3.0/configure --prefix=/FaF --infodir=/FaF/share/info
--mandir=/FaF/share/man --libdir=/FaF/lib64 --libexecdir=/FaF/lib64
--enable-languages=c,c++ --enable-checking=release --with-gmp=/FaF/
--with-mpfr=/FaF --with-gmc=/FaF --with-gxx-include-dir=/FaF/include/c++/7.3
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/--with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-7.3 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux --disable-multilib
Thread model: posix
gcc version 7.3.0 (SUSE Linux)
COLLECT_GCC_OPTIONS='-E' '-v' '-I' '/FaF/glibc/include/' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/cc1plus -E -quiet -v -I
/FaF/glibc/include/ -D_GNU_SOURCE - -mtune=generic -march=x86-64
ignoring nonexistent directory
"/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/../../../../x86_64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /FaF/glibc/include/
 /FaF/include/c++/7.3
 /FaF/include/c++/7.3/x86_64-suse-linux
 /FaF/include/c++/7.3/backward
 /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include
 /usr/local/include
 /FaF/include
 /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include-fixed
 /usr/include
End of search list.

First error lines - for some reasons g++ starts to use the g++ starts to use
the g++ 4.8.5 - which is installed on the system - include path.



In file included from /usr/include/math.h:48:0,
 from /FaF/include/c++/7.3/cmath:45,
 from foo.cpp:11:
/FaF/glibc/include/bits/mathdef.h:19:3: error: #error "Never use
 directly; include  instead"
 # error "Never use  directly; include  instead"
   ^
In file included from /FaF/include/c++/7.3/cstdlib:75:0,
 from foo.cpp:10:
/usr/include/stdlib.h:95:1: error: ‘__BEGIN_NAMESPACE_STD’ does not name a
type; did you mean ‘__BEGIN_DECLS’?
 __BEGIN_NAMESPACE_STD
 ^
 __BEGIN_DECLS
/usr/include/stdlib.h:101:5: error: ‘div_t’ does not name a type; did you mean
‘size_t’?
   } div_t;
 ^

[Bug fortran/64124] [F95] Valid constant expr rejected

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
I think my patch for PR 70409 also fixes this one.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[palves at redhat dot com]

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

--- Comment #10 from Pedro Alves  ---
It sounds that way, but I haven't verified, e.g., by trying older versions of
gdb, and/or bisecting.

Kevin, in addition to trying older versions of gdb with
freorder-blocks-and-partition, I'm curious about why gdb finds different ends
of prologue when stepping vs when setting a breakpoint.  It may be that making
both spots use the same logic (e.g., it may one is skipping instructions
manually using the heuristic unwinders and another is using the line tables)
will be good enough of a stopgap to unblock this bug.

[Bug tree-optimization/84739] [6/7/8 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Untested fix:
--- gcc/tree-tailcall.c.jj  2018-01-12 11:35:51.470222838 +0100
+++ gcc/tree-tailcall.c 2018-03-06 23:05:39.779048759 +0100
@@ -481,7 +481,7 @@ find_tail_calls (basic_block bb, struct
 {
   tree arg;

-  for (param = DECL_ARGUMENTS (func), idx = 0;
+  for (param = DECL_ARGUMENTS (current_function_decl), idx = 0;
   param && idx < gimple_call_num_args (call);
   param = DECL_CHAIN (param), idx ++)
{

Wonder if the bug is also reproduceable when the gimple call has some different
fntype.

[Bug inline-asm/84677] internal compiler error: in extract_constrain_insn, at recog.c:2205

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Doesn't need the "-x c++".

Started somewhere between r229464 (unaffected) and r229470 (affected); probably
r229470.

Running into this for gcc 8 due to:

2572  if (flag_checking)
2573check_rtl (true);

Is this valid code?  My asm-syntax knowledge isn't strong.

[Bug libstdc++/84601] [8 Regression] std::optional<std::pair<int, int>> is not assignment copyable

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #4 from Ville Voutilainen  ---
Fixed.

[Bug tree-optimization/84739] [6/7/8 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-06
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed.

The ICE in comment #1 started with r231428.

[Bug libstdc++/84601] [8 Regression] std::optional<std::pair<int, int>> is not assignment copyable

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Mar  6 21:43:03 2018
New Revision: 258304

URL: https://gcc.gnu.org/viewcvs?rev=258304=gcc=rev
Log:
PR libstdc++/84601
* include/std/optional (_Optional_payload): Split into multiple
specializations that can handle different cases of trivial or
non-trivial assignment operators.
* testsuite/20_util/optional/84601.cc: New.
* testsuite/20_util/optional/cons/value_neg.cc: Adjust.

Added:
trunk/libstdc++-v3/testsuite/20_util/optional/84601.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/optional
trunk/libstdc++-v3/testsuite/20_util/optional/cons/value_neg.cc

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #16)
> (In reply to Jakub Jelinek from comment #13)
> > E.g. could we walk into TARGET_EXPRs that have TARGET_EXPR_INITIAL
> > AGGR_INIT_EXPR, but avoid those that have TARGET_EXPR_INITIAL a CONSTRUCTOR,
> > or a CONSTRUCTOR with certain flags, or have some flags on TARGET_EXPRs?
> 
> No, the form of the TARGET_EXPR isn't sufficient to distinguish.  Here's a
> complete testcase:
> 
> struct X {
>   unsigned i;
>   unsigned n = i;
> };
> 
> X bar(X x) {
>   return x;
> }
> 
> struct Y
> {
>   static Y bar(Y y) { return y; }
>   unsigned i;
>   unsigned n = bar(Y{2,i}).n;
> };
> 
> int main()
> {
>   X x { 1, bar(X{2}).n };
>   if (x.n != 2)
> __builtin_abort();
>   
>   Y y { 1 };
>   if (y.n != 1)
> __builtin_abort();
> }
> 
> Here, the initializers for x and y end up looking equivalent within
> store_init_value, but the PLACEHOLDER_EXPRs are meant to refer to different
> objects.  There's no way for replace_placeholders to tell the difference.
> 
> I think to handle this we'll need to change process_init_constructor_record
> to either not expose PLACEHOLDER_EXPRs, or adjust them to indicate better
> which CONSTRUCTOR they refer to.

Ah, ok, that indeed fails with my patch.  Couldn't we mark somewhere using a
new lang flag the CONSTRUCTORs that are supposed to be boundaries for the
PLACEHOLDER_EXPRs
(in the above testcase on
{.i=1, .n=(TARGET_EXPR i}>)>).n}
it would be the {.i=2, .n=(&)->i} CONSTRUCTOR
and on
{.i=1, .n=(TARGET_EXPR i}>)>).n}
it wouldn't mark any)?  Is it the case that PLACEHOLDER_EXPRs should always
bind to some containing CONSTRUCTOR and can't be intermixed (say one
PLACEHOLDER_EXPR binding to inner CONSTRUCTOR and some other PLACEHOLDER_EXPR
within the same CONSTRUCTOR binding to an outer CONSTRUCTOR?

Or do you want the #c12 patch as a partial fix for GCC8 and come up with a real
fix for GCC9?  Or do nothing for now, something else?

[Bug tree-optimization/84740] [8 Regression] ICE in build_constructors, at tree-switch-conversion.c:965

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I can take a look.

[Bug target/83969] [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Assignee|segher at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #11 from Peter Bergner  ---
(In reply to Peter Bergner from comment #10)
> +  /* Don't allow non-offsettable addresses.  See PRs 83969 and 84279.  */
> +  if (!offsettable_address_p (false, mode, addr))
>  return false;

Ok, I had one regression and that was caused by a TImode load that was at the
end of the valid offset range...meaning "addr" was ok for a offset address, but
we could not add one more offset, which is what offsettable_address_p() tests
for.  Looks like I just need to replace offsettable_address_p() with
rs6000_offsettable_memref_p().  That fixes the failing test case.  I'll
rebootstrap/regtest with that change.

[Bug c++/84684] inserting random code / flags produces wrong code

[mpolacek at gcc dot gnu.org]

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

--- Comment #17 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar  6 21:11:46 2018
New Revision: 258303

URL: https://gcc.gnu.org/viewcvs?rev=258303=gcc=rev
Log:
PR c++/84684
* constexpr.c (cxx_bind_parameters_in_call): Unshare evaluated
arguments.

* g++.dg/cpp1z/constexpr-84684.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-84684.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/64107] [F95] Pure function as array size

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This appears to be fixed by my patch for PR 83633.  I will
convert the code and add it as a testcase to trunk.

% gfcx -o z a.f90
a.f90:15:22:

   integer :: x2(foo())
  1
Error: Explicit shaped array with nonconstant bounds at (1)
a.f90:24:22:

   integer :: x4(foo())
  1
Error: Explicit shaped array with nonconstant bounds at (1)

[Bug c/84721] [8 Regression] ICE in c_push_function_context, at c-decl.c:9667

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/84710] [8 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1896 with -O -fno-forward-propagate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug c/84721] [8 Regression] ICE in c_push_function_context, at c-decl.c:9667

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  6 20:57:30 2018
New Revision: 258302

URL: https://gcc.gnu.org/viewcvs?rev=258302=gcc=rev
Log:
PR c/84721
* c-parser.c (add_debug_begin_stmt): Don't add DEBUG_BEGIN_STMT if
!building_stmt_list_p ().

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

Added:
trunk/gcc/testsuite/gcc.dg/pr84721.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84710] [8 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1896 with -O -fno-forward-propagate

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  6 20:41:37 2018
New Revision: 258301

URL: https://gcc.gnu.org/viewcvs?rev=258301=gcc=rev
Log:
PR target/84710
* combine.c (try_combine): Use reg_or_subregno instead of handling
just paradoxical SUBREGs and REGs.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr84710.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84740] [8 Regression] ICE in build_constructors, at tree-switch-conversion.c:965

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-06
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; assertion failure here:
#1  0x00e405ce in build_constructors (info=0x7fffdb80,
swtch=)
at ../../src/gcc/tree-switch-conversion.c:965

965   gcc_assert (!info->contiguous_range);

(gdb) p info->contiguous_range 
$1 = true

(gdb) call debug (info->range_min)
0
(gdb) call debug (info->range_max)
2

Started between r247528 (not affected) and r247538 (affected); probably
r247538.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #21 from Martin Liška  ---
Should be fixed now.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:07:49 2018
New Revision: 258300

URL: https://gcc.gnu.org/viewcvs?rev=258300=gcc=rev
Log:
Backport r257932

2018-03-06  Martin Liska  

Backport from mainline
2018-02-23  Segher Boessenkool  

PR testsuite/80551
* c-c++-common/tsan/race_on_mutex.c: Change regexp to allow
__GI___pthread_mutex_init as well.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c

[Bug other/80589] Typing mistakes in two messages

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:07:18 2018
New Revision: 258298

URL: https://gcc.gnu.org/viewcvs?rev=258298=gcc=rev
Log:
Backport r257803

2018-03-06  Martin Liska  

Backport from mainline
2018-02-19  Martin Liska  

PR other/80589
* doc/invoke.texi: Fix typo.
* params.def (PARAM_MAX_LOOP_HEADER_INSNS): Likewise.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/invoke.texi
branches/gcc-7-branch/gcc/params.def

[Bug c/84310] -falign-{labels,loops,jumps} with value >= 32768+1 cause a segfault

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:07:38 2018
New Revision: 258299

URL: https://gcc.gnu.org/viewcvs?rev=258299=gcc=rev
Log:
Backport r257842

2018-03-06  Martin Liska  

Backport from mainline
2018-02-20  Martin Liska  

PR c/84310
PR target/79747
* final.c (shorten_branches): Build align_tab array with one
more element.
* opts.c (finish_options): Add alignment option limit check.
(MAX_CODE_ALIGN): Likewise.
(MAX_CODE_ALIGN_VALUE): Likewise.
* doc/invoke.texi: Document maximum allowed option value for
all -falign-* options.
2018-03-06  Martin Liska  

Backport from mainline
2018-02-20  Martin Liska  

PR c/84310
PR target/79747
* gcc.target/i386/pr84310.c: New test.
* gcc.target/i386/pr84310-2.c: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr84310-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr84310.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/invoke.texi
branches/gcc-7-branch/gcc/final.c
branches/gcc-7-branch/gcc/opts.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/79747] Missing documentation for -malign-{jumps,label,loops,functions}= and strange value range limitation

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:07:38 2018
New Revision: 258299

URL: https://gcc.gnu.org/viewcvs?rev=258299=gcc=rev
Log:
Backport r257842

2018-03-06  Martin Liska  

Backport from mainline
2018-02-20  Martin Liska  

PR c/84310
PR target/79747
* final.c (shorten_branches): Build align_tab array with one
more element.
* opts.c (finish_options): Add alignment option limit check.
(MAX_CODE_ALIGN): Likewise.
(MAX_CODE_ALIGN_VALUE): Likewise.
* doc/invoke.texi: Document maximum allowed option value for
all -falign-* options.
2018-03-06  Martin Liska  

Backport from mainline
2018-02-20  Martin Liska  

PR c/84310
PR target/79747
* gcc.target/i386/pr84310.c: New test.
* gcc.target/i386/pr84310-2.c: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr84310-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr84310.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/invoke.texi
branches/gcc-7-branch/gcc/final.c
branches/gcc-7-branch/gcc/opts.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:06:45 2018
New Revision: 258296

URL: https://gcc.gnu.org/viewcvs?rev=258296=gcc=rev
Log:
Backport r257383

2018-03-06  Martin Liska  

Backport from mainline
2018-02-05  Martin Liska  

PR gcov-profile/83879
* doc/gcov.texi: Document necessity of --dynamic-list-data when
using dlopen functionality.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/gcov.texi

[Bug gcov-profile/84137] Typo in gcov online documentation

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:06:56 2018
New Revision: 258297

URL: https://gcc.gnu.org/viewcvs?rev=258297=gcc=rev
Log:
Backport r257384

2018-03-06  Martin Liska  

Backport from mainline
2018-02-05  Martin Liska  

PR gcov-profile/84137
* doc/gcov.texi: Fix typo in documentation.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/gcov.texi

[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:06:29 2018
New Revision: 258295

URL: https://gcc.gnu.org/viewcvs?rev=258295=gcc=rev
Log:
Backport r256989

2018-03-06  Martin Liska  

Backport from mainline
2018-01-23  Martin Liska  

PR lto/81440
* lto-symtab.c (lto_symtab_merge): Handle and do not warn about
trailing arrays at the end of a struct.
2018-03-06  Martin Liska  

Backport from mainline
2018-01-23  Martin Liska  

PR lto/81440
* gcc.dg/lto/pr81440.h: New test.
* gcc.dg/lto/pr81440_0.c: New test.
* gcc.dg/lto/pr81440_1.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/lto/pr81440.h
branches/gcc-7-branch/gcc/testsuite/gcc.dg/lto/pr81440_0.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/lto/pr81440_1.c
Modified:
branches/gcc-7-branch/gcc/lto/ChangeLog
branches/gcc-7-branch/gcc/lto/lto-symtab.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82675] ICE in duplicate_loop_to_header_edge at gcc/cfgloopmanip.c:1207

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:06:10 2018
New Revision: 258294

URL: https://gcc.gnu.org/viewcvs?rev=258294=gcc=rev
Log:
Backport r255818

2018-03-06  Martin Liska  

Backport from mainline
2017-12-19  Martin Liska  

PR rtl-optimization/82675
* loop-unroll.c (unroll_loop_constant_iterations): Allocate one
more element in sbitmap.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/loop-unroll.c

[Bug testsuite/79455] c-c++-common/tsan/race_on_mutex.c fails on powerpcle starting with r244854 (where it was activated)

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:05:52 2018
New Revision: 258293

URL: https://gcc.gnu.org/viewcvs?rev=258293=gcc=rev
Log:
Backport r247342

2018-03-06  Martin Liska  

Backport from mainline
2017-04-27  Martin Liska  

PR testsuite/79455
* c-c++-common/tsan/race_on_mutex.c: Make the scanned pattern
more generic.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c

[Bug c/84229] A valid code rejected with -flto

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:04:36 2018
New Revision: 258290

URL: https://gcc.gnu.org/viewcvs?rev=258290=gcc=rev
Log:
Backport r257877

2018-03-06  Martin Liska  

Backport from mainline
2018-02-21  Jan Hubicka  

PR c/84229
* ipa-cp.c (determine_versionability): Do not version functions caling
va_arg_pack.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/ipa-cp.c

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

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:04:20 2018
New Revision: 258289

URL: https://gcc.gnu.org/viewcvs?rev=258289=gcc=rev
Log:
Backport r257490

2018-03-06  Martin Liska  

Backport from mainline
2018-02-08  Jan Hubicka  

PR ipa/81360
* cgraph.h (symtab_node::output_to_lto_symbol_table_p): Declare
* symtab.c: Include builtins.h
(symtab_node::output_to_lto_symbol_table_p): Move here
from lto-streamer-out.c:output_symbol_p.
* lto-streamer-out.c (write_symbol): Turn early exit to assert.
(output_symbol_p): Move all logic to symtab.c
(produce_symtab): Update.
2018-03-06  Martin Liska  

Backport from mainline
2018-02-08  Jan Hubicka  

PR ipa/81360
* lto.c (unify_scc): Register prevailing trees, not trees to be freed.
(read_cgraph_and_symbols): Use
symtab_node::output_to_lto_symbol_table_p.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/cgraph.h
branches/gcc-7-branch/gcc/lto-streamer-out.c
branches/gcc-7-branch/gcc/lto/ChangeLog
branches/gcc-7-branch/gcc/lto/lto.c
branches/gcc-7-branch/gcc/symtab.c
branches/gcc-7-branch/gcc/tree.c

[Bug lto/81004] [7 Regression] linking failed with -flto and static libboost_program_options

[marxin at gcc dot gnu.org]

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

--- Comment #27 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:02:22 2018
New Revision: 258287

URL: https://gcc.gnu.org/viewcvs?rev=258287=gcc=rev
Log:
Backport r257412

2018-03-06  Martin Liska  

Backport from mainline
2018-01-30  Jan Hubicka  

PR lto/81004
* lto.c: Include builtins.h
(register_resolution): Merge resolutions in case trees was
merged across units.
(lto_maybe_register_decl): Break out from ...
(lto_read_decls): ... here.
(unify_scc): Also register decls here.
(read_cgraph_and_symbols): Sanity check that all resolutions was
read.

Modified:
branches/gcc-7-branch/gcc/lto/ChangeLog
branches/gcc-7-branch/gcc/lto/lto.c

[Bug lto/83954] [6/7 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:01:44 2018
New Revision: 258285

URL: https://gcc.gnu.org/viewcvs?rev=258285=gcc=rev
Log:
Backport r257183

2018-03-06  Martin Liska  

Backport from mainline
2018-01-30  Jan Hubicka  

PR lto/83954
* lto-symtab.c (warn_type_compatibility_p): Silence false positive
for type match warning on arrays of pointers.
2018-03-06  Martin Liska  

Backport from mainline
2018-01-30  Jan Hubicka  

PR lto/83954
* gcc.dg/lto/pr83954.h: New testcase.
* gcc.dg/lto/pr83954_0.c: New testcase.
* gcc.dg/lto/pr83954_1.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/lto/pr83954.h
branches/gcc-7-branch/gcc/testsuite/gcc.dg/lto/pr83954_0.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/lto/pr83954_1.c
Modified:
branches/gcc-7-branch/gcc/lto/ChangeLog
branches/gcc-7-branch/gcc/lto/lto-symtab.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug lto/83954] [6/7 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:02:03 2018
New Revision: 258286

URL: https://gcc.gnu.org/viewcvs?rev=258286=gcc=rev
Log:
Backport r257343

2018-03-06  Martin Liska  

Backport from mainline
2018-02-02  Eric Botcazou  

PR lto/83954
* lto-symtab.c (warn_type_compatibility_p): Do not recurse into the
component type of array types with non-aliased component.

Modified:
branches/gcc-7-branch/gcc/lto/ChangeLog
branches/gcc-7-branch/gcc/lto/lto-symtab.c

[Bug target/84743] default widths for parallel reassociation now hurt rather than help

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
This needs to be fixed before GCC 8 release.

[Bug target/84743] New: default widths for parallel reassociation now hurt rather than help

[acsawdey at gcc dot gnu.org]

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

Bug ID: 84743
   Summary: default widths for parallel reassociation now hurt
rather than help
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: acsawdey at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le power8

The width settings in rs6000_reassociation_width() were chosen to help
performance for SPEC CPU in gcc 7.

Testing on power8 shows that in gcc 8 (258101) there are now major degradations
in CPU2017 int with the default reassociation widths as compared to using
--param tree-reassoc-width=1 to disable reassociation.

Benchmark   
500.perlbench_r -5.98%
502.gcc_r   -1.16%
505.mcf_r   -12.44%
520.omnetpp_r   -39.00%
523.xalancbmk_r -9.78%
525.x264_r  -1.76%
531.deepsjeng_r -4.23%
548.exchange2_r -0.66%
557.xz_r-2.04%

[Bug fortran/56667] Syntax error causes misleading message: "Expected PARAMETER symbol in complex constant"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for bug report.

[Bug fortran/56667] Syntax error causes misleading message: "Expected PARAMETER symbol in complex constant"

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Mar  6 19:30:41 2018
New Revision: 258283

URL: https://gcc.gnu.org/viewcvs?rev=258283=gcc=rev
Log:
2018-03-06  Steven G. Kargl  

PR fortran/56667
* primary.c (match_sym_complex_part): Give the matcher for an implied
do-loop a chance to run.

2018-03-06  Steven G. Kargl  

PR fortran/56667
* gfortran.dg/implied_do_2.f90: New test.
* gfortran.dg/coarray_8.f90: Update for new error message.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/implied_do_2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/primary.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/coarray_8.f90

[Bug fortran/56667] Syntax error causes misleading message: "Expected PARAMETER symbol in complex constant"

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Mar  6 19:27:48 2018
New Revision: 258282

URL: https://gcc.gnu.org/viewcvs?rev=258282=gcc=rev
Log:
2018-03-06  Steven G. Kargl  

PR fortran/56667
* primary.c (match_sym_complex_part): Give the matcher for an implied
do-loop a chance to run.

2018-03-06  Steven G. Kargl  

PR fortran/56667
* gfortran.dg/implied_do_2.f90: New test.
* gfortran.dg/coarray_8.f90: Update for new error message.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/implied_do_2.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray_8.f90

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #13)
> E.g. could we walk into TARGET_EXPRs that have TARGET_EXPR_INITIAL
> AGGR_INIT_EXPR, but avoid those that have TARGET_EXPR_INITIAL a CONSTRUCTOR,
> or a CONSTRUCTOR with certain flags, or have some flags on TARGET_EXPRs?

No, the form of the TARGET_EXPR isn't sufficient to distinguish.  Here's a
complete testcase:

struct X {
  unsigned i;
  unsigned n = i;
};

X bar(X x) {
  return x;
}

struct Y
{
  static Y bar(Y y) { return y; }
  unsigned i;
  unsigned n = bar(Y{2,i}).n;
};

int main()
{
  X x { 1, bar(X{2}).n };
  if (x.n != 2)
__builtin_abort();

  Y y { 1 };
  if (y.n != 1)
__builtin_abort();
}

Here, the initializers for x and y end up looking equivalent within
store_init_value, but the PLACEHOLDER_EXPRs are meant to refer to different
objects.  There's no way for replace_placeholders to tell the difference.

I think to handle this we'll need to change process_init_constructor_record to
either not expose PLACEHOLDER_EXPRs, or adjust them to indicate better which
CONSTRUCTOR they refer to.

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[willschm at gcc dot gnu.org]

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

--- Comment #8 from Will Schmidt  ---
(In reply to Will Schmidt from comment #6)
> (In reply to Arseny Solokha from comment #5)
> > (In reply to Will Schmidt from comment #4)
> > > Tried to re-create locally, I've gotten two ICE's using the provided
> > > testcode snippet, neither look quite like the originally reported issue. 
> > 
> > You are right. I also cannot reproduce the original issue anymore w/ 
> > r257975.
> 
> Today I cannot get any ICE's out of this test.  Wonder if things were fixed
> up in the mean-time, or if I tickled a config option and managed to hide the
> issue(s).   Going to try a few more runs with older trees to see if I can
> verify things are fixed.

(In reply to Arseny Solokha from comment #7)
> OK, the original issue still reproduces for the powerpc-e500v2-linux-gnuspe
> target as of r257975, so the change that affected this issue must have been
> local to the rs6000 backend.

Ok.  so at the moment I'm going to claim that I am unable to recreate the
initially reported problem in my environments, which are 64-bit or 64/32 mixed.
 Nothing pure 32-bit here, nothing e300* or e500*, etc.

The ICe's that I did see (comment #4) seem to be to be a separate issue.  Those
only occur in my sandbox/debug build of gcc, which has
CFLAGS,CXXFLAGS,CFLAGS_FOR_BUILD, CFLAGS_FOR_TARGET, etc all  set to "-O0 -g3
-fno-inline".  I otherwise don't see any ICE with this test case.

[Bug fortran/56667] Syntax error causes misleading message: "Expected PARAMETER symbol in complex constant"

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Mar  6 19:05:48 2018
New Revision: 258281

URL: https://gcc.gnu.org/viewcvs?rev=258281=gcc=rev
Log:
2018-03-06  Steven G. Kargl  

PR fortran/56667
* primary.c (match_sym_complex_part): Give the matcher for an implied
do-loop a chance to run.

2018-03-06  Steven G. Kargl  

PR fortran/56667
* gfortran.dg/implied_do_2.f90: New test.
* gfortran.dg/coarray_8.f90: Update for new error message.

Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_8.f90

[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

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

--- Comment #7 from Will Schmidt  ---
fixed and backported.   Closing now.

[Bug tree-optimization/84739] [6/7/8 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |tree-optimization
   Target Milestone|--- |6.5

[Bug inline-asm/84742] New: internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[vegard.nossum at gmail dot com]

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

Bug ID: 84742
   Summary: internal compiler error: in process_alt_operands, at
lra-constraints.c:2112
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Created attachment 43580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43580=edit
valgrind output

Input:

void a() {
  char b;
  asm volatile ("" :
"+fm<rrggx<gT,ggg"
(b));
  {
try {
} catch (char ()) {
}
  }
}

Output:

$ xgcc -x c++ -S -std=c++14 -O3 -fpermissive -fno-toplevel-reorder -
during RTL pass: reload
: In function 'void a()':
:9:1: internal compiler error: in process_alt_operands, at
lra-constraints.c:2112
0x289cf5b process_alt_operands
/home/vegard/git/gcc/gcc/lra-constraints.c:2112
0x28a6043 curr_insn_transform
/home/vegard/git/gcc/gcc/lra-constraints.c:3860
0x28b93b6 lra_constraints(bool)
/home/vegard/git/gcc/gcc/lra-constraints.c:4877
0x2829984 lra(_IO_FILE*)
/home/vegard/git/gcc/gcc/lra.c:2419
0x2608794 do_reload
/home/vegard/git/gcc/gcc/ira.c:5465
0x2608794 execute
/home/vegard/git/gcc/gcc/ira.c:5649

$ xgcc --version
xgcc (GCC) 8.0.1 20180306 (experimental)

Built from git 11a93d7a09b871b3b9a2eb108eb91ad83d94e070 (r258271).

This one is a bit of a weird one. It doesn't reproduce with "trunk" on
godbolt.org for me and the crash itself is indeterministic. Sometimes the
compiler doesn't print anything and it returns 0, sometimes it hangs after
printing "during RTL pass: reload", and sometimes it gives the splat above
(about 1 in every 10 runs, I'd say). I recommend running it in a loop to
increase the chances of reproducing.

Valgrind shows a bunch of errors, this is the first one:

==31845== Conditional jump or move depends on uninitialised value(s)
==31845==at 0x2757C74: sparseset_bit_p (sparseset.h:147)
==31845==by 0x2757C74: mark_pseudo_regno_live(int) (ira-lives.c:289)
==31845==by 0x2760800: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1140)
==31845==by 0x2677F7D: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1806)
==31845==by 0x276BED9: ira_create_allocno_live_ranges() (ira-lives.c:1565)
==31845==by 0x2687F08: ira_build() (ira-build.c:3429)
==31845==by 0x2640C54: ira (ira.c:5295)
==31845==by 0x2640C54: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5606)
==31845==by 0x2B7EDA7: execute_one_pass(opt_pass*) (passes.c:2497)
==31845==by 0x2B84CFB: execute_pass_list_1(opt_pass*) [clone .constprop.89]
(passes.c:2586)
==31845==by 0x2B85DA0: execute_pass_list_1 (passes.c:2587)
==31845==by 0x2B85DA0: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==31845==by 0x19A118E: cgraph_node::expand() (cgraphunit.c:2139)
==31845==by 0x19AA5A7: expand_all_functions (cgraphunit.c:2275)
==31845==by 0x19AA5A7: symbol_table::compile() [clone .part.56]
(cgraphunit.c:2624)
==31845==by 0x19B84D7: compile (cgraphunit.c:2537)
==31845==by 0x19B84D7: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2717)

I've attached a full valgrind log as well, in case that helps.

Test case was minimised by C-Reduce.

[Bug target/83748] Local variables not aligned to word boundary

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #7 from Segher Boessenkool  ---
Closing this now.

This was fixed in 2013, in r205896 -- so should be fixed in 4.9 already.

That commit added this to the documentation:

 In some cases, such as when the 'packed' attribute is applied to a
 structure field, it may not be possible to access the field with a
 single read or write that is correctly aligned for the target
 machine.  In this case GCC falls back to generating multiple
 accesses rather than code that will fault or truncate the result at
 run time.

(and also added the code to implement it; as you noticed, older compilers
will do misaligned loads if you're not careful).

[Bug c/84741] New: [7/8 Regression] ICE in ix86_expand_prologue, at config/i386/i386.c:13893

[gs...@t-online.de]

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

Bug ID: 84741
   Summary: [7/8 Regression] ICE in ix86_expand_prologue, at
config/i386/i386.c:13893
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Starts to ICE from 20170129 on with option -fstack-usage.
File gcc/testsuite/gcc.dg/rtl/x86_64/test-return-const.c.after-expand.c


$ gcc-8-20180304 -c test-return-const.c.after-expand.c
$ gcc-8-20180304 -c test-return-const.c.after-expand.c -fstack-usage
during RTL pass: pro_and_epilogue
test-return-const.c.after-expand.c: In function 'test_returning_constant':
test-return-const.c.after-expand.c:32:1: internal compiler error: Segmentation
fault
 }
 ^
0xaed10f crash_signal
../../gcc/toplev.c:325
0xda329c ix86_expand_prologue()
../../gcc/config/i386/i386.c:13893
0xfc4cda gen_prologue()
../../gcc/config/i386/i386.md:13183
0xd8f588 target_gen_prologue
../../gcc/config/i386/i386.md:19561
0x88f139 make_prologue_seq
../../gcc/function.c:5926
0x88f352 thread_prologue_and_epilogue_insns()
../../gcc/function.c:6043
0x88f9f2 rest_of_handle_thread_prologue_and_epilogue
../../gcc/function.c:6534
0x88f9f2 execute
../../gcc/function.c:6576

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[sudi at gcc dot gnu.org]

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

--- Comment #16 from sudi at gcc dot gnu.org ---
So I think I would go with Jakub's suggestion of defining calls_builtin_setjmp
and use that in aarch64_layout_frame for cfun->machine->frame.emit_frame_chain.
I am still investigating Wilco's concern over pr60003.c

Also I would like to ask if we can pick up the discussions on PR59039 and on
the documentation patch. Some definition would be a lot more helpful for
someone like me who had no idea about __builtin_setjmp/longjmp to wrap my head
around what it actually is.

The macro DONT_USE_BUITIN_SETJMP made me very confused for a while until Ramana
pointed it out to me that its only used in the context of compiler's exception
unwinding machinery and does not apply to a case like this where the user calls
the builtin function. With this context in head when I went back and read the
document, it made sense. Can we possibly tweak the wording to make it clearer?

[Bug c/84740] New: [8 Regression] ICE in build_constructors, at tree-switch-conversion.c:965

[gs...@t-online.de]

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

Bug ID: 84740
   Summary: [8 Regression] ICE in build_constructors, at
tree-switch-conversion.c:965
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Gives an ICE at -O[s23] since at least 20170618.
Shrinked/modified from gcc.dg/tree-ssa/cswtch-4.c


$ cat z1.c
void
frobulate_for_gcc (unsigned int v)
{
  const char *s;
  switch (v)
{
case 0:
  s = "foo";
  break;
case 1:
  s = "bar";
  break;
case 2:
  s = "spam";
  break;
default:
  s = (const char *) 0;
  break;
}
  if (!s)
__builtin_printf ("%s\n", s);
}


$ gcc-7  -c z1.c -O2
$ gcc-8-20180304 -c z1.c -O1
$ gcc-8-20180304 -c z1.c -O2
during GIMPLE pass: switchconv
z1.c: In function 'frobulate_for_gcc':
z1.c:22:1: internal compiler error: in build_constructors, at
tree-switch-conversion.c:965
 }
 ^
0xbb98a0 build_constructors
../../gcc/tree-switch-conversion.c:965
0xbb98a0 process_switch
../../gcc/tree-switch-conversion.c:1566
0xbb98a0 execute
../../gcc/tree-switch-conversion.c:1630


No ICE without line "if (!s)".

[Bug c/84739] New: [6/7/8 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[gs...@t-online.de]

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

Bug ID: 84739
   Summary: [6/7/8 Regression] ICE in get_value_for_expr, at
tree-ssa-ccp.c:649
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions 6/7/8 at -O[s23] :


$ cat z1.c
static void baz (void) __attribute__((weakref("bar")));
int
foo (int x, int y)
{
  if (x)
y = 0;
  if (y)
goto L1;
  y = 0;
L1:
  return y;
}
void
bar (int x, int y)
{
  y = foo (x, y);
  if (y != 0)
baz ();
}


$ gcc-5 -O2 -c z1.c
$
$ gcc-8-20180304 -O2 -c z1.c
z1.c:1:13: warning: 'baz' alias between functions of incompatible types
'void(void)' and 'void(int,  int)' [-Wattribute-alias]
 static void baz (void) __attribute__((weakref("bar")));
 ^~~
z1.c:14:1: note: aliased declaration here
 bar (int x, int y)
 ^~~
during GIMPLE pass: ccp
z1.c: In function 'bar':
z1.c:14:1: internal compiler error: Segmentation fault
0xaed10f crash_signal
../../gcc/toplev.c:325
0xbc5401 get_value_for_expr
../../gcc/tree-ssa-ccp.c:649
0xbc7ea8 ccp_propagate::visit_phi(gphi*)
../../gcc/tree-ssa-ccp.c:1133
0xc42778 ssa_propagation_engine::simulate_stmt(gimple*)
../../gcc/tree-ssa-propagate.c:233
0xc42992 ssa_propagation_engine::simulate_block(basic_block_def*)
../../gcc/tree-ssa-propagate.c:359
0xc43669 ssa_propagation_engine::ssa_propagate()
../../gcc/tree-ssa-propagate.c:800
0xbc4697 do_ssa_ccp
../../gcc/tree-ssa-ccp.c:2474
0xbc4697 execute
../../gcc/tree-ssa-ccp.c:2518

[Bug c/84739] [6/7/8 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Configured with --enable-checking=yes :


$ gcc-8-20180304 -O2 -c z1.c
z1.c:1:13: warning: 'baz' alias between functions of incompatible types
'void(void)' and 'void(int,  int)' [-Wattribute-alias]
 static void baz (void) __attribute__((weakref("bar")));
 ^~~
z1.c:14:1: note: aliased declaration here
 bar (int x, int y)
 ^~~
during GIMPLE pass: tailr
z1.c: In function 'bar':
z1.c:19:1: internal compiler error: in gimple_call_arg, at gimple.h:3179
 }
 ^
0xecae86 gimple_call_arg
../../gcc/gimple.h:3179
0xecae86 gimple_call_arg
../../gcc/gimple.h:3187
0xecae86 eliminate_tail_call
../../gcc/tree-tailcall.c:921
0xecae86 optimize_tail_call
../../gcc/tree-tailcall.c:953
0xecae86 tree_optimize_tail_calls_1
../../gcc/tree-tailcall.c:1082

[Bug libstdc++/84738] New: stack-overflow in regex_match

[jr98 at hotmail dot de]

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

Bug ID: 84738
   Summary: stack-overflow in regex_match
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jr98 at hotmail dot de
  Target Milestone: ---

The following code crashes with a stack-oveflow

Code: (min.cpp)
#include 
#include 

int main(int argc, char *argv[])
{
  std::regex re("y**{83}{72}b");
  std::regex_match("", re);
  return 0;
}

Compile comandline:
g++-7 -fsanitize=address -std=c++17 -O2 -g -ggdb min.cpp

Version:
g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-8ubuntu3.2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)

__GLIBCXX__ is 20171003

[Bug c++/70431] [C++11] Out of line defaulted copy constructor of a union does not compile.

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-06
 CC||jason at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Ville Voutilainen  ---
clang accepts the code.

[Bug c++/70431] [C++11] Out of line defaulted copy constructor of a union does not compile.

[raphael.kubo.da.costa at intel dot com]

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

Raphael Kubo da Costa  changed:

   What|Removed |Added

 CC||raphael.kubo.da.costa@intel
   ||.com

--- Comment #1 from Raphael Kubo da Costa  ---
This is also true for classes and structs, I've just run into the same bug with
7.3.1 and 8.0.1 when debugging
https://chromium-review.googlesource.com/c/chromium/src/+/944403

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #2)
> I guess it somehow confuses VRP, Martin can you please take a look? Note
> that __builtin___sanitizer_cov_trace_pc is pure function, can't modify
> memory in original program.

No, __builtin___sanitizer_cov_trace_pc is certainly not pure and can't really
be, otherwise would optimize them all away (nothing uses their void return
value),
so the problem is that it invalidates all recorded string lengths, at least
those that escape (but in this testcase it is a global variable).
As __sanitizer_cov_trace_pc is a user-supplied function, I don't really think
we can assume anything on it (e.g. that it will not change any global or
escaped local variables, it can change them and most likely will do at least
some of them, otherwise it would be useless).

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
In general, by inserting their instrumentation the sanitizers cause all sorts
of trouble for middle-end warnings.  The usual answer has been to disable
-Werror when using -fsanitize.  Personally, I think that's less than optimal
(ideally we want both good static analysis and robust runtime detection), but
sometimes it may be the only viable solution.

The -Wstringop-truncation suppression logic looks for the next statement after
a strncpy call that writes a NUL into the destination (actually, it looks for
an assignment of any value to the destination for now, but that will likely
change in the future).  The __builtin___sanitizer_cov_trace_pc() call inserted
by the sanitizer just after the strncpy() call disables the suppression.

  __builtin_strncpy (, arg.0_1, 16);

   [local count: 1073741825]:
  __builtin___sanitizer_cov_trace_pc ();

There are other similar examples where this can happen (e.g., bug 84624).  It
might be possible to deal with some of them either by hardcoding a whitelist of
things to skip over, or by making the logic smart enough to see that some
calls/expressions cannot access (read from) the strncpy destination, or some
combination of the two.  Richi has been suggesting the latter approach.  The
challenge (for me) is to figure out how to avoid false negatives on things
like:

  void f (const char *s)
  {
char d[8];

char *p = strncpy (d, s, sizeof d);   // want a -Wstringop-truncation here

foo (p);   // reads a string from d

d[sizeof d - 1] = '\0';
  }

or even:

  extern char *p;

  void f (const char *s)
  {
char d[8];

p = strncpy (d, s, sizeof d);   // also want a -Wstringop-truncation here

foo ();   // also reads a string from d through p

d[sizeof d - 1] = '\0';
  }

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|ipa |tree-optimization
   Target Milestone|--- |8.0
Summary|20% degradation in CPU2000  |[8 Regression] 20%
   |172.mgrid starting with |degradation in CPU2000
   |r256888 |172.mgrid starting with
   ||r256888

[Bug ipa/84737] New: 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

Bug ID: 84737
   Summary: 20% degradation in CPU2000 172.mgrid starting with
r256888
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, marxin at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

I'm seeing a 20% degradation on 172.mgrid with r256888. Benchmark was built
with "-O3 -mcpu=power7 -ffast-math". Profiling shows the difference comes from
function resid() and its clone.

r256887
---
Counted PM_RUN_CYC events (Run_cycles.) with a unit mask of 0x00 (No unit mask)
count 10
samples  %image name   symbol name
658215   48.2563  mgrid_base.pat_test_64   .resid_
367381   26.9341  mgrid_base.pat_test_64   .psinv_
153587   11.2601  mgrid_base.pat_test_64   .interp_
1097858.0488  mgrid_base.pat_test_64   .rprj3_
52642 3.8594  mgrid_base.pat_test_64   .comm3_
7912  0.5801  mgrid_base.pat_test_64   .MAIN__
3796  0.2783  libc-2.17.so .__memset_power8



r256888
---
Counted PM_RUN_CYC events (Run_cycles.) with a unit mask of 0x00 (No unit mask)
count 10
samples  %image name   symbol name
1109100  59.2023  mgrid_base.gcc_hunt_64   .resid_.constprop.1
368930   19.6930  mgrid_base.gcc_hunt_64   .psinv_
1601028.5460  mgrid_base.gcc_hunt_64   .interp_
1149546.1361  mgrid_base.gcc_hunt_64   .MAIN__
55253 2.9493  mgrid_base.gcc_hunt_64   .comm3_
46903 2.5036  mgrid_base.gcc_hunt_64   .resid_
5103  0.2724  libc-2.17.so .__memset_power8

[Bug c++/84736] New: When compiling with -g -O2 internal compiler error: in force_type_die, at dwarf2out.c:25111

[kuba.skowron at gmail dot com]

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

Bug ID: 84736
   Summary: When compiling with -g -O2 internal compiler error: in
force_type_die, at dwarf2out.c:25111
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kuba.skowron at gmail dot com
  Target Milestone: ---

Created attachment 43579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43579=edit
Zipped first.ii file

There is internal compiler error when compiling with -g -O2 (ii file attached).

$ g++-7 -save-temps -Wall -g -O2 first.cpp
In file included from osd/OSD.cc:51:0:
osd/ReplicatedPG.h: In destructor ‘virtual
ReplicatedPG::WaitTrimTimer::WaitTrimTimer(boost::statechart::state::my_context)::OnTimer::~OnTimer()’:
osd/ReplicatedPG.h:1667:14: internal compiler error: in force_type_die, at
dwarf2out.c:25111
   struct OnTimer : Context {
  ^~~
0x8206ba force_type_die
../../src/gcc/dwarf2out.c:25111
0x82089b get_context_die
../../src/gcc/dwarf2out.c:25025
0x82089b force_decl_die
../../src/gcc/dwarf2out.c:25044
0x81ba47 gen_subprogram_die
../../src/gcc/dwarf2out.c:21905
0x816138 gen_decl_die
../../src/gcc/dwarf2out.c:25347
0x816e6e dwarf2out_decl
../../src/gcc/dwarf2out.c:25856
0x81cb42 dwarf2out_abstract_function
../../src/gcc/dwarf2out.c:21681
0xb46695 expand_call_inline
../../src/gcc/tree-inline.c:4887
0xb48084 gimple_expand_calls_inline
../../src/gcc/tree-inline.c:4917
0xb48084 optimize_inline_calls(tree_node*)
../../src/gcc/tree-inline.c:5057
0x113f6a9 early_inliner(function*)
../../src/gcc/ipa-inline.c:2721

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-1ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04)

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
My limited understanding is this is a GDB bug and that it basically never
worked properly with -freorder-blocks-and-partition.  So not really sure how we
could work around it in GCC.  Pedro, do you agree?

[Bug target/81572] [7 Regression] gcc-7 regression: unnecessary vector regmove on compare

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-02/msg01310.ht
   ||ml

--- Comment #8 from Peter Bergner  ---
Backport testing was clean.  Patch committed to the GCC 7 release branch.
Closing as fixed everywhere.

[Bug c++/81764] [6/7/8 Regression] Visibility attributes for explicitly instantiated template class get warned if it has been implicitly instantiated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/81572] [7 Regression] gcc-7 regression: unnecessary vector regmove on compare

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Tue Mar  6 15:54:30 2018
New Revision: 258280

URL: https://gcc.gnu.org/viewcvs?rev=258280=gcc=rev
Log:
gcc/
Backport from mainline
2018-02-22  Vladimir Makarov  

PR target/81572
* lra-int.h (LRA_UNKNOWN_ALT, LRA_NON_CLOBBERED_ALT): New macros.
* lra.c (lra_set_insn_recog_data, lra_update_insn_recog_data): Use
LRA_UNKNOWN_ALT.
* lra-constraints.c (curr_insn_transform): Set up
LRA_NON_CLOBBERED_ALT for moves processed on the fast path.  Use
LRA_UNKNOWN_ALT.
(remove_inheritance_pseudos): Use LRA_UNKNOWN_ALT.
* lra-eliminations.c (spill_pseudos): Ditto.
(process_insn_for_elimination): Ditto.
* lra-lives.c (reg_early_clobber_p): Use the new macros.
* lra-spills.c (spill_pseudos): Use LRA_UNKNOWN_ALT and
LRA_NON_CLOBBERED_ALT.

gcc/testsuite/
Backport from mainline
2018-02-22  Vladimir Makarov  

PR target/81572
* gcc.target/powerpc/pr81572.c: New.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr81572.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/lra-constraints.c
branches/gcc-7-branch/gcc/lra-eliminations.c
branches/gcc-7-branch/gcc/lra-int.h
branches/gcc-7-branch/gcc/lra-lives.c
branches/gcc-7-branch/gcc/lra-spills.c
branches/gcc-7-branch/gcc/lra.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Created attachment 43578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43578=edit
gcc8-pr79937.patch

Actually, seems TREE_HAS_CONSTRUCTOR is set on a CONSTRUCTOR only by
finish_compound_literal.  So if those are something we don't want to walk into
and everything else we do, then this patch might be it (passed make
check-c++-all, but otherwise untested).

[Bug tree-optimization/80511] [8 Regression] gcc.dg/Wstrict-overflow-18.c gcc.dg/Wstrict-overflow-7.c gcc.dg/pragma-diag-3.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/84729] [6/7/8 Regression] internal compiler error: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/84650] [8 Regression] [graphite] ICE: Segmentation fault (in create_new_iv)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/84610] [6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/84552] [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #8 from Richard Biener  ---
Raising priority.  A fix can be either in GCC or in gdb (we can just document a
new gdb requirement).

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #16 from Richard Biener  ---
I still say simply walk to the next VDEF...

[Bug testsuite/84456] [8 regression] gcc.dg/guality/pr49888.c fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|debug   |testsuite

--- Comment #3 from Richard Biener  ---
So it's a testsuite issue?  Can somebody with a recent assembler verify with
-gno-whatever?  Maybe we need a dg-require-effective-target locview?

[Bug rtl-optimization/84345] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/84251] [8 Regression] Performance regression in gcc 8 when comparing floating point numbers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #6 from Richard Biener  ---
So we changed wrong-code to missed-optimization.  Sounds reasonable enough to
not make this P1.

[Bug target/84719] gcc's __builtin_memcpy performance with certain number of bytes is terrible compared to clang's

[manuel.lauss at googlemail dot com]

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

Manuel Lauss  changed:

   What|Removed |Added

 CC||manuel.lauss at googlemail dot 
com

--- Comment #12 from Manuel Lauss  ---
clang-7 achieves an impressive level of ipc (amd zen):

 Performance counter stats for './memtime-clangO2' (10 runs):

358,260795  task-clock:u (msec)   #0,999 CPUs utilized 
  ( +-  1,43% )
 0  context-switches:u#0,000 K/sec  
 0  cpu-migrations:u  #0,000 K/sec  
   244.191  page-faults:u #0,682 M/sec 
  ( +-  0,00% )
 1.253.573.425  cycles:u  #3,499 GHz   
  ( +-  1,50% )
   149.207.036  stalled-cycles-frontend:u #   11,90% frontend cycles
idle ( +-  2,04% )
   333.373.414  stalled-cycles-backend:u  #   26,59% backend cycles
idle  ( +-  0,00% )
 4.333.767.562  instructions:u#3,46  insn per cycle 
  #0,08  stalled cycles per
insn  ( +-  0,00% )
   333.621.304  branches:u#  931,225 M/sec 
  ( +-  0,00% )
   248.011  branch-misses:u   #0,07% of all branches   
  ( +-  0,06% )

   0,358644336 seconds time elapsed
 ( +-  1,43% )


compared to gcc-8 as of today:
 Performance counter stats for './memtime-gcc8O2' (10 runs):

   2087,357431  task-clock:u (msec)   #1,000 CPUs utilized 
  ( +-  0,19% )
 0  context-switches:u#0,000 K/sec  
 0  cpu-migrations:u  #0,000 K/sec  
   244.191  page-faults:u #0,117 M/sec 
  ( +-  0,00% )
 8.273.911.027  cycles:u  #3,964 GHz   
  ( +-  0,00% )
 3.691.281.142  stalled-cycles-frontend:u #   44,61% frontend cycles
idle ( +-  0,02% )
   333.373.414  stalled-cycles-backend:u  #4,03% backend cycles
idle  ( +-  0,00% )
 3.667.101.412  instructions:u#0,44  insn per cycle 
  #1,01  stalled cycles per
insn  ( +-  0,00% )
   333.621.824  branches:u#  159,830 M/sec 
  ( +-  0,00% )
   248.423  branch-misses:u   #0,07% of all branches   
  ( +-  0,01% )

   2,088370519 seconds time elapsed
 ( +-  0,19% )