[Bug fortran/83458] F2008: inquire fails on units opened with newunit=

[daanvanvugt at gmail dot com]

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

--- Comment #3 from Daan van Vugt  ---
Ahh, okay, thanks!

On Fri, Dec 22, 2017 at 5:58 AM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83458
>
> Jerry DeLisle  changed:
>
>What|Removed |Added
> 
> 
>  Status|ASSIGNED|RESOLVED
>  Resolution|--- |INVALID
>
> --- Comment #2 from Jerry DeLisle  ---
> You have your inquire arguments wrong
>
> Try:
>
>  inquire(unit=un, opened=openedq, name=name_of_file)
>
> or
>
>  inquire(number=un, opened=openedq, file="/dev/urandom")
>
> Marking as invalid
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug tree-optimization/83544] Missed optimization opportunity for constant folding

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
In one case we optimize super early to
  int t = 1 / (int) x <= 0 ? 1 / 0 : 1;
which prevents the VRP optimization from the other case. We almost recover in
isolate-paths, except that Jeff insisted on using __builtin_trap() instead of
__builtin_unreachable(), so we don't. We could still simplify
  _2 = 1 / x.1_1;
  if (_2 != 1)
a bit to avoid actually performing the division, I think that's already tracked
in one of your earlier PRs.

[Bug debug/83547] New: [8 Regression] (statement-frontiers) error: void value not ignored as it ought to be

[trippels at gcc dot gnu.org]

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

Bug ID: 83547
   Summary: [8 Regression] (statement-frontiers) error: void value
not ignored as it ought to be
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 linux % cat lpar.i
void foo(void) {
  if (({ 0; }))
;
}

trippels@gcc2-power8 linux % gcc -O2 -c lpar.i
trippels@gcc2-power8 linux % gcc -gno-statement-frontiers -O2 -g -c lpar.i
trippels@gcc2-power8 linux % gcc -O2 -g -c lpar.i
lpar.i: In function ‘foo’:
lpar.i:2:7: error: void value not ignored as it ought to be
   if (({ 0; }))
   ^

[Bug debug/83547] [8 Regression] (statement-frontiers) error: void value not ignored as it ought to be

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug target/83546] New: -march=silvermont doesn't enable rdrnd by default despite what docs say

[craig.topper at gmail dot com]

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

Bug ID: 83546
   Summary: -march=silvermont doesn't enable rdrnd by default
despite what docs say
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

The documentation https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html says
'silvermont' enables rdrnd, but that doesn't appear to happen. 

I think it may have worked in r205275 when 'slm' listed all of its features
separately.

But I think it was then broken in r206178 when PTA_SILVERMONT was introduced
and defined like this

  #define PTA_SILVERMONT \
(PTA_WESTMERE | PTA_MOVBE)


PTA_WESTMERE doesn't and shouldn't include RDRND.

[Bug fortran/83458] F2008: inquire fails on units opened with newunit=

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jerry DeLisle  ---
You have your inquire arguments wrong

Try:

 inquire(unit=un, opened=openedq, name=name_of_file)

or

 inquire(number=un, opened=openedq, file="/dev/urandom")

Marking as invalid

[Bug fortran/83458] F2008: inquire fails on units opened with newunit=

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-12-22
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Confirmed and I will take this one.

[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83501

--- Comment #2 from Martin Sebor  ---
See also pr83501 for a related optimization opportunity that strlen could take
advantage of.

[Bug tree-optimization/83544] New: Missed optimization opportunity for constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 83544
   Summary: Missed optimization opportunity for constant folding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

We compiled two programs (A1.c, A2.c) by GCC-8.0.0 with -O3 option.
We expect the resulting assembly codes would be the same, or at least
A1.c would result in simpler code.  However, the result was the opposite.


+-+-+
|A1.c |  A2.c   |
+-+-+
|int main (void)  |int main (void)  |
|{|{|
|  volatile int x = 1;|  volatile int x = 1;|
| |  int a = 1; |
| | |
|  int t = 1 / ( 0 < ( 1/x ) );   |  int t = a / ( 0 < ( 1/x ) );   |
|  if (t != 1) __builtin_abort(); |  if (t != 1) __builtin_abort(); |
|  return 0;  |  return 0;  |
|}|}|
+-+-+

+++
|A1.s (gcc-8.0.0 A1.c -O3 -S)|A2.s (gcc-8.0.0 A2.c -O3 -S)|
+++
|main:   |main:   |
|.LFB0:  |.LFB0:  |
|  .cfi_startproc|  .cfi_startproc|
|  movl  $1, %eax||
|  movl  $1, -4(%rsp)|  movl  $1, -4(%rsp)|
|  movl  -4(%rsp), %ecx  |  movl  -4(%rsp), %eax  |
|  cltd  ||
|  idivl %ecx||
|  cmpl  $1, %eax||
|  je.L2 ||
|  ud2   ||
|  .p2align 4,,10||
|  .p2align 3||
|.L2:||
|  xorl  %eax, %eax  |  xorl  %eax, %eax  |
|  ret   |  ret   |
|  .cfi_endproc  |  .cfi_endproc  |
|.LFE0:  |.LFE0:  |
|  .size  main, .-main   |   .size  main, .-main  |
+++

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

[Bug debug/83527] [8 Regression] Another statement-frontiers -fcompare-debug failure

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Fixed

[Bug debug/83419] [8 Regression] -fcompare-debug failure (length)

[aoliva at gcc dot gnu.org]

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

--- Comment #9 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Dec 22 02:07:31 2017
New Revision: 255966

URL: https://gcc.gnu.org/viewcvs?rev=255966=gcc=rev
Log:
[SFN] sync up debug-only stmt list's side effects with empty stmts too

for  gcc/c-family/ChangeLog

PR debug/83527
PR debug/83419
* c-semantics.c (only_debug_stmts_after_p): New.
(pop_stmt_list): Clear side effects in debug-only stmt list.
Check for single nondebug stmt followed by debug stmts only.

for  gcc/testsuite/ChangeLog

PR debug/83527
PR debug/83419
* gcc.dg/pr83527.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr83527.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/83527] [8 Regression] Another statement-frontiers -fcompare-debug failure

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Dec 22 02:07:31 2017
New Revision: 255966

URL: https://gcc.gnu.org/viewcvs?rev=255966=gcc=rev
Log:
[SFN] sync up debug-only stmt list's side effects with empty stmts too

for  gcc/c-family/ChangeLog

PR debug/83527
PR debug/83419
* c-semantics.c (only_debug_stmts_after_p): New.
(pop_stmt_list): Clear side effects in debug-only stmt list.
Check for single nondebug stmt followed by debug stmts only.

for  gcc/testsuite/ChangeLog

PR debug/83527
PR debug/83419
* gcc.dg/pr83527.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr83527.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Martin Sebor  ---
On powerpc64le the root cause of the failure to optimize the code is in the
strlen pass not handling the struct initialization

  struct S s = { "12345" };

represented as struct assignment (s = *.LC0 below).  The pass only handles
assignment to individual struct members (which is how the initialization is
represented on x86_64).

f ()
{
  struct S s;
  long unsigned int _1;

   [local count: 1073741825]:
  s = *.LC0;
  ...

To enable the optimization in this case the pass needs to be extended to handle
the assignment from a constant VAR_DECL with an initial value (a CONSTRUCTOR).

[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Dec 22 00:07:39 2017
New Revision: 255962

URL: https://gcc.gnu.org/viewcvs?rev=255962=gcc=rev
Log:
PR testsuite/83462 - c-c++-common/Warray-bounds-3.c fails

gcc/testsuite/ChangeLog

* c-c++-common/Warray-bounds-3.c: Adjust dg-warning grep pattern.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-3.c

[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target|arm-none-eabi   |arm-none-eabi,
   ||powerpc64*-linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-22
 Depends on||83543
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed with an arm-none-eabi cross-compiler.  The arm-none-eabi C++ results
show many more failures than the C results for the same test.

Today's test results show a FAIL and an XFAIL in both powerpc64 and
powerpc64le:

https://gcc.gnu.org/ml/gcc-testresults/2017-12/msg01429.html
https://gcc.gnu.org/ml/gcc-testresults/2017-12/msg01417.html

XPASS: c-c++-common/Warray-bounds-3.c  -Wc++-compat  strcpy (test for warnings,
line 362)
FAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat   (test for warnings, line
67)

I see slightly different results with the powerpc64le cross-compiler.  At least
one problem is in the test itself not being prepared for GCC formatting char[5]
as 'char[5]' in C but as 'char [5]' in C++.  It would be nice to fix this (in
GCC) and have both print arrays the same way.  Until then, let me fix the test.
 That will turn that FAIL into an XFAIL.

The Warray-bounds-4.c failure on line 67 is due to bug 83543.

I'm traveling until next weekend but I'll look into it after I get back.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543
[Bug 83543] strlen of a local array member not optimized on some targets

[Bug tree-optimization/83543] New: strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

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

Bug ID: 83543
   Summary: strlen of a local array member not optimized on some
targets
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Bug 83462 reports (among others) a failure in the new
c-c++-common/Warray-bounds-4.c test on powerpc64le.  The failure is due to a
strlen optimization that's for some reason not working on this target (and on
some others, including arm-none-eabi) but that works fine on x86_64-linux.  The
test case below shows the difference in cross-compiler output between these
three architectures.

$ (set -x && cat z.c && for arch in '' arm-none-eabi powerpc64le-linux; do
/ssd/build/$arch/gcc-git/gcc/xgcc -B /ssd/build/$arch/gcc-git/gcc -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout z.c; done)
+ cat z.c
struct S { char a[7]; };

void f (void)
{
  struct S s = { "12345" };
  if (__builtin_strlen (s.a) != 5)
__builtin_abort ();
}
+ for arch in ''\'''\''' arm-none-eabi powerpc64le-linux
+ /ssd/build//gcc-git/gcc/xgcc -B /ssd/build//gcc-git/gcc -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout z.c

;; Function f (f, funcdef_no=0, decl_uid=1894, cgraph_uid=0, symbol_order=0)

f ()
{
   [local count: 1073741825]:
  return;

}


+ for arch in ''\'''\''' arm-none-eabi powerpc64le-linux
+ /ssd/build/arm-none-eabi/gcc-git/gcc/xgcc -B
/ssd/build/arm-none-eabi/gcc-git/gcc -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout z.c

;; Function f (f, funcdef_no=0, decl_uid=4155, cgraph_uid=0, symbol_order=0)

f ()
{
  struct S s;
  unsigned int _1;

   [local count: 1073741825]:
  s = *.LC0;
  _1 = __builtin_strlen ();
  if (_1 != 5)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  s ={v} {CLOBBER};
  return;

}


+ for arch in ''\'''\''' arm-none-eabi powerpc64le-linux
+ /ssd/build/powerpc64le-linux/gcc-git/gcc/xgcc -B
/ssd/build/powerpc64le-linux/gcc-git/gcc -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout z.c

;; Function f (f, funcdef_no=0, decl_uid=2784, cgraph_uid=0, symbol_order=0)

f ()
{
  struct S s;
  long unsigned int _1;

   [local count: 1073741825]:
  s = *.LC0;
  _1 = __builtin_strlen ();
  if (_1 != 5)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  s ={v} {CLOBBER};
  return;

}

[Bug c++/83542] template deduction failure when using pack in both deduced and non-deduced contexts

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
This slightly different example:

template 
struct list { };

template 
void foo(list, list, void(*)(T..., U)) 
{ }


void f(int, int) { } 

int main()
{
foo(list{}, list{}, );
}


fails with a different error:

foo.cxx: In function ‘int main()’:
foo.cxx:13:37: error: no matching function for call to ‘foo(list,
list, void (*)(int, int))’
 foo(list{}, list{}, );
 ^
foo.cxx:5:6: note: candidate: template void foo(list, list, void (*)(T ..., U))
 void foo(list, list, void(*)(T..., U))
  ^~~
foo.cxx:5:6: note:   template argument deduction/substitution failed:
foo.cxx:13:37: note:   candidate expects 1 argument, 2 provided
 foo(list{}, list{}, );
 ^

[Bug c++/83542] New: template deduction failure when using pack in both deduced and non-deduced contexts

[barry.revzin at gmail dot com]

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

Bug ID: 83542
   Summary: template deduction failure when using pack in both
deduced and non-deduced contexts
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This example fails to compile:

template 
struct list { };

template 
void foo(list, list, void(*)(T..., U...))
{ }


void f(int, int ) { } 

int main()
{
foo(list{}, list{}, );
}

on gcc 7.2. with:

foo.cxx: In function ‘int main()’:
foo.cxx:13:37: error: no matching function for call to ‘foo(list,
list, void (*)(int, int))’
 foo(list{}, list{}, );
 ^
foo.cxx:5:6: note: candidate: template void
foo(list, list, void (*)(T ..., U ...))
 void foo(list, list, void(*)(T..., U...))
  ^~~
foo.cxx:5:6: note:   template argument deduction/substitution failed:
foo.cxx:13:37: note:   inconsistent parameter pack deduction with ‘’ and ‘’
 foo(list{}, list{}, );
 ^

But deduction should succeed - we can deduce T... and U... from the list<>
arguments. Additionally, the error message isn't very helpful. What do the ‘’s
refer to?

[Bug c/83448] [7 Regression] ice in get_source_location_for_substring, at input.c:1507

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ice in |[7 Regression] ice in
   |get_source_location_for_sub |get_source_location_for_sub
   |string, at input.c:1507 |string, at input.c:1507

--- Comment #12 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/83487] [8 Regression] ICE in expand_call, at calls.c:4098

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/83487] [8 Regression] ICE in expand_call, at calls.c:4098

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 21 23:10:45 2017
New Revision: 255961

URL: https://gcc.gnu.org/viewcvs?rev=255961=gcc=rev
Log:
PR middle-end/83487
* config/i386/i386.c (ix86_function_arg_boundary): Return
PARM_BOUNDARY for TYPE_EMPTY_P types.

* gcc.c-torture/compile/pr83487.c: New test.
* gcc.dg/compat/pr83487-1.h: New file.
* gcc.dg/compat/pr83487-1_main.c: New test.
* gcc.dg/compat/pr83487-1_x.c: New file.
* gcc.dg/compat/pr83487-1_y.c: New file.
* gcc.dg/compat/pr83487-2_main.c: New test.
* gcc.dg/compat/pr83487-2_x.c: New file.
* gcc.dg/compat/pr83487-2_y.c: New file.
* g++.dg/abi/pr83487.C: New test.
* g++.dg/compat/abi/pr83487-1_main.C: New test.
* g++.dg/compat/abi/pr83487-1_x.C: New file.
* g++.dg/compat/abi/pr83487-1_y.C: New file.
* g++.dg/compat/abi/pr83487-2_main.C: New test.
* g++.dg/compat/abi/pr83487-2_x.C: New file.
* g++.dg/compat/abi/pr83487-2_y.C: New file.

Added:
trunk/gcc/testsuite/g++.dg/abi/pr83487.C
trunk/gcc/testsuite/g++.dg/compat/abi/pr83487-1_main.C
trunk/gcc/testsuite/g++.dg/compat/abi/pr83487-1_x.C
trunk/gcc/testsuite/g++.dg/compat/abi/pr83487-1_y.C
trunk/gcc/testsuite/g++.dg/compat/abi/pr83487-2_main.C
trunk/gcc/testsuite/g++.dg/compat/abi/pr83487-2_x.C
trunk/gcc/testsuite/g++.dg/compat/abi/pr83487-2_y.C
trunk/gcc/testsuite/gcc.c-torture/compile/pr83487.c
trunk/gcc/testsuite/gcc.dg/compat/pr83487-1.h
trunk/gcc/testsuite/gcc.dg/compat/pr83487-1_main.c
trunk/gcc/testsuite/gcc.dg/compat/pr83487-1_x.c
trunk/gcc/testsuite/gcc.dg/compat/pr83487-1_y.c
trunk/gcc/testsuite/gcc.dg/compat/pr83487-2_main.c
trunk/gcc/testsuite/gcc.dg/compat/pr83487-2_x.c
trunk/gcc/testsuite/gcc.dg/compat/pr83487-2_y.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/83448] [7/8 Regression] ice in get_source_location_for_substring, at input.c:1507

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 21 23:09:14 2017
New Revision: 255960

URL: https://gcc.gnu.org/viewcvs?rev=255960=gcc=rev
Log:
PR c/83448
* gimple-ssa-sprintf.c (maybe_warn): Don't call set_caret_index
if navail is >= dir.len.

* gcc.c-torture/compile/pr83448.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-warn-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr83448.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-warn-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83541] Missed optimization with int overflow

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
int test(void)
{
  int x = __INT_MAX__;
  return x+1;
}

CCP also turns this into INT_MIN, again it could be bolder.

[Bug tree-optimization/83541] Missed optimization with int overflow

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Yes, it is a known issue, (E)VRP is too conservative.

pushing new range for x_2(D): [2147483647, +INF]  EQUIVALENCES: { x_2(D) } (1
elements)
Visiting stmt _4 = x_2(D) + 1;

Visiting statement:
_4 = x_2(D) + 1;
Match-and-simplified x_2(D) + 1 to -2147483648

Nope, there is an overflow, it should give __builtin_unreachable() instead of a
constant value, or to be more conservative produce an empty range whose meet
with [42, 42] would be just [42, 42].

[Bug debug/83527] [8 Regression] Another statement-frontiers -fcompare-debug failure

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01462.html

[Bug tree-optimization/83541] New: Missed optimization with int overflow

[zamazan4ik at tut dot by]

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

Bug ID: 83541
   Summary: Missed optimization with int overflow
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

gcc(trunk) with '-O3 -std=c++17 -ffast-math' for this:

#include 

int test(int x)
{
if(x == std::numeric_limits::max())
{
return x+1;
}
return 42;
}

generates this:

test(int):
  cmp edi, 2147483647
  mov edx, -2147483648
  mov eax, 42
  cmove eax, edx
  ret


But branch with condition is UB, so you can just delete it and simply return
42.

[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #6 from Mark Wielaard  ---
(In reply to Aldy Hernandez from comment #4)
> I am attaching a simplified preprocessed file that exhibits the problem. 
> Perhaps someone with more debug-fu can comment here.
> 
> [tl;dr: Shouldn't local variables in a cloned variable have their own
> location lists?].

In this case it seems the answer is yes.
The location code range(s) of the abstract origin don't make sense in the
cloned code since it doesn't cover the new cloned code range.

Also, since it seems we know the cloned variable is always 1 maybe it could
just simply have a DW_AT_const_value 1 instead of a DW_AT_location?

[Bug ada/83535] [8 regression] indirect atomic access with wrong size

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug ada/83535] [8 regression] indirect atomic access with wrong size

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Dec 21 22:02:45 2017
New Revision: 255958

URL: https://gcc.gnu.org/viewcvs?rev=255958=gcc=rev
Log:
PR ada/83535
* gcc-interface/decl.c (gnat_to_gnu_entity) : Always take
into account the Esize if it is known.

Added:
trunk/gcc/testsuite/gnat.dg/atomic9.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/82027] [7/8 Regression] wrong code with -O3 -flto

[jamborm at gcc dot gnu.org]

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

--- Comment #12 from Martin Jambor  ---
Thanks,  I have submitted the patch to the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01457.html

[Bug fortran/83540] New: [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize

[anlauf at gmx dot de]

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

Bug ID: 83540
   Summary: [8 Regression] Invalid code with MATMUL,
-fno-realloc-lhs -ffrontend-optimize
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de
  Target Milestone: ---

The following code crashes at runtime:

! Bug with "-fno-realloc-lhs -ffrontend-optimize"
program gfcbug142
  implicit none
  real, allocatable :: b(:,:)
  integer :: n = 5
  allocate (b(n,n))
  call random_number (b)
  print *, shape (matmul (b, transpose (b)))
end program gfcbug142

% gfc-8 -g -fno-realloc-lhs -ffrontend-optimize gfcbug142a.f90 && ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xe3ff in ???
#1  0x8048b77 in gfcbug142
at /work/DWD/git/dace_code/gfcbug142a.f90:8
#2  0x8048dd2 in main
at /work/DWD/git/dace_code/gfcbug142a.f90:9
Segmentation fault (core dumped)

Adding -fcheck=all:

Fortran runtime error: Incorrect extent in return array in MATMUL intrinsic for
dimension 1: is 0, should be 5

Error termination. Backtrace:
#0  0x8048a7b in gfcbug142
at /work/DWD/git/dace_code/gfcbug142a.f90:8
#1  0x804950d in main
at /work/DWD/git/dace_code/gfcbug142a.f90:9

[Bug target/83536] One 'false' too much in r255699 for mingw target (in config/i386/i386.c)

[mateuszb at poczta dot onet.pl]

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

--- Comment #2 from mateuszb at poczta dot onet.pl ---
Yes, I agree.

The 80-chars width limit was also significant in this case -- instead of
writing code you must fight with too long lines. I think that there is the time
to change this limit to 130 chars (for example).

[Bug c/83539] New: [8 regression] several test case failures starting with r255947

[seurer at gcc dot gnu.org]

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

Bug ID: 83539
   Summary: [8 regression] several test case failures starting
with r255947
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

The failing tests all have excess errors but the errors vary

> FAIL: gcc.c-torture/compile/20030530-3.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -O (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -O3 (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g1 (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g1 -O (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g1 -O3 (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g3 (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g3 -O (test for excess errors)
> FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g3 -O3 (test for excess errors)
> FAIL: gcc.dg/debug/20030605-1.c -gdwarf-2 -O (test for excess errors)
> FAIL: gcc.dg/debug/20030605-1.c -gdwarf-2 -O3 (test for excess errors)
> FAIL: gcc.dg/debug/20030605-1.c -gdwarf-2 -g3 -O (test for excess errors)
> FAIL: gcc.dg/debug/20030605-1.c -gdwarf-2 -g3 -O3 (test for excess errors)
> FAIL: gcc.dg/noncompile/971104-1.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/torture/pr51071.c   -O3 -g  (test for excess errors)

/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20030530-3.c: In
function 'redeclaration_error_message':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20030530-3.c:14:8:
error: void value not ignored as it ought to be
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20030530-3.c: In
function 'redeclaration_error_message':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20030530-3.c:14:8:
error: void value not ignored as it ought to be

FAIL: gcc.c-torture/compile/20030530-3.c   -O3 -g  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20030530-3.c:14:8:
error: void value not ignored as it ought to be


/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20020224-1.c: In function
'f4':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20020224-1.c:52:52:
error: void value not ignored as it ought to be
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20020224-1.c: In function
'f4':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20020224-1.c:52:52:
error: void value not ignored as it ought to be

FAIL: gcc.dg/debug/20020224-1.c -gdwarf-2 -g1 (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20020224-1.c:52:52:
error: void value not ignored as it ought to be


/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20030605-1.c: In function
'foo':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20030605-1.c:6:8: error:
size of array 'buf' has non-integer type
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20030605-1.c: In function
'foo':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20030605-1.c:6:8: error:
size of array 'buf' has non-integer type

FAIL: gcc.dg/debug/20030605-1.c -gdwarf-2 -O (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/debug/20030605-1.c:6:8: error:
size of array 'buf' has non-integer type

[Bug tree-optimization/83438] [8 Regression] 435.gromacs miscompares

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
My bisections keep landing on:
commit bb173647d8221f86812f4e98942960b894e9e972 (HEAD, refs/bisect/bad)
Author: hubicka 
Date:   Thu Nov 23 15:56:28 2017 +

* ipa-fnsummary.c (record_modified_bb_info): Use sreal
frequencies. Fix estimation of aggregate parameters.

* gcc.dg/ipa/inline-1.c: Update template.


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


But there is something really wonky about this benchmark.  There are times when
I fully expect it to pass and it fails and vice-versa.  I'm really starting to
wonder if there's an uninit read in there or something similar.

[Bug middle-end/81897] [6/7/8 Regression] spurious -Wmaybe-uninitialized warning

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
This really looks like something tree-ssa-uninit.c ought to be handling too.

[ Just to be clear we should fix both tree-ssa-uninit.c the cfgcleanup. ]


We have a PHI with a default definition on the RHS:


   [local count: 182536114]:
  # dst_32 = PHI 
  __warned = 1;
  if (fibmatch_6 != 0)
goto ; [0.00%]
  else
goto ; [100.00%]


So if you dump the CFG and analyze the path you'll find that the only way to
traverse the edge 18->4 has a series of predicates, *all* of which must be true
to ever reach 18->4.  Yet the predicate analysis bits only analyze the last
predicate in the path:

[WORKLIST]: add to initial list: dst_32 = PHI 
[CHECK]: examining phi: dst_32 = PHI 
[BEFORE SIMPLICATION -- [DEF]:

is guarded by :

_19 == 0


[BEFORE NORMALIZATION --[DEF]:

is guarded by :

_19 == 0


[AFTER NORMALIZATION -- [DEF]:

is guarded by :

_19 == 0

I think that's because our choice for where to start the predicate analysis for
the def of a PHI arg is terrible.  We look at the domiantor of e->src:

  /* Build the control dependency chain for uninit operand `i'...  */
  uninit_preds = vNULL;
  if (!compute_control_dep_chain (find_dom (e->src),
  e->src, dep_chains, _chains,
  _chain, _calls))

I'm not sure why it's done that way.  THere's no reason we can't go all the way
back to the entry block here (note there's some lameness in
compute_control_dep_chain that needs to be worked around -- you can't just slam
ENTRY_BLOCK_PTR in there).

But fixing that still doesn't resolve the problem, but gives us a shot at
actually seeing a full predicate chain -- which would include the predicate
from bb2:

  [local count: 1073741825]:
  fibmatch_6 = f ();
  if (fibmatch_6 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]

We care about the 2-->7 edge here.  ie, the *only* way to traverse the 18->4
edge is to first have traversed the 2->7 edge which occurs when fibmatch_6 !=
0.

That's the def side.  Now looking at the use side.
  [local count: 182536114]:
  # dst_32 = PHI 
  __warned = 1;
  if (fibmatch_6 != 0)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 182536114]:
  goto ; [100.00%]

   [local count: 0]:

   [local count: 536870912]:

   [local count: 1073741825]:
  # dst_2 = PHI 
  return dst_2;


So given that the only way we ever traverse 18->4 is when fibmatch_6 != 0 which
implies that we always traverse 4->13->5->6 and on that path we never use
dst_32.

[Bug target/83467] [7/8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1476: unable to find a register to spill with -flive-range-shrinkage -m8bit-idiv

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed for 7.3+.

[Bug target/83467] [7/8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1476: unable to find a register to spill with -flive-range-shrinkage -m8bit-idiv

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Dec 21 20:48:34 2017
New Revision: 255956

URL: https://gcc.gnu.org/viewcvs?rev=255956=gcc=rev
Log:
PR target/83467
* config/i386/i386.md (*ashl3_mask): Add operand
constraints to operand 2.
(*3_mask): Ditto.
(*3_mask): Ditto.

testsuite/ChangeLog:

PR target/83467
* gcc.target/i386/pr83467-1.c: New test.
* gcc.target/i386/pr83467-2.c: Ditto.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr83467-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr83467-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/57076] @ in the src directory name causes failure while building of gcc.info

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #3)
> Maybe the best thing would be reject this during configure.
>

Since I can't think of anything better, agreed.

[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Created attachment 42950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42950=edit
hacked up preprocessed file showing problem with only -O3 -g

[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez  ---
I am attaching a simplified preprocessed file that exhibits the problem. 
Perhaps someone with more debug-fu can comment here.

[tl;dr: Shouldn't local variables in a cloned variable have their own location
lists?].

The following is being cloned into guality_main.constprop(), which in turn is
called from main():

int
guality_main(int argc, char *argv[])
{
  int boring = -1;
boring = -f();
  guality_check ("boring", boring, 0);
  return boring;
}

[FWIW, guality_main and guality_main.constprop have exactly the same IL, albeit
with different #DEBUG statements.  I don't know why we even clone it.]

$ ./a.out
FAIL: guality/guality.h: boring is -1, not 1
FAIL: guality/guality.h: 0 PASS, 1 FAIL, 0 UNRESOLVED

Since guality_main.constprop() is the function being called, let's look for
"boring" in it:

;; guality_main.constprop()
 <1><9f0>: Abbrev Number: 42 (DW_TAG_subprogram)
<9f1>   DW_AT_abstract_origin: <0x474>
<9f5>   DW_AT_low_pc  : 0x400e22
<9fd>   DW_AT_high_pc : 0x1f
   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
   DW_AT_GNU_all_call_sites: 1
   DW_AT_sibling : <0xa4a>
 <2>: Abbrev Number: 46 (DW_TAG_variable)
   DW_AT_abstract_origin: <0x9c1>

According to this, "boring" comes from 0x9c1 which is defined in
guality_main(), the original function:

;; guality_main()
 <1><994>: Abbrev Number: 42 (DW_TAG_subprogram)
<995>   DW_AT_abstract_origin: <0x474>
<999>   DW_AT_low_pc  : 0x400e03
<9a1>   DW_AT_high_pc : 0x1f
<9a9>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<9ab>   DW_AT_GNU_all_call_sites: 1
<9ab>   DW_AT_sibling : <0x9f0>
...
 <2><9c1>: Abbrev Number: 45 (DW_TAG_variable)
<9c2>   DW_AT_abstract_origin: <0x49d>  <-- points to DW_TAG_var for
"boring"
<9c6>   DW_AT_location: 0x542 (location list)

The location list for this 0x542 has a literal of 1 as expected:

0542 00400e03 00400e18 (DW_OP_lit1; DW_OP_stack_value)

However, my question is, shouldn't "boring" in guality_main.constprop (0xa0b)
have a DW_AT_location of itself?  Because even if if the location of boring in
guality_main.constprop (0xa0b) comes through the abstract origin that
ultimately leeds to...

0542 00400e03 00400e18 (DW_OP_lit1; DW_OP_stack_value)

This is the wrong address. 0x400e03 through 0x400e18 is in guality_main(), not
in guality_main.constprop() which is the function being called:

00400e03 :
  400e03:   48 83 ec 08 sub$0x8,%rsp
  400e07:   31 d2   xor%edx,%edx
  400e09:   be 01 00 00 00  mov$0x1,%esi
  400e0e:   bf 08 12 40 00  mov$0x401208,%edi
  400e13:   e8 b3 fd ff ff  callq  400bcb 
  400e18:   b8 01 00 00 00  mov$0x1,%eax
  400e1d:   48 83 c4 08 add$0x8,%rsp
  400e21:   c3  retq   

Hints, tips, and/or solutions, would be greatly appreciated :).

[Bug ada/83535] [8 regression] indirect atomic access with wrong size

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Fixing.

[Bug ada/83535] [8 regression] indirect atomic access with wrong size

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|WAITING |NEW
   Target Milestone|--- |8.0
Summary|Doesn’t respect Size for an |[8 regression] indirect
   |object  |atomic access with wrong
   ||size

--- Comment #2 from Eric Botcazou  ---
I can reproduce on x86-64 too.

[Bug c/46921] Dropped side effect with combination of statement expression and struct initializer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-12-21
 CC|dave.pagan at oracle dot com   |
   Assignee|unassigned at gcc dot gnu.org  |dave.pagan at oracle 
dot com
 Ever confirmed|0   |1

--- Comment #2 from Paolo Carlini  ---
Dave is on it.

[Bug c/30552] gcc crashes when compiling examples with GNU statement expressions in VLAs (also involved: nested functions declared K)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|dave.pagan at oracle dot com,  |paolo.carlini at oracle 
dot com
   |gcc-bugs at gcc dot gnu.org|
   Assignee|unassigned at gcc dot gnu.org  |dave.pagan at oracle 
dot com

--- Comment #7 from Paolo Carlini  ---
Dave on it, then.

[Bug rtl-optimization/80747] [6/7 Regression] gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression]
   |gcc.dg/tree-ssa/tailrecursi |gcc.dg/tree-ssa/tailrecursi
   |on-4.c fails with ICE when  |on-4.c fails with ICE when
   |compiled with options   |compiled with options
   |"-fprofile-use  |"-fprofile-use
   |-freorder-blocks-and-partit |-freorder-blocks-and-partit
   |ion"|ion"

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/83521] [6/7 Regression] ICE: verify_gimple failed (error: invalid operand in unary operation)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: invalid operand in  |(error: invalid operand in
   |unary operation)|unary operation)

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/83523] [6/7 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: statement marked|(error: statement marked
   |for throw, but doesn't) |for throw, but doesn't)

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/80747] [6/7/8 Regression] gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 21 19:28:10 2017
New Revision: 255954

URL: https://gcc.gnu.org/viewcvs?rev=255954=gcc=rev
Log:
PR rtl-optimization/80747
PR rtl-optimization/83512
* cfgrtl.c (force_nonfallthru_and_redirect): When splitting
succ edge from ENTRY, copy partition from e->dest to the newly
created bb.
* bb-reorder.c (reorder_basic_blocks_simple): If last_tail is
ENTRY, use BB_PARTITION of its successor block as current_partition.
Don't copy partition when splitting succ edge from ENTRY.

* gcc.dg/pr80747.c: New test.
* gcc.dg/pr83512.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80747.c
trunk/gcc/testsuite/gcc.dg/pr83512.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/cfgrtl.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/83512] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 21 19:28:10 2017
New Revision: 255954

URL: https://gcc.gnu.org/viewcvs?rev=255954=gcc=rev
Log:
PR rtl-optimization/80747
PR rtl-optimization/83512
* cfgrtl.c (force_nonfallthru_and_redirect): When splitting
succ edge from ENTRY, copy partition from e->dest to the newly
created bb.
* bb-reorder.c (reorder_basic_blocks_simple): If last_tail is
ENTRY, use BB_PARTITION of its successor block as current_partition.
Don't copy partition when splitting succ edge from ENTRY.

* gcc.dg/pr80747.c: New test.
* gcc.dg/pr83512.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80747.c
trunk/gcc/testsuite/gcc.dg/pr83512.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/cfgrtl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83523] [6/7/8 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 21 19:27:21 2017
New Revision: 255953

URL: https://gcc.gnu.org/viewcvs?rev=255953=gcc=rev
Log:
PR tree-optimization/83523
* tree-ssa-math-opts.c (is_widening_mult_p): Return false if
for INTEGER_TYPE TYPE_OVERFLOW_TRAPS.
(convert_mult_to_fma): Likewise.

* g++.dg/tree-ssa/pr83523.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr83523.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug tree-optimization/83521] [6/7/8 Regression] ICE: verify_gimple failed (error: invalid operand in unary operation)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 21 19:26:34 2017
New Revision: 255952

URL: https://gcc.gnu.org/viewcvs?rev=255952=gcc=rev
Log:
PR tree-optimization/83521
* tree-ssa-phiopt.c (factor_out_conditional_conversion): Use
gimple_build_assign without code on result of
fold_build1 (VIEW_CONVERT_EXPR, ...), as it might not create
a VIEW_CONVERT_EXPR.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr83521.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/83406] [8 Regression] GCC8 can't deduce lambda return type

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec 21 19:16:01 2017
New Revision: 255950

URL: https://gcc.gnu.org/viewcvs?rev=255950=gcc=rev
Log:
[PR c++/83406] deducing lambda type

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01432.html
PR c++/83406
* parser.c (cp_parser_lambda_body): Remove obsolete
single-return-statement handling.

PR c++/83406
* g++.dg/cpp0x/lambda/lambda-ice15.C: Adjust error.
* g++.dg/cpp1y/pr83406.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr83406.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice15.C

[Bug c++/83406] [8 Regression] GCC8 can't deduce lambda return type

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed r255950.

[Bug target/83467] [7/8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1476: unable to find a register to spill with -flive-range-shrinkage -m8bit-idiv

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Dec 21 19:00:28 2017
New Revision: 255949

URL: https://gcc.gnu.org/viewcvs?rev=255949=gcc=rev
Log:
PR target/83467
* config/i386/i386.md (*ashl3_mask): Add operand
constraints to operand 2.
(*ashl3_mask_1): Ditto.
(*3_mask): Ditto.
(*3_mask_1): Ditto.
(*3_mask): Ditto.
(*3_mask_1): Ditto.

testsuite/ChangeLog:

PR target/83467
* gcc.target/i386/pr83467-1.c: New test.
* gcc.target/i386/pr83467-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr83467-1.c
trunk/gcc/testsuite/gcc.target/i386/pr83467-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug debug/83527] [8 Regression] Another statement-frontiers -fcompare-debug failure

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Mine

[Bug target/83536] One 'false' too much in r255699 for mingw target (in config/i386/i386.c)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
It's very error-prone to make these kinds of changes.  Absent designated
initializers the problem could be avoided by defining an initialization macro
and using it to initialize the elements.  E.g., something like this:

#define ATTR_SPEC_INIT(name, min_len, max_len, decl_req, type_req, fn_type_req,
affects_type_identity, handler, exclude) \
  { name, min_len, max_len, decl_req, type_req, fn_type_req,
affects_type_identity, handler, exclude }

With more than one such initialization macro new members could also be added
without having to disturb all those that don't need to set it to a non-default
value.  E.g.,

#define ATTR_SPEC_DECL_INIT(name) \
  ATTR_SPEC_INIT (name, 0, 0, true, false, false, false, NULL, NULL }

#define ATTR_SPEC_TYPE_INIT(name) \
  ATTR_SPEC_INIT (name, 0, 0, false, true false, false, NULL, NULL }

etc.

Another alternative is to move the tables into their own files compiled using
the C compiler and make use of designated initializers.

[Bug libstdc++/83538] New: std::match_results C++14 conformance issue: reference != value_type

[andrey.y.guskov at intel dot com]

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

Bug ID: 83538
   Summary: std::match_results C++14 conformance issue: reference
!= value_type&
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

C++14 standard (page 1123, see here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf#1137) says:

namespace std {
template >>
class match_results {
public:
typedef sub_match value_type;
typedef const value_type& const_reference;
typedef value_type& reference;
...

As of now, std::match_results implementation disagrees with the standard in
that it does not consider 'reference' equal to 'value_type&'.
I made a reproducer to prove that:

#include 
template  struct diff { static const bool s = true; };
template  struct diff { static const bool s = false; };
typedef std::match_results >
m;
int main() { return !printf((diff::s)? "FAIL\n" :
"PASS\n"); }

[Bug c/83537] New: missing integer overflow in offsetof not diagnosed

[msebor at gcc dot gnu.org]

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

Bug ID: 83537
   Summary: missing integer overflow in offsetof not diagnosed
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

An offsetof(type, member) expression is supposed to evaluate to an integer
constant with type size_t and a value giving the offset in bytes, to the
structure member.  This is only possible for offsets that fit into size_t. 
Since larger offsets are not representable in size_t such offsetof expressions
cannot satisfy the requirement.  To help detect bugs GCC should diagnose the
overflow (perhaps with -Woverflow).

$ cat z.c && gcc -O -S -Wall -fdump-tree-optimized=/dev/stdout z.c
#include 
#include 

struct S { int i, a[]; };

size_t f (void)
{
  return offsetof (struct S, a[PTRDIFF_MAX]);
}


;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=0, symbol_order=0)

f ()
{
   [local count: 1073741825]:
  return 0;

}

[Bug debug/83419] [8 Regression] -fcompare-debug failure (length)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #8 from Alexandre Oliva  ---
Fixed

[Bug debug/83419] [8 Regression] -fcompare-debug failure (length)

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Dec 21 18:14:06 2017
New Revision: 255947

URL: https://gcc.gnu.org/viewcvs?rev=255947=gcc=rev
Log:
[SFN] propagate single-nondebug-stmt's side effects to enclosing list

Statements without side effects, preceded by debug begin stmt markers,
would become a statement list with side effects, although the stmt on
its own would be extracted from the list and remain not having side
effects.  This causes debug info and possibly codegen differences.
This patch fixes it, identifying the situation in which the stmt would
have been extracted from the stmt list, and propagating the side
effects flag from the stmt to the list.

for  gcc/ChangeLog

PR debug/83419
* c-family/c-semantics.c (pop_stmt_list): Propagate side
effects from single nondebug stmt to container list.

for  gcc/testsuite/ChangeLog

PR debug/83419
* gcc.dg/pr83419.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr83419.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c-semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c/83448] [7/8 Regression] ice in get_source_location_for_substring, at input.c:1507

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug debug/48150] [6/7/8 Regression] gcc.dg/guality/sra-1.c

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #19 from Aldy Hernandez  ---
I can't reproduce this on gcc6, 7 or trunk, with:

GNU gdb (GDB) Fedora 7.12.1-41.fc25

I also can't reproduce on trunk with:

GNU gdb (GDB) Fedora 8.0.1-30.fc26

Is this still an issue?  Was this bug only tied to a particular gdb version?

[Bug ada/83535] Doesn’t respect Size for an object

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-12-21
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Please specify the target, the compilation options, etc.

[Bug c/83448] [7/8 Regression] ice in get_source_location_for_substring, at input.c:1507

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Untested fix:
--- gimple-ssa-sprintf.c.jj82017-12-19 22:05:44.0 +0100
+++ gimple-ssa-sprintf.c2017-12-21 18:04:30.960153926 +0100
@@ -2466,7 +2466,8 @@ maybe_warn (substring_loc , locat
  /* For plain character directives (i.e., the format string itself)
 but not others, point the caret at the first character that's
 past the end of the destination.  */
- dirloc.set_caret_index (dirloc.get_caret_idx () + navail);
+ if (navail < dir.len)
+   dirloc.set_caret_index (dirloc.get_caret_idx () + navail);
}

   if (*dir.beg == '\0')
@@ -2587,14 +2588,16 @@ maybe_warn (substring_loc , locat

   /* The size of the destination region is a range.  */

-  if (target_to_host (*dir.beg) != '%')
+  if (target_to_host (*dir.beg) != '%'
+  && avail_range.min == avail_range.max)
 {
   unsigned HOST_WIDE_INT navail = avail_range.max;

   /* For plain character directives (i.e., the format string itself)
 but not others, point the caret at the first character that's
 past the end of the destination.  */
-  dirloc.set_caret_index (dirloc.get_caret_idx () + navail);
+  if (navail < dir.len)
+   dirloc.set_caret_index (dirloc.get_caret_idx () + navail);
 }

   if (*dir.beg == '\0')

Will try to write some testcases now.

[Bug c/83448] [7/8 Regression] ice in get_source_location_for_substring, at input.c:1507

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Cleaned up testcase for testsuite:
char *a;
int b;

void
foo ()
{
  for (;;)
{
  if (b < 0)
foo ();
  __builtin_snprintf (a, b, "%*s", b, "");
}
}

The check certainly doesn't match the comment, if *dir.beg != '%', that doesn't
mean there were no formatting directives and only if there weren't any %
characters the length of the destination buffer has any correspondence to the
location in the format string (and even then, what about \n, \t, \123 and the
like, does the care handling code handle those?).

So, it makes sense for:
void
foo (char *a)
{
  __builtin_snprintf (a, 5, "abcdef");
}

Here:
pr83448-2.c: In function ‘foo’:
pr83448-2.c:4:35: warning: ‘abcdef’ directive output truncated writing 6 bytes
into a region of size 5 [-Wformat-truncation=]
   __builtin_snprintf (a, 5, "abcdef");
  ~^
is nicer than:
pr83448-2.c: In function ‘foo’:
pr83448-2.c:4:30: warning: ‘abcdef’ directive output truncated writing 6 bytes
into a region of size 5 [-Wformat-truncation=]
   __builtin_snprintf (a, 5, "abcdef");
  ^~
that we'd emit without those hunks discussed here.

So IMHO instead of removing those we should guard them properly.

void
bar (char *a)
{
  __builtin_snprintf (a, 7, "abc\n\123 ef");
}

also puts caret below f, so it seems \n and \123 is handled right.

[Bug c++/83406] [8 Regression] GCC8 can't deduce lambda return type

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[juergen.reuter at desy dot de]

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

--- Comment #8 from Jürgen Reuter  ---
Another thing I observed: one difference between the laptop where the bootstrap
worked and the one where it didn't work (besides the different chipsets i5 vs.
i7) is that on the one where the bootstrap doesn't work, the MAC OS X Security
Integrity Protocol (SIP) is activated, while on the one where the bootstrap
worked it is deactivated. Could it be that during the bootstrap procedure the
SIP causes some trouble in that some of the settings of the gcc to be
bootstrapped are being blocked?

[Bug lto/82027] [7/8 Regression] wrong code with -O3 -flto

[ssbssa at yahoo dot de]

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

--- Comment #11 from Domani Hannes  ---
(In reply to Martin Jambor from comment #10)
> OK, so I did not realize that duplicate_thunk_for_node does not set
> clone_of but former_clone of, which is of course what it must do.  I
> have checked and this is the only place where we currently set
> former_clone_of in WPA, and therefore I am testing the following fix:
> 
> diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
> index a19f8a13dfb..ed3df15b143 100644
> --- a/gcc/lto-cgraph.c
> +++ b/gcc/lto-cgraph.c
> @@ -1958,7 +1958,7 @@ input_offload_tables (bool do_force_output)
>  static int
>  output_cgraph_opt_summary_p (struct cgraph_node *node)
>  {
> -  return (node->clone_of
> +  return ((node->clone_of || node->former_clone_of)
>   && (node->clone.tree_map
>   || node->clone.args_to_skip
>   || node->clone.combined_args_to_skip));

I can confirm that this fixes the crash in my original (non-reduced)
application.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #34 from rguenther at suse dot de  ---
On December 21, 2017 3:30:45 PM GMT+01:00, "ro at CeBiTec dot Uni-Bielefeld.DE"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
>--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE dot Uni-Bielefeld.DE> ---
>I'm having a look at what's still going wrong with Eric's updated
>patch.  On Solaris/SPARC, there are only two failures left:
>
>FAIL: g++.dg/lto/pr51567-1 cp_lto_pr51567-1_0.o-cp_lto_pr51567-1_0.o
>link, 
>-flto -g 
>
>output is:
>ld: warning: relocation error: R_SPARC_UA32: file
>/var/tmp//ccp39Xjadebugobj
>section [8].debug_str: invalid offset symbol '.debug_str (section)':
>offset
>0x
>ld: warning: relocation error: R_SPARC_UA32: file
>/var/tmp//ccp39Xjadebugobj
>section [8].debug_str: invalid offset symbol '.debug_str (section)':
>offset
>0x2258
>
>FAIL: g++.dg/lto/pr53470 cp_lto_pr53470_0.o-cp_lto_pr53470_0.o link, 
>-g -flto 
>
>for both 32 and 64-bit.  Those are only warnings actually, but throw
>off
>DejaGnu which doesn't expect linker output.
>
>Investigating what's happending is unnecessarily hard right now because
>even with -save-temps, a couple of the intermediate files are removed
>and I needed to run the whole compilation under truss to see how they
>are created.
>
>Here's what I found for the g++.dg/lto/pr51567-1 case:
>
>The linker warning happens during the final link step, which is
>(omitting all paths to build directories)
>
>/usr/ccs/bin/ld -V -M  -Y P,/lib:/usr/lib -Qy -o
>g++-dg-lto-pr51567-1-01.exe
> /usr/lib/crt1.o crtp.o /usr/lib/crti.o /usr/lib/values-Xa.o
>/usr/lib/values-xpg6.o  crtbegin.o
> cck5M.wddebugobj
> g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o -lstdc++ -lm
> -lrt -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
> crtend.o
> /usr/lib/crtn.o
>
>cck5M.wddebugobj is created in several steps:
>
>* lto-wrapper cp_lto_pr51567-1_0.o -> ccPhb7tcdebugobjtem
>
>* ld -r -> cck5M.wddebugobj
>
>and g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o is from
>
>/usr/ccs/bin/as -V -Qy -s -xarch=v8plus -m32 -o
>g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o
>g++-dg-lto-pr51567-1-01.exe.ltrans0.s
>
>-save-temps preserves the .s file, but not the object.
>
>The ld warning above occurs (I believe) because the relocation offsets
>are wrong: the .debug_str section is only 9 bytes long
>
>Section Header[5]:  sh_name: .debug_str
>sh_addr:  0   sh_flags:   0
>sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
>sh_offset:0x5c7   sh_entsize: 0
>sh_link:  0   sh_info:0
>sh_addralign: 0x1   
>
>but the offsets are way beyond that.
>
>Relocation Section:  .rela.debug_str
>  index  type  offset value addend  sectionsymbol
>[0]  R_SPARC_UA32   0x175 0  0  .debug_str .debug_str (section)
>[1]  R_SPARC_UA32   0x1ab 0  0  .debug_str .debug_str (section)
>[2]  R_SPARC_UA32 0x6 0  0  .debug_str .debug_abbrev
>(section)
>
>The genesis of this section is especially strange:
>
>* In the original object (pre lto-wrapper) there are
>
>Section Header[5]:  sh_name: .gnu.debuglto_.debug_str
>sh_addr:  0   sh_flags:   0
>sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
>sh_offset:0x671   sh_entsize: 0
>sh_link:  0   sh_info:0
>sh_addralign: 0x1   
>
>Section Header[24]:  sh_name: .debug_str
>sh_addr:  0   sh_flags:   0
>sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
>sh_offset:0x1466  sh_entsize: 0
>sh_link:  0   sh_info:0
>sh_addralign: 0x1   
>
>  but no relocs for either section.  However I find
>
>Relocation Section:  .rela.gnu.debuglto_.debug_info
>  index  type offset value addend  section / symbol
>   [0]  R_SPARC_UA320x6 0  0  .gnu.debuglto_.debug_info
>.gnu.debuglto_.debug_abbrev (section)
>   [1]  R_SPARC_UA32  0x175 0  0  .gnu.debuglto_.debug_info
>.gnu.debuglto_.debug_str (section)
>   [2]  R_SPARC_UA32  0x1ab 0  0  .gnu.debuglto_.debug_info
>.gnu.debuglto_.debug_str (section)
>
>* After the lto-wrapper step, there's only .debug_str left
>
>Section Header[3]:  sh_name: .debug_str
>sh_addr:  0   sh_flags:   0
>sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
>sh_offset:0x485   sh_entsize: 0
>sh_link:  0   sh_info:0
>sh_addralign: 0x1   
>
>  but with the relocs relative to .debug_str
>
>Relocation Section:  .rela.gnu.debuglto_.debug_info
>  index  type  offset value addend  sectionsymbol
>[0]  R_SPARC_UA32 0x6 0  0  .debug_str .debug_abbrev
>(section)
>[1]  R_SPARC_UA32   0x175 0  0  .debug_str .debug_str (section)
>[2]  R_SPARC_UA32   0x1ab 0  0  .debug_str .debug_str (section)
>
>* After ld -r, there's
>
>Section 

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #33 from rguenther at suse dot de  ---
On December 21, 2017 4:20:35 PM GMT+01:00, "ro at CeBiTec dot Uni-Bielefeld.DE"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
>--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE dot Uni-Bielefeld.DE> ---
>Here are the additional types of failures found on Solaris/x86:
>
>* Invalid sh_info:
>
>FAIL: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o link, 
>-flto
>-flto-partition=none -g 
>FAIL: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o link, 
>-flto -g 
>
>ld: fatal: file /var/tmp//ccXwdzGddebugobjtem: section
>[6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 9
>ld: fatal: file /var/tmp//ccuVJOVbdebugobjtem: section
>[6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 8
>
>  seen during the ld -r -o ccrIZb_ddebugobj ccSerOuddebugobjtem
>  cc5b3Arcdebugobjtem step:
>
>ccSerOuddebugobjtem: .rel.gnu.debuglto_.debug_info: sh_info: 9: does
>not point
>to a valid section
>
>Section Header[6]:  sh_name: .rel.gnu.debuglto_.debug_info
>sh_addr:  0   sh_flags:   0
>sh_size:  0x8 sh_type:[ SHT_REL ]
>sh_offset:0x11c8  sh_entsize: 0x8 (1 entry)
>sh_link:  5   sh_info:9
>sh_addralign: 0x4   
>
>  But there's no section 9 any longer.

I fixed that in the posted patch for the hpux issue(s). 

>  In the input object (cp_lto_pr42987_0.o):
>
>Section Header[47]:  sh_name: .rel.gnu.debuglto_.debug_info
>sh_addr:  0   sh_flags:   0
>sh_size:  0x8 sh_type:[ SHT_REL ]
>sh_offset:0x4434  sh_entsize: 0x8 (1 entry)
>sh_link:  45  sh_info:9
>sh_addralign: 0x4   
>
>  with sh_info pointing at:
>
>Section Header[9]:  sh_name: .gnu.debuglto_.debug_info
>sh_addr:  0   sh_flags:   0
>sh_size:  0x3d4   sh_type:[ SHT_PROGBITS ]
>sh_offset:0x7fb   sh_entsize: 0
>sh_link:  0   sh_info:0
>sh_addralign: 0x1   
>
>*
>
>UNRESOLVED: g++.dg/lto/pr51650-1
>cp_lto_pr51650-1_0.o-cp_lto_pr51650-1_0.o
>execute  -flto -g 
>FAIL: g++.dg/lto/pr51650-1 cp_lto_pr51650-1_0.o-cp_lto_pr51650-1_0.o
>link, 
>-flto -g 
>
>ld: fatal: file /var/tmp//ccvDXoBddebugobjtem: section
>[6].rel.gnu.debuglto_.debug_info: relocations can not be applied
>against
>section [5].symtab
>
>  during ld -r:
>
>ld -r -o ccyWaCJadebugobj ccNQIWVcdebugobjtem
>ld: fatal: file ccNQIWVcdebugobjtem: section
>[6].rel.gnu.debuglto_.debug_info:
>relocations can not be applied against section [5].symtab
>
>Relocation Section:  .rel.gnu.debuglto_.debug_info
>  index  type  offset value  section symbol
>[0]  R_386_32 0x6 0  .symtab .debug_abbrev (section)
>
>  input object (cp_lto_pr51650-1_0.o):
>
>Relocation Section:  .rel.gnu.debuglto_.debug_info
>  index  type  offset value  section / symbol
>[0]  R_386_32 0x6 0  .gnu.debuglto_.debug_info
>.gnu.debuglto_.debug_abbrev (section)
>
>  I don't fully understand what the linker error is trying to say, but
>  obviously there's something amiss with reloc section remapping (or
>  lack thereof).
>
>Rainer

[Bug c++/55004] [meta-bug] constexpr issues

[ebotcazou at gcc dot gnu.org]

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

Bug 82872 Summary: [6/7 regression] ICE in ignore_overflows on __PTRDIFF_MAX__ 
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82872

   What|Removed |Added

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

[Bug c++/82872] [6/7 regression] ICE in ignore_overflows on __PTRDIFF_MAX__ index

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |8.0
Summary|[6/7/8 Regression] ICE in   |[6/7 regression] ICE in
   |ignore_overflows on |ignore_overflows on
   |__PTRDIFF_MAX__ index   |__PTRDIFF_MAX__ index

--- Comment #4 from Eric Botcazou  ---
No backport planned.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #24 from igor.v.tsimbalist at intel dot com ---
(In reply to Jakub Jelinek from comment #23)
> (In reply to igor.v.tsimbalist from comment #21)
> > Maybe I did more than expected :). Actually 512VNNI has VL bit according to
> > recently published extension. Please see
> > 
> > https://software.intel.com/sites/default/files/managed/c5/15/architecture-
> > instruction-set-extensions-programming-reference.pdf
> 
> Looking at the same paper, AVX512VPOPCNTDQ is also mixed with AVX512VL,
> though the 128-bit and 256-bit intrinsics and builtins aren't in GCC yet,
> but for
> VNNI there already is avx512vnnivlintrin.h and thus
> __builtin_ia32_vpdpbusd_v8si etc. can use | OPTION_MASK_ISA_AVX512VL after
> your patch immediately.

Agree. Specifying OPTION_MASK_ISA_AVX512VL has to be revised as well as
extension of OPTION_MASK_ISA_AVX512F_UNSET.

[Bug c++/82872] [6/7/8 Regression] ICE in ignore_overflows on __PTRDIFF_MAX__ index

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Dec 21 16:22:04 2017
New Revision: 255944

URL: https://gcc.gnu.org/viewcvs?rev=255944=gcc=rev
Log:
PR c++/82872
* convert.c (convert_to_integer_1) : Do not return the
shared zero if the input has overflowed.

Added:
trunk/gcc/testsuite/c-c++-common/pr82872.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/convert.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
I can confirm that the patch above indeed does work. Interestingly, I don't see
the bootstrap on all combinations of Apple Hardware and MAC OS X versions.
Apparently, the problem (for me) only shows up on an 2011 Apple i5 with both
Sierra and High Sierra and XCode 9.X. AFAI can say, the problem doesn't arise
for a 2015 i7 with the same combinations of OSX and XCode versions. 
Back to the fix by Dominique: yes, it works for the problematic combination I
checked.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
(In reply to igor.v.tsimbalist from comment #21)
> Maybe I did more than expected :). Actually 512VNNI has VL bit according to
> recently published extension. Please see
> 
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-
> instruction-set-extensions-programming-reference.pdf

Looking at the same paper, AVX512VPOPCNTDQ is also mixed with AVX512VL, though
the 128-bit and 256-bit intrinsics and builtins aren't in GCC yet, but for
VNNI there already is avx512vnnivlintrin.h and thus
__builtin_ia32_vpdpbusd_v8si etc. can use | OPTION_MASK_ISA_AVX512VL after your
patch immediately.

[Bug rtl-optimization/83513] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 3) in fill_vec_av_set in selective scheduler

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
> (btw it appears that either the comment or the sense of the last tiebreaker 
> is inverted)

I have to take that back, I was confused by the unusual tmp vs. tmp2 order:

  sel_rank_for_schedule (const void *x, const void *y)
  {
expr_t tmp = *(const expr_t *) y;
expr_t tmp2 = *(const expr_t *) x;

... and the ordering sel_rank_for_schedule seeks to produce is "worse insns
first, better last". The rest of the previous comment still stands.

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[florin.iucha at amd dot com]

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

Florin Iucha  changed:

   What|Removed |Added

 CC||florin.iucha at amd dot com

--- Comment #17 from Florin Iucha  ---
Warning if the code 'may alter its value' is one thing.

Can we have GCC at least not warn if it knows it will not alter the value?

For example, compiling

struct foo
{
   unsigned bar: 30;
   unsigned fill: 2;
};

struct foo test(unsigned value)
{
   struct foo foo;

   foo.bar = value >> 2;

   return foo;
}

This yields:

test.c: In function ‘test’:
test.c:11:14: warning: conversion to ‘unsigned int:30’ from ‘unsigned int’ may
alter its value [-Wconversion]
foo.bar = value >> 2;
  ^

Tested with GCC 5.4.0 and 7.2.

[Bug target/83536] New: One 'false' too much in r255699 for mingw target (in config/i386/i386.c)

[mateuszb at poczta dot onet.pl]

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

Bug ID: 83536
   Summary: One 'false' too much in r255699 for mingw target (in
config/i386/i386.c)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mateuszb at poczta dot onet.pl
  Target Milestone: ---

Copy from Jakub Jelinek [PATCH] Swap affects_type_identity and handler fields
in attribute_spec [r255699] config/i386/i386.c:
 #if TARGET_DLLIMPORT_DECL_ATTRIBUTES
-  { "dllimport", 0, 0, false, false, false, handle_dll_attribute, false, NULL
},
-  { "dllexport", 0, 0, false, false, false, handle_dll_attribute, false, NULL
},
-  { "shared",0, 0, true,  false, false, ix86_handle_shared_attribute,
-false, NULL },
+  { "dllimport", 0, 0, false, false, false, false, handle_dll_attribute,
+NULL },
+  { "dllexport", 0, 0, false, false, false, false, handle_dll_attribute,
+NULL },
+  { "shared",0, 0, true,  false, false, false,
+ix86_handle_shared_attribute, false, NULL },
 #endif

Please look at new "shared" -- 'false' is copied to front but not deleted from
old position. This breaks build for mingw target.

[Bug middle-end/81914] [7 Regression] gcc 7.1 generates branch for code which was branchless in earlier gcc version

[bugzi...@poradnik-webmastera.com]

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

--- Comment #12 from Daniel Fruzynski  ---
One more test case. Code compiled with TEST defined is branchless, without it
has branch.

[code]
#include 

#define TEST

void test(uint64_t* a)
{
  uint64_t n = *a / 8;
  if (0 == n)
n = 1;
#ifdef TEST
  *a += n;
#else
  *a += 1 << n;
#endif
}
[/code]

[Bug rtl-optimization/80747] [6/7/8 Regression] gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

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

[Bug rtl-optimization/83512] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
This is fixed by my PR80747 patch, I'll add the testcase to the patchset.

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

[Bug rtl-optimization/80747] [6/7/8 Regression] gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  I actually think instead of having some magic default we should,
in case we need to ignore the ENTRY succ edge in the greedy algorithm and thus
last_tail remains ENTRY, use the partition of the ENTRY successor bb.

And there is another bug that we don't copy the partition early enough and thus
create EDGE_CROSSING and mark the jump as crossing, then we copy the partition,
but nothing undoes the edge flags set to EDGE_CROSSING or CROSSING_JUMP_P on
the jump.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Ah, that changes the situation, I guess your patch is fine then (but please ask
still Uros or Kirill for approval on gcc-patches).  But make sure that the
i386-builtins.def | OPTION_MASK_ISA_AVX512VL additions and perhaps sse.md
changes for AVX512VL are done soon.

[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
The fix will be in gcc 7.3 which is planned for release during the third week
of January according to https://gcc.gnu.org/ml/gcc/2017-12/msg00102.html .

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #21 from igor.v.tsimbalist at intel dot com ---
Maybe I did more than expected :). Actually 512VNNI has VL bit according to
recently published extension. Please see

https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

I can go with my initial patch where I correct just OPTION_MASK_ISA_AVX512F_SET
and leave everything else to an owner of 512vnni implementation. Ok with that?

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Here are the additional types of failures found on Solaris/x86:

* Invalid sh_info:

FAIL: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o link,  -flto
-flto-partition=none -g 
FAIL: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o link,  -flto -g 

ld: fatal: file /var/tmp//ccXwdzGddebugobjtem: section
[6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 9
ld: fatal: file /var/tmp//ccuVJOVbdebugobjtem: section
[6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 8

  seen during the ld -r -o ccrIZb_ddebugobj ccSerOuddebugobjtem
  cc5b3Arcdebugobjtem step:

ccSerOuddebugobjtem: .rel.gnu.debuglto_.debug_info: sh_info: 9: does not point
to a valid section

Section Header[6]:  sh_name: .rel.gnu.debuglto_.debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x8 sh_type:[ SHT_REL ]
sh_offset:0x11c8  sh_entsize: 0x8 (1 entry)
sh_link:  5   sh_info:9
sh_addralign: 0x4   

  But there's no section 9 any longer.

  In the input object (cp_lto_pr42987_0.o):

Section Header[47]:  sh_name: .rel.gnu.debuglto_.debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x8 sh_type:[ SHT_REL ]
sh_offset:0x4434  sh_entsize: 0x8 (1 entry)
sh_link:  45  sh_info:9
sh_addralign: 0x4   

  with sh_info pointing at:

Section Header[9]:  sh_name: .gnu.debuglto_.debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x3d4   sh_type:[ SHT_PROGBITS ]
sh_offset:0x7fb   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

*

UNRESOLVED: g++.dg/lto/pr51650-1 cp_lto_pr51650-1_0.o-cp_lto_pr51650-1_0.o
execute  -flto -g 
FAIL: g++.dg/lto/pr51650-1 cp_lto_pr51650-1_0.o-cp_lto_pr51650-1_0.o link, 
-flto -g 

ld: fatal: file /var/tmp//ccvDXoBddebugobjtem: section
[6].rel.gnu.debuglto_.debug_info: relocations can not be applied against
section [5].symtab

  during ld -r:

ld -r -o ccyWaCJadebugobj ccNQIWVcdebugobjtem
ld: fatal: file ccNQIWVcdebugobjtem: section [6].rel.gnu.debuglto_.debug_info:
relocations can not be applied against section [5].symtab

Relocation Section:  .rel.gnu.debuglto_.debug_info
  index  type  offset value  section symbol
[0]  R_386_32 0x6 0  .symtab .debug_abbrev (section)

  input object (cp_lto_pr51650-1_0.o):

Relocation Section:  .rel.gnu.debuglto_.debug_info
  index  type  offset value  section / symbol
[0]  R_386_32 0x6 0  .gnu.debuglto_.debug_info
.gnu.debuglto_.debug_abbrev (section)

  I don't fully understand what the linker error is trying to say, but
  obviously there's something amiss with reloc section remapping (or
  lack thereof).

Rainer

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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

--- Comment #16 from simon at pushface dot org ---
I think this was actually INVALID.

I’m glad to report that Arno’s notes in Comment #14 do in fact solve the 
problem (after supplying dummies for the parts of the standard library that
aren’t actually present -- __gl_wc_encoding etc).

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
(In reply to igor.v.tsimbalist from comment #19)
> Created attachment 42947 [details]
> 512VNNI patch

What is the reason for moving it over?  At least right now you don't have any |
OPTION_MASK_ISA_AVX512VL or | OPTION_MASK_ISA_64BIT with it, and because there
is a high chance we'll get some new isas that will need that, better keep the
bits in isa_flags free for those.

I meant just:
 case OPT_mavx512vnni:
   if (value)
 {
   opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_AVX512VNNI_SET;
   opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA_AVX512VNNI_SET;
-  opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_AVX512F_SET;
-  opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA_AVX512F_SET;
+  opts->x_ix86_isa_flags |= OPTION_MASK_ISA_AVX512F_SET;
+  opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512F_SET;
 }
you had in your earlier patch.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #19 from igor.v.tsimbalist at intel dot com ---
Created attachment 42947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42947=edit
512VNNI patch

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #18 from igor.v.tsimbalist at intel dot com ---
Added a patch for m512vnni, which is done similarly to 512vbmi2. It looks like
most of avx512* bits have to be included in OPTION_MASK_ISA_AVX512F_UNSET. I
leave it to a separate revision of mask bits. Doing building and testing.

[Bug ada/83535] New: Doesn’t respect Size for an object

[simon at pushface dot org]

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

Bug ID: 83535
   Summary: Doesn’t respect Size for an object
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

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

The code in which this problem surfaced is for a Cortex-M CPU, and writes to 
a hardware register to generate an external interrupt. The attached demo is 
for the desktop.

I expected the write to NVIC_STIR to be a 32-bit write, with the input IRQ
extended to 32 bits (the hardware requires a 32-bit write). GCC 5, 6 and 7 
all do this.

GCC 8 (8.0.0 20171216) only writes 8 bits, with the result that the 
expected interrupt isn’t triggered.

The actual code is

   procedure Trigger_Interrupt (IRQ : Ada.Interrupts.Interrupt_ID) is
  --  The Software Trigger Interrupt Register.
  NVIC_STIR : Ada.Interrupts.Interrupt_ID
  with
Import,
Atomic,
Size=> 32,
Address => System'To_Address (16#e000_ef00#);
   begin
  NVIC_STIR := IRQ;
   end Trigger_Interrupt;

where

package Ada.Interrupts is
   pragma Pure;
   type Interrupt_ID is range 0 .. 44;
   ...

Discussion at
https://groups.google.com/d/msg/comp.lang.ada/ThIioaYg-_Y/OCWJNhX0DAAJ

[Bug c++/83534] New: C++17: typeinfo for noexcept function lacks noexcept information

[sbergman at redhat dot com]

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

Bug ID: 83534
   Summary: C++17: typeinfo for noexcept function lacks noexcept
information
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with current trunk towards GCC 8.0, but also with GCC 7.2.1:

> ~ cat test.cc
> #include 
> #include 
> void f1();
> void f2() noexcept;
> int main() { std::cout << (typeid(f1) == typeid(f2)) << '\n'; }
> 
> ~ g++ -std=c++17 test.cc
> ~ ./a.out
> 1

should print "0" instead, as those are different types since C++17 (and using

  typeid() == tpyeid()

instead correctly prints "0").

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I'm having a look at what's still going wrong with Eric's updated
patch.  On Solaris/SPARC, there are only two failures left:

FAIL: g++.dg/lto/pr51567-1 cp_lto_pr51567-1_0.o-cp_lto_pr51567-1_0.o link, 
-flto -g 

output is:
ld: warning: relocation error: R_SPARC_UA32: file /var/tmp//ccp39Xjadebugobj
section [8].debug_str: invalid offset symbol '.debug_str (section)': offset
0x
ld: warning: relocation error: R_SPARC_UA32: file /var/tmp//ccp39Xjadebugobj
section [8].debug_str: invalid offset symbol '.debug_str (section)': offset
0x2258

FAIL: g++.dg/lto/pr53470 cp_lto_pr53470_0.o-cp_lto_pr53470_0.o link,  -g -flto 

for both 32 and 64-bit.  Those are only warnings actually, but throw off
DejaGnu which doesn't expect linker output.

Investigating what's happending is unnecessarily hard right now because
even with -save-temps, a couple of the intermediate files are removed
and I needed to run the whole compilation under truss to see how they
are created.

Here's what I found for the g++.dg/lto/pr51567-1 case:

The linker warning happens during the final link step, which is
(omitting all paths to build directories)

 /usr/ccs/bin/ld -V -M  -Y P,/lib:/usr/lib -Qy -o g++-dg-lto-pr51567-1-01.exe
 /usr/lib/crt1.o crtp.o /usr/lib/crti.o /usr/lib/values-Xa.o
/usr/lib/values-xpg6.o  crtbegin.o
 cck5M.wddebugobj
 g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o -lstdc++ -lm
 -lrt -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
 crtend.o
 /usr/lib/crtn.o

cck5M.wddebugobj is created in several steps:

* lto-wrapper cp_lto_pr51567-1_0.o -> ccPhb7tcdebugobjtem

* ld -r -> cck5M.wddebugobj

and g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o is from

/usr/ccs/bin/as -V -Qy -s -xarch=v8plus -m32 -o
g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o
g++-dg-lto-pr51567-1-01.exe.ltrans0.s

-save-temps preserves the .s file, but not the object.

The ld warning above occurs (I believe) because the relocation offsets
are wrong: the .debug_str section is only 9 bytes long

Section Header[5]:  sh_name: .debug_str
sh_addr:  0   sh_flags:   0
sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
sh_offset:0x5c7   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

but the offsets are way beyond that.

Relocation Section:  .rela.debug_str
  index  type  offset value addend  sectionsymbol
[0]  R_SPARC_UA32   0x175 0  0  .debug_str .debug_str (section)
[1]  R_SPARC_UA32   0x1ab 0  0  .debug_str .debug_str (section)
[2]  R_SPARC_UA32 0x6 0  0  .debug_str .debug_abbrev (section)

The genesis of this section is especially strange:

* In the original object (pre lto-wrapper) there are

Section Header[5]:  sh_name: .gnu.debuglto_.debug_str
sh_addr:  0   sh_flags:   0
sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
sh_offset:0x671   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

Section Header[24]:  sh_name: .debug_str
sh_addr:  0   sh_flags:   0
sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
sh_offset:0x1466  sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

  but no relocs for either section.  However I find

Relocation Section:  .rela.gnu.debuglto_.debug_info
  index  type offset value addend  section / symbol
[0]  R_SPARC_UA320x6 0  0  .gnu.debuglto_.debug_info
.gnu.debuglto_.debug_abbrev (section)
[1]  R_SPARC_UA32  0x175 0  0  .gnu.debuglto_.debug_info
.gnu.debuglto_.debug_str (section)
[2]  R_SPARC_UA32  0x1ab 0  0  .gnu.debuglto_.debug_info
.gnu.debuglto_.debug_str (section)

* After the lto-wrapper step, there's only .debug_str left

Section Header[3]:  sh_name: .debug_str
sh_addr:  0   sh_flags:   0
sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
sh_offset:0x485   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

  but with the relocs relative to .debug_str

Relocation Section:  .rela.gnu.debuglto_.debug_info
  index  type  offset value addend  sectionsymbol
[0]  R_SPARC_UA32 0x6 0  0  .debug_str .debug_abbrev (section)
[1]  R_SPARC_UA32   0x175 0  0  .debug_str .debug_str (section)
[2]  R_SPARC_UA32   0x1ab 0  0  .debug_str .debug_str (section)

* After ld -r, there's

Section Header[5]:  sh_name: .debug_str
sh_addr:  0   sh_flags:   0
sh_size:  0x9 sh_type:[ SHT_PROGBITS ]
sh_offset:0x5c7   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

Relocation Section:  .rela.debug_str
  index  type  offset value 

[Bug c++/83533] error: no type named 'X' in 'using = ...'

[povelikin.rostislav at gmail dot com]

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

--- Comment #1 from Rostislav Povelikin  
---
If I change aliasing of u with typedef instead of using - works fine.

[Bug rtl-optimization/83513] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 3) in fill_vec_av_set in selective scheduler

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org
 Blocks||82407

--- Comment #2 from Alexander Monakov  ---
Thanks. So the fix for PR 82398 was incomplete. Here we have insns:

i1: uid: 43  prio: 0  usefulness: 100%
i2: uid: 20  prio: 3  usefulness: 0%
i3: uid: 46  prio: 5  usefulness: 0%

and sel_rank_for_schedule says i2 < i3 by priority difference, but i1 < i2 &&
i3 < i1 by uid difference (btw it appears that either the comment or the sense
of the last tiebreaker is inverted). Now priority comparison code doesn't
account for the possibility of priority being 0.

I think we should either
 - simplify priority comparison to always compare by (prio + prio_adj) * use
(in which case comparison i2i3 will fall down to uid comparison), or
 - slightly expand it to always sort zero-usefulness exprs after non-zero ones
(even when they have priority 0 like i1 in the example).

Andrey, do you have a preference?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
[Bug 82407] [meta-bug] qsort_chk fallout tracking

[Bug c++/83533] New: error: no type named 'X' in 'using = ...'

[povelikin.rostislav at gmail dot com]

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

Bug ID: 83533
   Summary: error: no type named 'X' in 'using = ...'
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: povelikin.rostislav at gmail dot com
  Target Milestone: ---

Created attachment 42945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42945=edit
Source code

Hi all,

Doesn't work with configuration described below. Works fine with other gcc
versions and other systems.

Source code in attached files.

Command line is:
gcc -v -save-temps a.cpp -std=c++11

Output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE a.cpp -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o a.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.7
 /usr/include/c++/4.7/x86_64-linux-gnu
 /usr/include/c++/4.7/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -fpreprocessed a.ii -quiet -dumpbase
a.cpp -mtune=generic -march=x86-64 -auxbase a -std=c++11 -version -o a.s
GNU C++ (Debian 4.7.2-5) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version
3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Debian 4.7.2-5) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version
3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 66d178dd81da8c975e003e06d9f5e782
a.cpp: In instantiation of ‘void foo() [with long unsigned int N = 3ul]’:
a.cpp:27:16:   required from here
a.cpp:20:23: error: no type named ‘d’ in ‘using u = struct internal::U >’



preprocessed source file:
# 1 "a.cpp"
# 1 ""
# 1 "a.cpp"
# 1 "/usr/include/c++/4.7/cstddef" 1 3
# 41 "/usr/include/c++/4.7/cstddef" 3

# 42 "/usr/include/c++/4.7/cstddef" 3

# 1 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/c++config.h" 1 3
# 171 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/c++config.h" 3
namespace std
{
  typedef long unsigned int size_t;
  typedef long int ptrdiff_t;


  typedef decltype(nullptr) nullptr_t;

}
# 414 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/c++config.h" 3
# 1 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/os_defines.h" 1 3
# 40 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/os_defines.h" 3
# 1 "/usr/include/features.h" 1 3 4
# 323 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/predefs.h" 1 3 4
# 324 "/usr/include/features.h" 2 3 4
# 356 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 1 3 4
# 359 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 360 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 2 3 4
# 357 "/usr/include/features.h" 2 3 4
# 388 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 1 3 4



# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 5 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 2 3 4




# 1 "/usr/include/x86_64-linux-gnu/gnu/stubs-64.h" 1 3 4
# 10 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 2 3 4
# 389 "/usr/include/features.h" 2 3 4
# 41 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/os_defines.h" 2 3
# 415 "/usr/include/c++/4.7/x86_64-linux-gnu/bits/c++config.h" 2 3


# 1 

[Bug gcov-profile/83509] [8 Regression] gcov-dump-8 unable to dump any gcda files

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Thu Dec 21 14:22:08 2017
New Revision: 255941

URL: https://gcc.gnu.org/viewcvs?rev=255941=gcc=rev
Log:
Fix gcov-dump tool for GCDA files (PR gcov-profile/83509).

2017-12-21  Martin Liska  

PR gcov-profile/83509
* gcov-dump.c (dump_gcov_file): Do not read info about
support_unexecuted_blocks for gcda files.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov-dump.c

[Bug ipa/83532] New: [8 Regression] ICE in apply_scale, at profile-count.h:955

[marxin at gcc dot gnu.org]

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

Bug ID: 83532
   Summary: [8 Regression] ICE in apply_scale, at
profile-count.h:955
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Can be seen during building of Python with PGO. One can debug that on x86_64
with r255776:

$ gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -fmessage-length=0
-grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
-DOPENSSL_LOAD_CONF  -fmessage-length=0 -grecord-gcc-switches -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -fmessage-length=0
-grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection  -std=c99
-Wextra -Wno-unused-result -Wno-unused-parameter
-Wno-missing-field-initializers -fmessage-length=0 -grecord-gcc-switches -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -fprofile-use
-fprofile-correction   -I. -I./Include   -fPIC -DPy_BUILD_CORE abstract.i
during GIMPLE pass: feedback_fnsplit
Objects/abstract.c: In function ‘_Py_CheckFunctionResult.part.11’:
Objects/abstract.c:3246:1: internal compiler error: in apply_scale, at
profile-count.h:955
0xc1970d profile_count::apply_scale(profile_count, profile_count) const
../../gcc/profile-count.h:955
0xc520be copy_edges_for_bb
../../gcc/tree-inline.c:2231
0xc53c23 copy_cfg_body
../../gcc/tree-inline.c:2752
0xc54634 copy_body
../../gcc/tree-inline.c:2971
0xc5dd5b tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
../../gcc/tree-inline.c:6038
0x79deda cgraph_node::create_version_clone_with_body(vec, vec*, bitmap_head*, bool,
bitmap_head*, basic_block_def*, char const*)
../../gcc/cgraphclones.c:984
0x13e7dbf split_function
../../gcc/ipa-split.c:1368
0x13ed920 execute_split_functions
../../gcc/ipa-split.c:1896
0x13edda8 execute_feedback_split_functions
../../gcc/ipa-split.c:1959
0x13edda8 execute
../../gcc/ipa-split.c:1991

Problem is that we do:

(gdb) p old_edge->count.debug()
Attempt to extract a component of a value that is not a struct or union
(gdb) p old_edge->count().debug()
1
$1 = void
(gdb) p num.debug()
1 (adjusted)
$2 = void
(gdb) p den.debug()
0

Thus a division by zero happens.