[Bug debug/82933] [8 Regression] valgrind error in set_cur_line_info_table with -g

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 21 07:50:15 2017
New Revision: 254987

URL: https://gcc.gnu.org/viewcvs?rev=254987=gcc=rev
Log:
PR debug/82933
* run-rtl-passes.c: Include debug.h.
(run_rtl_passes): Call debug_hooks->assembly_start.
* dwarf2out.c (dwarf2out_assembly_start): Return early if invoked
multiple times.

* gcc.dg/rtl/x86_64/pr82933.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/rtl/x86_64/pr82933.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/run-rtl-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82981] [7 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 21 07:49:14 2017
New Revision: 254986

URL: https://gcc.gnu.org/viewcvs?rev=254986=gcc=rev
Log:
PR target/82981
* internal-fn.c (expand_mul_overflow): Use OPTAB_WIDEN instead of
OPTAB_DIRECT in calls to expand_simple_binop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c

[Bug ada/83027] program hangs when Ada.Text_IO is with'ed both in executable and shared library

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Status|WAITING |NEW
Summary|An innocent do-nothing  |program hangs when
   |program hangs if linked |Ada.Text_IO is with'ed both
   |using shared library|in executable and shared
   ||library

--- Comment #18 from Eric Botcazou  ---
> Created attachment 42666 [details]
> Minimal example reprising the bug
> 
> I've created the minimal example reprising the bug.
> 
> The bug is actually awful: Just four innocent (doing nothing) source files
> cause the program to hang infinitely despite it was asked to do none.
> 
> Note that the bug is triggered only for dynamic libraries.

Thanks for the small reproducer.  This has apparently never worked correctly...

[Bug go/83071] gccgo: ICE in set_type

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Fixed.

[Bug go/83071] gccgo: ICE in set_type

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Nov 21 06:14:32 2017
New Revision: 254983

URL: https://gcc.gnu.org/viewcvs?rev=254983=gcc=rev
Log:
compiler: report error for ++/-- applied to a non-numeric type

This avoids a compiler crash.

Fixes GCC PR 83071.

Reviewed-on: https://go-review.googlesource.com/78875

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/statements.cc

[Bug target/83084] New: [7/8 Regression] -fcompare-debug failure on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 83084
   Summary: [7/8 Regression] -fcompare-debug failure on ppc64le
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---

On ppc64le:

trippels@gcc2-power8 out % cat v8-stack-trace-impl.ii
enum _Lock_policy { _S_atomic };
template <_Lock_policy = _S_atomic> struct A {
  bool m_fn1();
  int _M_use_count;
};
template <> bool A<>::m_fn1() {
  int a;
  do
if (a)
  return 0;
  while (__atomic_compare_exchange_n(&_M_use_count, , 0, 1, 4, 0));
}

trippels@gcc2-power8 out % g++ --save-temps -fcompare-debug -O2 -c
v8-stack-trace-impl.ii
g++: error: v8-stack-trace-impl.ii: -fcompare-debug failure

trippels@gcc2-power8 out % diff -u v8-stack-trace-impl.gkd
v8-stack-trace-impl.gk.gkd
--- v8-stack-trace-impl.gkd 2017-11-21 06:00:22.288381883 +
+++ v8-stack-trace-impl.gk.gkd  2017-11-21 06:00:22.308382369 +
@@ -69,16 +69,16 @@
  -> 10)
 (code_label # 0 0 8 (nil) [1 uses])
 (note # 0 0 [bb 5] NOTE_INSN_BASIC_BLOCK)
-(insn:TI # 0 0 (set (mem/v:BLK (scratch:DI) [  A8])
-(unspec:BLK [
-(mem/v:BLK (scratch:DI) [  A8])
-] UNSPEC_LWSYNC)) "v8-stack-trace-impl.ii":11# {*lwsync}
- (nil))
 (insn:TI # 0 0 (set (reg:SI 10 10 [138])
 (unspec_volatile:SI [
 (mem/v:SI (reg/f:DI 3 3 [orig:131 this ] [131]) [  S4 A32])
 ] UNSPECV_LL)) "v8-stack-trace-impl.ii":11# {load_lockedsi}
  (nil))
+(insn:TI # 0 0 (set (mem/v:BLK (scratch:DI) [  A8])
+(unspec:BLK [
+(mem/v:BLK (scratch:DI) [  A8])
+] UNSPEC_LWSYNC)) "v8-stack-trace-impl.ii":11# {*lwsync}
+ (nil))
 (insn:TI # 0 0 (set (reg:CC 68 0 [141])
 (compare:CC (reg:SI 10 10 [138])
 (const_int 0 [0]))) "v8-stack-trace-impl.ii":11# {*cmpsi_signed}

[Bug target/81325] -fcompare-debug failure on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #8 from Markus Trippelsdorf  ---
Closing.

[Bug c++/83060] ICE on valid C++ code: in ignore_overflows, at cp/cvt.c:583

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Only pointer expressions that compute the value of a pointer that points to the
same [sub]object or just past it are valid.  The following is undefined whether
or not there is padding between a.i and a.s:

  struct A { int i; int s[8]; } a;
  int *p = [-1];

[Bug tree-optimization/83080] ICE at -Os and above with -Wall on C++ code: Segmentation fault

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-21
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Introduced by my r254830.

The problem is that ELTSIZE is zero here:

  up_bound_p1 = int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize);

which makes int_const_binop() fail and return null.  The null up_bound_p1 is
then used below:

  tree arg = TREE_OPERAND (ref, 0);

  HOST_WIDE_INT off;
  if (get_addr_base_and_unit_offset (arg, ))
up_bound_p1 = wide_int_to_tree (sizetype,
wi::sub (wi::to_wide (up_bound_p1),
 off));

  up_bound_p1 = int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize);

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #25 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Nov 21 02:17:11 2017
New Revision: 254982

URL: https://gcc.gnu.org/viewcvs?rev=254982=gcc=rev
Log:
2017-11-20  Jerry DeLisle  

PR libgfortran/78549
* io/io.h (newunit_free): Add declaration. Clean some whitespace.
* io/transfer.c (st_read_done, st_write_done): Call newunit_free.
* io/unit.c (newunit_free): Change type from static void to void.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c

[Bug tree-optimization/67530] Failure to eliminate dead code produced by vector lowering

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
It seems to work fine now (on trunk at least)?

[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Trunk does (both -m32 and -m64)

srawi 9,4,5
addze 9,9
slwi 9,9,5
subf 4,9,4
srw 3,3,4

and

rlwinm 4,4,0,27,31
srw 3,3,4

so the original problem is still there.

[Bug fortran/83057] OPEN(3f) without a filename and without STATUS='SCRATCH' does not produce a warning as being an extension on unassigned files

[urbanjost at comcast dot net]

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

--- Comment #2 from urbanjost at comcast dot net ---
A long-standing convention when referencing procedures anprd commands,
especially on Unix platforms is to suffix them with (category[group]) to
distinguish them from English words and to identify if talking about a
procedure or a command. "(3f)" just means a callalable function or procedure, f
typically means Fortran, "c" for the C programming language, "X11" for X11
Windows routines and so on. This helps to clarify such things as sleep,
sleep(1), and sleep(3c) --- respectively meaning "to slumber", the GNU/Linux or
Unix command sleep, and and the C routine sleep.

[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault

[markmigm at gmail dot com]

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

--- Comment #6 from Mark Millard  ---
(In reply to Segher Boessenkool from comment #5)
> This was BE, on a compiler that defaults to power4 ("970 without altivec").
> I.e. the default for powerpc64-linux.

Good to know. Thanks.

I've no clue what or how to build a match to the
test environment and test technique that you used.

So unless I get the time to explore, I'll not be
establishing the repeatability of your result for
comparison to what happened under FreeBSD.

[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
This was BE, on a compiler that defaults to power4 ("970 without altivec").
I.e. the default for powerpc64-linux.

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed by r254981; marking as resolved.

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue Nov 21 00:57:29 2017
New Revision: 254981

URL: https://gcc.gnu.org/viewcvs?rev=254981=gcc=rev
Log:
Use -Wtraditional for "would be stringified in traditional C" (PR
preprocessor/81794)

libcpp/ChangeLog:

2017-03-24  Eric Gallager  

PR preprocessor/81794
* macro.c (check_trad_stringification): Have warning be controlled
by -Wtraditional.

gcc/testsuite/ChangeLog:

2017-09-17  Eric Gallager  

PR preprocessor/81794
* gcc.dg/pragma-diag-7.c: Update to include check for
stringification.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pragma-diag-7.c
trunk/libcpp/ChangeLog
trunk/libcpp/macro.c

[Bug c/81404] suggested hints for standard C macros should avoid GCC predefined macros

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Tue Nov 21 00:50:39 2017
New Revision: 254980

URL: https://gcc.gnu.org/viewcvs?rev=254980=gcc=rev
Log:
C/C++: more stdlib header hints (PR c/81404)

This patch extends the C frontend's "knowledge" of the C stdlib within
get_c_name_hint to cover some more macros and functions, covering
a case reported in PR c/81404 ("INT_MAX"), so that rather than printing:

  t.c:5:12: error: 'INT_MAX' undeclared here (not in a function); did you mean
'__INT_MAX__'?
   int test = INT_MAX;
  ^~~
  __INT_MAX__

we instead print:

  t.c:5:12: error: 'INT_MAX' undeclared here (not in a function)
   int test = INT_MAX;
  ^~~
  t.c:5:12: note: 'INT_MAX' is defined in header ''; did you forget
to '#include '?
  t.c:1:1:
  +#include 

  t.c:5:12:
int test = INT_MAX;
   ^~~

It also adds generalizes some of the code for this (and for the "std::"
namespace hints in the C++ frontend), moving it to a new
c-family/known-headers.cc and .h, and introducing a class known_headers.
This currently just works by scanning a hardcoded array of known
name/header associations, but perhaps in the future could be turned
into some kind of symbol database so that the compiler could record API
uses and use that to offer suggestions e.g.

foo.cc: error: 'myapi::foo' was not declared in this scope
foo.cc: note: 'myapi::foo" was declared in header 'myapi/private.h'
(included via 'myapi/public.h') when compiling 'bar.cc'; did you forget to
'#include "myapi/public.h"'?

or somesuch.

In any case, moving this to a class gives an easier way to locate the
hardcoded knowledge about the stdlib.

The patch also adds similar code to the C++ frontend covering
unqualified names in the standard library, so that rather than just
e.g.:

  t.cc:19:13: error: 'NULL' was not declared in this scope
   void *ptr = NULL;
   ^~~~

we can emit:

  t.cc:19:13: error: 'NULL' was not declared in this scope
   void *ptr = NULL;
   ^~~~
  t.cc:19:13: note: 'NULL' is defined in header ''; did you forget
  to '#include '?
  t.cc:1:1:
  +#include 

  t.cc:19:13:
   void *ptr = NULL;
   ^~~~

(Also XFAIL for PR c++/80567 added for the C++ testcase; this is a
separate pre-existing bug exposed by the testcase for PR 81404).

gcc/ChangeLog:
PR c/81404
* Makefile.in (C_COMMON_OBJS): Add c-family/known-headers.o.

gcc/c-family/ChangeLog:
PR c/81404
* known-headers.cc: New file, based on material from c/c-decl.c.
(suggest_missing_header): Copied as-is.
(get_stdlib_header_for_name): New, based on get_c_name_hint but
heavily edited to add C++ support.  Add some knowledge about
, , and .
* known-headers.h: Likewise.

gcc/c/ChangeLog:
PR c/81404
* c-decl.c: Include "c-family/known-headers.h".
(get_c_name_hint): Rename to get_stdlib_header_for_name and move
to known-headers.cc.
(class suggest_missing_header): Move to known-header.h.
(lookup_name_fuzzy): Call get_c_stdlib_header_for_name rather
than get_c_name_hint.

gcc/cp/ChangeLog:
PR c/81404
* name-lookup.c: Include "c-family/known-headers.h"
(lookup_name_fuzzy): Call get_cp_stdlib_header_for_name and
potentially return a new suggest_missing_header hint.

gcc/testsuite/ChangeLog:
PR c/81404
* g++.dg/spellcheck-stdlib.C: New.
* gcc.dg/spellcheck-stdlib.c (test_INT_MAX): New.


Added:
trunk/gcc/c-family/known-headers.cc
trunk/gcc/c-family/known-headers.h
trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/c-family/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/spellcheck-stdlib.c

[Bug c/81404] suggested hints for standard C macros should avoid GCC predefined macros

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed on trunk for gcc 8 by r254980.

[Bug c++/80567] bogus fixit hint for undeclared memset: else

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Tue Nov 21 00:50:39 2017
New Revision: 254980

URL: https://gcc.gnu.org/viewcvs?rev=254980=gcc=rev
Log:
C/C++: more stdlib header hints (PR c/81404)

This patch extends the C frontend's "knowledge" of the C stdlib within
get_c_name_hint to cover some more macros and functions, covering
a case reported in PR c/81404 ("INT_MAX"), so that rather than printing:

  t.c:5:12: error: 'INT_MAX' undeclared here (not in a function); did you mean
'__INT_MAX__'?
   int test = INT_MAX;
  ^~~
  __INT_MAX__

we instead print:

  t.c:5:12: error: 'INT_MAX' undeclared here (not in a function)
   int test = INT_MAX;
  ^~~
  t.c:5:12: note: 'INT_MAX' is defined in header ''; did you forget
to '#include '?
  t.c:1:1:
  +#include 

  t.c:5:12:
int test = INT_MAX;
   ^~~

It also adds generalizes some of the code for this (and for the "std::"
namespace hints in the C++ frontend), moving it to a new
c-family/known-headers.cc and .h, and introducing a class known_headers.
This currently just works by scanning a hardcoded array of known
name/header associations, but perhaps in the future could be turned
into some kind of symbol database so that the compiler could record API
uses and use that to offer suggestions e.g.

foo.cc: error: 'myapi::foo' was not declared in this scope
foo.cc: note: 'myapi::foo" was declared in header 'myapi/private.h'
(included via 'myapi/public.h') when compiling 'bar.cc'; did you forget to
'#include "myapi/public.h"'?

or somesuch.

In any case, moving this to a class gives an easier way to locate the
hardcoded knowledge about the stdlib.

The patch also adds similar code to the C++ frontend covering
unqualified names in the standard library, so that rather than just
e.g.:

  t.cc:19:13: error: 'NULL' was not declared in this scope
   void *ptr = NULL;
   ^~~~

we can emit:

  t.cc:19:13: error: 'NULL' was not declared in this scope
   void *ptr = NULL;
   ^~~~
  t.cc:19:13: note: 'NULL' is defined in header ''; did you forget
  to '#include '?
  t.cc:1:1:
  +#include 

  t.cc:19:13:
   void *ptr = NULL;
   ^~~~

(Also XFAIL for PR c++/80567 added for the C++ testcase; this is a
separate pre-existing bug exposed by the testcase for PR 81404).

gcc/ChangeLog:
PR c/81404
* Makefile.in (C_COMMON_OBJS): Add c-family/known-headers.o.

gcc/c-family/ChangeLog:
PR c/81404
* known-headers.cc: New file, based on material from c/c-decl.c.
(suggest_missing_header): Copied as-is.
(get_stdlib_header_for_name): New, based on get_c_name_hint but
heavily edited to add C++ support.  Add some knowledge about
, , and .
* known-headers.h: Likewise.

gcc/c/ChangeLog:
PR c/81404
* c-decl.c: Include "c-family/known-headers.h".
(get_c_name_hint): Rename to get_stdlib_header_for_name and move
to known-headers.cc.
(class suggest_missing_header): Move to known-header.h.
(lookup_name_fuzzy): Call get_c_stdlib_header_for_name rather
than get_c_name_hint.

gcc/cp/ChangeLog:
PR c/81404
* name-lookup.c: Include "c-family/known-headers.h"
(lookup_name_fuzzy): Call get_cp_stdlib_header_for_name and
potentially return a new suggest_missing_header hint.

gcc/testsuite/ChangeLog:
PR c/81404
* g++.dg/spellcheck-stdlib.C: New.
* gcc.dg/spellcheck-stdlib.c (test_INT_MAX): New.


Added:
trunk/gcc/c-family/known-headers.cc
trunk/gcc/c-family/known-headers.h
trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/c-family/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/spellcheck-stdlib.c

[Bug c/83011] -Wformat-truncation=2 difficult to avoid for non-constant bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|-Wformat-truncation wrongly |-Wformat-truncation=2
   |computes length (depends on |difficult to  avoid for
   |the position of numbers in  |non-constant bounds
   |the addition)   |

--- Comment #5 from Martin Sebor  ---
There's a difference between

  len = 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix)) + 1;

and

  len = 1 + 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix));

just like there's a difference between

  UINT_MAX + 0LU + 1

and

  1 + UINT_MAX + 0LU

The former promotes the 1 to unsigned long and evaluates the first addition in
that type (and the constant expression evaluates to 1) while the latter doesn't
promote it and evaluates the fist addition in unsigned long (and the constant
expression evaluates to 0).

The upshot is that the range of len that GCC sees in the first case is [1,
big-number] while in the second it's [0, big-number].  I explained why the
checker warns in the first case.  In the second case, calling snprintf with a
zero bound means to essentially have it assume the size is unlimited.  So the
checker never warns on this case.

In short, there is no issue with the computation.  There is a potential bug in
the program that would occur if (len < strlen (prefix) + 2) were true.  In
ILP32 that could happen for example if (timer_count == 82595524) and
(strlen(prefix) >= 20) were both satisfied.  In LP64 this can't happen but GCC
doesn't know that (it doesn't know that strlen(prefix) can't be larger than
PTRDIFF_MAX).

Anyway, having said all this I do agree that the warning in this case is too
difficult to deal with and should be adjusted so I'm going to confirm this
report on that basis.

[Bug c++/72786] Odd spelling suggestion with later defined macro: Suggestion is identical to unknown identifier

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue Nov 21 00:40:53 2017
New Revision: 254978

URL: https://gcc.gnu.org/viewcvs?rev=254978=gcc=rev
Log:
C++: provide macro used-before-defined hint (PR c++/72786)

This patch uses the name_hint/deferred_diagnostic to provide
a message in the C++ frontend if a macro is used before it is defined
e.g.:

test.c:6:24: error: expected ';' at end of member declaration
   virtual void clone() const OVERRIDE { }
^
 ;
test.c:6:30: error: 'OVERRIDE' does not name a type
   virtual void clone() const OVERRIDE { }
  ^~~~
test.c:6:30: note: the macro 'OVERRIDE' had not yet been defined
test.c:15:0: note: it was later defined here
 #define OVERRIDE override

It's possible to do it from the C++ frontend as tokenization happens
up-front (and hence the macro already exists when the above is parsed);
I attempted to do it from the C frontend, but because the C frontend only
tokenizes on-demand during parsing, the macro isn't known about until
later.

gcc/cp/ChangeLog:
PR c++/72786
* name-lookup.c (class macro_use_before_def): New class.
(lookup_name_fuzzy): Detect macro that were used before being
defined, and report them as such.

gcc/ChangeLog:
PR c++/72786
* spellcheck.h (best_match::blithely_get_best_candidate): New
accessor.

gcc/testsuite/ChangeLog:
PR c++/72786
* g++.dg/spellcheck-macro-ordering-2.C: New test case.
* g++.dg/spellcheck-macro-ordering.C: Add dg-message directives
for macro used-before-defined.

libcpp/ChangeLog:
PR c++/72786
* include/cpplib.h (cpp_macro_definition_location): New decl.
* macro.c (cpp_macro_definition): New function.


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-macro-ordering-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/spellcheck.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/spellcheck-macro-ordering.C
trunk/libcpp/ChangeLog
trunk/libcpp/include/cpplib.h
trunk/libcpp/macro.c

[Bug ada/83027] Hang when attaching a SIGINT handler

[porton at narod dot ru]

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

--- Comment #17 from Victor Porton  ---
Created attachment 42666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42666=edit
Minimal example reprising the bug

I've created the minimal example reprising the bug.

The bug is actually awful: Just four innocent (doing nothing) source files
cause the program to hang infinitely despite it was asked to do none.

Note that the bug is triggered only for dynamic libraries.

To reprise the bug unpack the attached minimal.tar.gz archive run

make all && make run

It stucks infinitely.

Now we know for sure: It is a GCC (or maybe linker) bug, not Ahven one.

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

[sje at gcc dot gnu.org]

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

--- Comment #8 from Steve Ellcey  ---
Author: sje
Date: Tue Nov 21 00:18:14 2017
New Revision: 254977

URL: https://gcc.gnu.org/viewcvs?rev=254977=gcc=rev
Log:
2017-11-20  Steve Ellcey  

PR target/81356
* gfortran.dg/pr45636.f90 (aarch64*-*-*): Remove from xfail list.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr45636.f90

[Bug c++/83083] New: c++2a concepts without -fconcepts

[h2+bugs at fsfe dot org]

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

Bug ID: 83083
   Summary: c++2a concepts without -fconcepts
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Currently GCC offers the Concepts TS via -fconcepts, but it doesn't seem to
offer the modified/reduced Concepts merged into C++2a. For forward
compatibility checks of existing code and also for comparison with other
compilers (which will hopefully start supporting C++2a concepts sometime next
year), it would very, very helpful if GCC8 provided the new
concepts-light-light via the regular -std=c++2a switch (without -fconcepts).

Is this a planned feature or not a priority? Will it make it into GCC8? I know
these things are not trivial, but it seems like it's "only" a subset of already
existing features that "just" needs to be rewired.

Thanks a lot for your work on this!

[Bug tree-optimization/83082] New: [8 regression] libgomp.graphite/force-parallel-1.c fails starting with r254888

[seurer at gcc dot gnu.org]

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

Bug ID: 83082
   Summary: [8 regression] libgomp.graphite/force-parallel-1.c
fails starting with r254888
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing this on powerpc64 both LE and BE:

make -k check-target-libgomp
RUNTESTFLAGS=graphite.exp=libgomp.graphite/force-parallel-1.c

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.graphite/force-parallel-1.c
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -ansi
-pedantic-errors -O2 -ftree-parallelize-loops=4 -floop-parallelize-all
-fdump-tree-parloops-details -fdump-tree-optimized -fno-loop-strip-mine
-fno-loop-block -fdump-tree-graphite-all
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs
-lm -o ./force-parallel-1.exe
PASS: libgomp.graphite/force-parallel-1.c (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/gcc/32:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/gcc/32:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libsanitizer/asan/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libsanitizer/asan/.libs:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.1.0/lib64
spawn [open ...]
PASS: libgomp.graphite/force-parallel-1.c execution test
FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2
loops carried no dependency" 1 (found 0 times)
FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times optimized
"loopfn" 8 (found 12 times)
testcase
/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.graphite/graphite.exp
completed in 0 seconds

=== libgomp Summary ===

# of expected passes2
# of unexpected failures2

[Bug middle-end/83074] Shared object built with `-pie --coverage' hangs forever

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Andreas Schwab  ---
> $ gcc -Wl,-L. -Wl,--export-dynamic -pie foo.o -o foo.so

Don't use --export-dynamic.  This causes __libc_csu_{init,fini} to be shared
between the objects instead of having a private copy in each object.

[Bug middle-end/83074] Shared object built with `-pie --coverage' hangs forever

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Stefan Vargyas from comment #3)
> This feature is quite useful in practice -- for example, the
> GNU C library is runnable this way too:
> 
>   $ /lib64/libc.so.6
>   GNU C Library stable release version 2.11.3 (20110527), by Roland McGrath
> et al.
>   ...

libc.so.6 is a shared library, not a PIE.  It is normally linked with -shared,
just arranged to have .interp section and a meaningful e_entry in Ehdr.
PIE is something significantly different, in particular it is the executable,
albeit position independent, e.g. required to be the first in symbol search
scope so that its symbols bind locally.

[Bug middle-end/83074] Shared object built with `-pie --coverage' hangs forever

[stvar at yahoo dot com]

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

--- Comment #3 from Stefan Vargyas  ---
> 
> Why do you expect you can use a PIE as a shared library?
> 

Well, with `-pie' one can issue 'foo.so' by itself:

  $ ./foo.so
  foo.so: version 0.1

This feature is quite useful in practice -- for example, the
GNU C library is runnable this way too:

  $ /lib64/libc.so.6
  GNU C Library stable release version 2.11.3 (20110527), by Roland McGrath et
al.
  ...

On the other hand, I deem the above use-case to be not that
useful whilest developing a library -- when one may use e.g.
`--coverage'.

Therefore, I myself have no problem with my (real) Makefile
discriminating 'LDFLAGS' as below:

  ifeq (${COVERAGE},yes)
  CFLAGS += --coverage
  LDFLAGS += --coverage -shared
  else
  LDFLAGS += -pie
  endif

[Bug rtl-optimization/70134] combine misses jump optimization on powerpc64le

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
PowerPC has no simple way to set a CR field to "equal".  We could add
a pattern to do that (which will cost 2 insns, so works for 3->2
combinations, like we in fact get here; something like  li X,0 ; cmpwi X,0 ).

But, this is normally handled by cprop, and in fact it works like you
would hope if you just add -fgcse.  So is this a bug, or just something
-O1 does not do?

[Bug middle-end/83074] Shared object built with `-pie --coverage' hangs forever

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Martin Liška from comment #1)
> Hi.
> 
> Thanks for the report. I isolated the issue and it's related to how
> constructors are called and hang in GCOV is just demonstration of the
> problem.
> 
> Please consider this:
> 
> $ cat foo.c
> __attribute__ ((constructor)) static void
> ctor2 ()
> {
>   static int c2 = 0;
>   __builtin_printf ("ctor2 called\n");
>   if (c2++ != 0)
> __builtin_abort ();
> }
> 
> int
> main (void)
> {
> }
> 
> $ cat bar.c
> __attribute__((constructor))
> static void ctor1() {
>   static int c1 = 0;
>   __builtin_printf ("ctor1 called\n");
>   if (c1++ != 0)
> __builtin_abort ();
> }
> 
> int main(void)
> {
> }
> 
> Then running:
> 
> $ gcc -g -I. -fPIC -c foo.c -o foo.o 
> $ gcc -g -I. -c bar.c -o bar.o 
> $ gcc -Wl,-L. -Wl,--export-dynamic -pie foo.o -o foo.so

Why do you expect you can use a PIE as a shared library?

[Bug c++/83045] [8 Regression] -Wreturn-type regression in C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

Patch I wrote for this.  Unfortunately it shows up various new warnings, so
I'll need to adjust the testsuite for it tomorrow.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #32 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #20)

> Index: gcc/tree-ssa-sccvn.c
> ===
> --- gcc/tree-ssa-sccvn.c(revision 254945)
> +++ gcc/tree-ssa-sccvn.c(working copy)
> @@ -3632,6 +3632,38 @@ visit_nary_op (tree lhs, gassign *stmt)

The patched compiler works for this particular case (a "break" is needed at the
top of the patch, though), but there are many other cases where a temporary
should be calculated and its value stored, e.g.:

--cut here--
void foo_OK (char *buf, unsigned int data)
{
  buf[0] = ~data >> 8;
  buf[1] = ~data;
}

void foo (char *buf, unsigned int data)
{
  buf[0] = ~data;
  buf[1] = ~data >> 8;
}

void bar (char *buf, unsigned int data)
{
  buf[0] = -data >> 8;
  buf[1] = -data;
}

void baz (char *buf, unsigned int data)
{
  buf[0] = (data+3) >> 8;
  buf[1] = (data+3);
}
--cut here--

Only foo_OK compiles (-O2 -march=haswell) to expected asm:

notl%esi
movbe   %si, (%rdi)

all others generate duplicated operation:

movb%sil, %al
notl%esi
notl%eax
movb%al, (%rdi)
movl%esi, %eax
movb%ah, 1(%rdi)

Should I open a new PR for the above enhancement?

[Bug target/68690] PowerPC64: TOC save in PHP core loop results in load hit store

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
On trunk it now is (since r254599):

===
std 2,24(1)
.p2align 5,,31
.L4:
ld 9,0(30)
mtctr 9
mr 12,9
bctrl
ld 2,24(1)
addic. 31,31,-1
bne 0,.L4
===

so, fixed.

[Bug gcov-profile/83074] Shared object built with `-pie --coverage' hangs forever

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 CC||hjl at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||matz at gcc dot gnu.org,
   ||schwab at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Hi.

Thanks for the report. I isolated the issue and it's related to how
constructors are called and hang in GCOV is just demonstration of the problem.

Please consider this:

$ cat foo.c
__attribute__ ((constructor)) static void
ctor2 ()
{
  static int c2 = 0;
  __builtin_printf ("ctor2 called\n");
  if (c2++ != 0)
__builtin_abort ();
}

int
main (void)
{
}

$ cat bar.c
__attribute__((constructor))
static void ctor1() {
  static int c1 = 0;
  __builtin_printf ("ctor1 called\n");
  if (c1++ != 0)
__builtin_abort ();
}

int main(void)
{
}

Then running:

$ gcc -g -I. -fPIC -c foo.c -o foo.o 
$ gcc -g -I. -c bar.c -o bar.o 
$ gcc -Wl,-L. -Wl,--export-dynamic -pie foo.o -o foo.so
$ gcc -Wl,-L. -l:foo.so -fPIC bar.o foo.so -o bar

$ ./bar
ctor2 called
ctor2 called
Aborted (core dumped)

Problem is that ctor1 is not called and we instead call ctor2 twice.
Note that clang compiler has the same problem.

To be honest I'm not shared libraries expert, but I'll CC some guys who can
help.

[Bug c/83011] -Wformat-truncation wrongly computes length (depends on the position of numbers in the addition)

[julien at trigofacile dot com]

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

--- Comment #4 from Julien ÉLIE  ---
Martin, the following thing still puzzles me.

len = 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix)) + 1;
=> gives a warning, as explained below

len = 1 + 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix));
=> gives *no* warning

len = 52 * timer_count + 28 + (prefix == NULL ? 0 : strlen(prefix));
=> gives *no* warning


Isn't there an issue to fix in how the checker assumes the size of the
destination?
I do not understand how such a computation could be a feature.

[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault

[markmigm at gmail dot com]

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

--- Comment #4 from Mark Millard  ---
(In reply to Segher Boessenkool from comment #3)
> Builds fine on powerpc64-linux, both trunk and 7.

Could you give information on how to set up
and run this test, including pointing to
what distribution to install and the like?
(In my context it would be installed on an
old PowerMac G5 so-called "quad core", if
possible.)

Knowing in more detail what type of context was
able to check this would be handy.

I'm not as familiar with Linux as with FreeBSD.

There may be an issue of big-endian powerp64 vs.
little-endian: FreeBSD is big-endian for the
PowerMac G5 context.

[Bug tree-optimization/83081] New: [8 regression][arm] gcc.dg/pr80218.c fails since r254888

[clyon at gcc dot gnu.org]

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

Bug ID: 83081
   Summary: [8 regression][arm] gcc.dg/pr80218.c fails since
r254888
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since r254888, I've noticed that:
FAIL: gcc.dg/pr80218.c scan-rtl-dump-not ira "Invalid sum"

on target arm-none-linux-gnueabi (it still works on arm-none-linux-gnueabihf)

This might be a duplicate of bug #83043.

[Bug target/77687] frame access after release without redzone on powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
Backported to 7; closing as fixed.

[Bug target/77687] frame access after release without redzone on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Mon Nov 20 20:10:28 2017
New Revision: 254968

URL: https://gcc.gnu.org/viewcvs?rev=254968=gcc=rev
Log:
rs6000: Don't touch below the stack pointer (PR77687)

With the 32-bit SVR4 ABI we don't have a red zone, so we have to restore
the callee-saved registers before we restore the stack pointer.

The previous fix for this PR failed in two ways, for huge frames: first,
we use a negative offset from r11 in that case, so the (mem:BLK 11) access
does no good; second, sched does not handle accesses to mem:BLK correctly
in this case (does not make dependencies).

This patch fixes it by doing a store to (mem:BLK (scratch)) instead.
This means no unrelated (not to stack) loads/stores can be moved over the
stack restore either, but so be it.


PR target/77687
* config/rs6000/rs6000.md (stack_restore_tie): Store to a scratch
address instead of to r1 and r11.

gcc/testsuite/
PR target/77687
* gcc.target/powerpc/pr77687.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr77687.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-11/msg01807.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org

--- Comment #18 from Janne Blomqvist  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01807.html

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #31 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #28)
> Ok, let's go with your patch then.

Committed as r254967:

Author: uros
Date: Mon Nov 20 19:52:14 2017
New Revision: 254967

URL: https://gcc.gnu.org/viewcvs?rev=254967=gcc=rev
Log:
* config/i386/i386.md (bswaphi2): New expander.
(*bswaphi2_movbe): New insn pattern.
(bswaphi -> rorhi pepehole2): New peephole pattern.

testsuite/ChangeLog:

* gcc.target/i386/movbe-5.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/movbe-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

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

--- Comment #16 from neil.n.carlson at gmail dot com ---
I've confirmed Dominique's findings: Code in comments 0, 5, 11 are working now
with Paul's commit (Thanks!), but comment 12 code still gives an ICE.

Should I create a new PR for that example, or is it fine leaving this PR open?

[Bug go/83071] gccgo: ICE in set_type

[pmatos at gcc dot gnu.org]

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

--- Comment #2 from pmatos at gcc dot gnu.org ---
(In reply to Ian Lance Taylor from comment #1)
> This is of course a compiler bug, but it's a crash on invalid code.  You
> can't write `input++` when `input` is a string type.  In Go the `++`
> operator only applies to integer types.  When I fix the compiler bug, you
> will get an error compiling this code instead of a crash.

Go beginner here... as in... began today. :)
Thanks for the explanation. Can't wait to try the fixed gccgo.

[Bug target/83052] ICE in extract_insn, at recog.c:2305 starting from r254560

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-11-20
Summary|[8 Regression] ICE in   |ICE in extract_insn, at
   |extract_insn, at|recog.c:2305 starting from
   |recog.c:2305 starting from  |r254560
   |r254560 |
  Known to fail||4.5.0, 5.4.0, 6.4.0, 7.2.0,
   ||8.0

--- Comment #2 from Martin Liška  ---
(In reply to Andi Kleen from comment #1)
> I'm not sure why you call it a regression? You must be running the test
> suite manually with the new option.

Sorry, I was too eager ;) and did PRs for multiple different issues.

It's very old, with -mcmodel=large, all releases I have are affected (4.5.0+).

[Bug go/83071] gccgo: ICE in set_type

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
This is of course a compiler bug, but it's a crash on invalid code.  You can't
write `input++` when `input` is a string type.  In Go the `++` operator only
applies to integer types.  When I fix the compiler bug, you will get an error
compiling this code instead of a crash.

[Bug tree-optimization/83075] [8 Regression] Invalid strncpy optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Fix: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01800.html

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Mon Nov 20 19:09:34 2017
New Revision: 254966

URL: https://gcc.gnu.org/viewcvs?rev=254966=gcc=rev
Log:
2017-11-20  Paul Thomas  

PR fortran/79072
* trans-expr.c (trans_class_vptr_len_assignment): Set from_len
if the temporary is unlimited polymorphic.
* trans-stmt.c (trans_associate_var): Use the fake result decl
to obtain the 'len' field from an explicit function result when
in that function scope.

2017-11-20  Paul Thomas  

PR fortran/79072
* gfortran.dg/class_result_5.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/class_result_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83080] New: ICE at -Os and above with -Wall on C++ code: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 83080
   Summary: ICE at -Os and above with -Wall on C++ code:
Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171120 (experimental) [trunk revision 254954] (GCC)
$
$ g++tk -O1 -c -Wall tmp.cpp
$ g++-7.2.0 -Os -c -Wall tmp.cpp
$
$ g++tk -Os -c -Wall tmp.cpp
tmp.cpp: In constructor ‘A::A()’:
tmp.cpp:9:9: warning: array subscript 0 is above array bounds of ‘int [0]’
[-Warray-bounds]
   b[0][0] = 0;
   ~~^
during GIMPLE pass: vrp
tmp.cpp:7:1: internal compiler error: Segmentation fault
 A::A ()
 ^
0xe6ccef crash_signal
../../gcc-source-trunk/gcc/toplev.c:325
0x9abc34 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.h:3459
0x9abc34 wi::to_wide(tree_node const*)
../../gcc-source-trunk/gcc/tree.h:5247
0x111c4c8 vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
../../gcc-source-trunk/gcc/tree-vrp.c:4811
0x112ea0f vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
../../gcc-source-trunk/gcc/tree-vrp.c:4780
0x112ea0f check_array_bounds
../../gcc-source-trunk/gcc/tree-vrp.c:4984
0x1158ec2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set<tree_node*, default_hash_traits<tree_node*> >*))
../../gcc-source-trunk/gcc/tree.c:11122
0x115931e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set<tree_node*, default_hash_traits<tree_node*> >*))
../../gcc-source-trunk/gcc/tree.c:11439
0xbc59c7 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-source-trunk/gcc/gimple-walk.c:221
0x111e542 vrp_prop::check_all_array_refs()
../../gcc-source-trunk/gcc/tree-vrp.c:5030
0x111fff3 vrp_prop::vrp_finalize(bool)
../../gcc-source-trunk/gcc/tree-vrp.c:6791
0x112ec14 execute_vrp
../../gcc-source-trunk/gcc/tree-vrp.c:6864
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$

-

struct A
{ 
  A ();
  int b[1][0];
};

A::A ()
{ 
  b[0][0] = 0;
}

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
 CC|qing.zhao at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |qing.zhao at oracle dot 
com
 Ever confirmed|0   |1

--- Comment #3 from Paolo Carlini  ---
Qing is on it.

[Bug middle-end/79538] missing -Wformat-overflow with %s and non-member array arguments

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|qing.zhao at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |qing.zhao at oracle dot 
com

--- Comment #3 from Paolo Carlini  ---
Qing is on it.

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
It's not possible. I meant to make it possible for GCC 8 (maybe even switch
make the gnu-versioned-namespace *always* use the new ABI, with no option to
use the old one).

[Bug target/81291] [6/7/8 Regression] wrong code with -O2 -fno-rerun-cse-after-loop -fno-tree-ter -fno-tree-vrp -funroll-loops due to improper carry

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Fixed on trunk.  This may be the same as PR82621, which I'll backport this
week.

[Bug tree-optimization/83075] [8 Regression] Invalid strncpy optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Good catch!

[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

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

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

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

While these variants compile :

$ cat z3.f90
program p
   print *, transfer('xy', ['a'])
end

$ cat z4.f90
program p
   print *, transfer(4_'xy', [4_'ab'])
end

$ cat z5.f90
program p
   print *, transfer(4_'xy', 4_'a')
end

[Bug fortran/83079] New: ICE in gfc_widechar_to_char, at fortran/scanner.c:198

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

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

Bug ID: 83079
   Summary: ICE in gfc_widechar_to_char, at fortran/scanner.c:198
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With this snippet :

$ cat z1.f90
program p
   print *, transfer(4_'xy', [4_'a'])
end


$ gfortran-8-20171119 -c z1.f90
f951: internal compiler error: in gfc_widechar_to_char, at
fortran/scanner.c:198
0x70b1a6 gfc_widechar_to_char(unsigned int const*, int)
../../gcc/fortran/scanner.c:198
0x724ff2 gfc_target_interpret_expr(unsigned char*, unsigned long, gfc_expr*,
bool)
../../gcc/fortran/target-memory.c:616
0x7250a7 interpret_array
../../gcc/fortran/target-memory.c:378
0x7250a7 gfc_target_interpret_expr(unsigned char*, unsigned long, gfc_expr*,
bool)
../../gcc/fortran/target-memory.c:567
0x719cc8 gfc_simplify_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:6618
0x6a4f41 do_simplify
../../gcc/fortran/intrinsic.c:4409
0x6af3ec gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4779
0x6f8745 resolve_unknown_f
../../gcc/fortran/resolve.c:2865
0x6f8745 resolve_function
../../gcc/fortran/resolve.c:3174
0x6f886a gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6704
0x6fefe2 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11062
0x6fecb7 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10108
0x6ff0eb gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11052
0x701aca resolve_codes
../../gcc/fortran/resolve.c:16412
0x701bce gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16447
0x6eb54a resolve_all_program_units
../../gcc/fortran/parse.c:6030
0x6eb54a gfc_parse_file()
../../gcc/fortran/parse.c:6280
0x72ff5f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/83078] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1110

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

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

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

Detected without "implicit none" :


$ cat z2.f90
program p
   type t
  integer :: a(n)
   end type t
   type(t) :: x = t([1, 2])
end


$ gfortran-8-20171119 -c z2.f90
z2.f90:3:19:

   integer :: a(n)
   1
Error: Variable 'n' at (1) in this context must be constant
z2.f90:3:19:

   integer :: a(n)
   1
Error: Variable 'n' at (1) in this context must be constant

[Bug fortran/83078] New: ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1110

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

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

Bug ID: 83078
   Summary: ICE in gfc_typenode_for_spec, at
fortran/trans-types.c:1110
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With an undefined value "n" :

$ cat z1.f90
program p
   implicit none
   type t
  integer :: a(n)
   end type t
   type(t) :: x = t([1, 2])
end


$ gfortran-8-20171119 -c z1.f90
z1.f90:1:0:

 program p

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1110
0x7a9ee3 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1110
0x7aa22a gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2213
0x755974 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1716
0x7589c7 generate_local_decl
../../gcc/fortran/trans-decl.c:5525
0x71d9ab do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x759622 generate_local_vars
../../gcc/fortran/trans-decl.c:5725
0x759622 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6372
0x6eb720 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x6eb720 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72ff5f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug libstdc++/83077] New: sso-string @ gnu-versioned-namespace.

[pawel_sikora at zoho dot com]

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

Bug ID: 83077
   Summary: sso-string @ gnu-versioned-namespace.
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

hi,
i'm using the -std=c++1y and i'd like to use sso-string implementation with
std::__7:: (gnu-versioned-namespace). i don't need a dual-abi. i'd like just a
single-new-abi. afaics in the gcc-7.2.0/libstdc++-v3/acinclude.m4 this isn't
possible.

[Bug fortran/83076] New: [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

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

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

Bug ID: 83076
   Summary: [8 Regression] ICE in
gfc_deallocate_scalar_with_status, at
fortran/trans.c:1598
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With testcase from pr78781 comment 2 :


$ gfortran-8-20171029 -c z2.f90 -fcoarray=lib
$
$ gfortran-8-20171105 -c z2.f90 -fcoarray=lib
z2.f90:8:0:

   if ( associated(x%z) ) deallocate(x%z)

internal compiler error: in gfc_deallocate_scalar_with_status, at
fortran/trans.c:1598
0x733640 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*,
bool, gfc_expr*, gfc_typespec, bool)
../../gcc/fortran/trans.c:1598
0x79fe76 gfc_trans_deallocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6747
0x72ff57 trans_code
../../gcc/fortran/trans.c:1984
0x793ff3 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1325
0x79ad2a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1356
0x730047 trans_code
../../gcc/fortran/trans.c:1916
0x756bfc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x733ac1 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2206
0x6e8abd translate_all_program_units
../../gcc/fortran/parse.c:6078
0x6e8abd gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72d3bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug tree-optimization/83075] New: [8 Regression] Invalid strncpy optimization

[jakub at gcc dot gnu.org]

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

Bug ID: 83075
   Summary: [8 Regression] Invalid strncpy optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

handle_builtin_stxcpy has:
  /* Strncpy() et al. cannot modify the source string.  Prevent the rest
 of the pass from invalidating the strinfo data.  */
  if (sisrc)
sisrc->dont_invalidate = true;
and I believe that is just wrong.  Consider following testcase:
typedef __SIZE_TYPE__ size_t;

size_t
foo (char *p, char *q)
{
  size_t l1 = __builtin_strlen (q);
  __builtin_strncpy (p, q, l1);
  size_t l2 = __builtin_strlen (q);
  return l1 + l2;
}

int
main ()
{
  char buf[16] = "abcdef";
  if (foo (buf + 6, buf) != 6 + 12)
__builtin_abort ();
  return 0;
}

The C99 standard says here:
The strncpy function copies not more than n characters (characters that follow
a null character are not copied) from the array pointed to by s2 to the array
pointed to by s1. If copying takes place between objects that overlap, the
behavior is undefined.

It specifically talks about 2 arrays, not about strings, and I believe there
is no overlap above, the source is the first 6 characters, the destination
starts after that.  So IMHO we aren't allowed to optimize away the second
strlen call.

[Bug tree-optimization/83075] [8 Regression] Invalid strncpy optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug gcov-profile/83074] New: Shared object built with `-pie --coverage' hangs forever

[stvar at yahoo dot com]

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

Bug ID: 83074
   Summary: Shared object built with `-pie --coverage' hangs
forever
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stvar at yahoo dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42664=edit
Source code, Makefile and test scenario

Dear maintainers,

While running the testing suite of one of my projects with coverage
instrumentation enabled, I came across the following issue of GCC:

The short story: a shared object built with `-pie --coverage' hangs
forever somewhere in function 'gcov_do_dump' (most likely in function
'compute_summary') in the file 'libgcc/libgcov-driver.c'.

This happens on a GNU/Linux x86_64 machine with GCC 7.2.0 built from
sources (using a stock GCC 4.3.4):

  $ make GCC=gcc-7.2.0 COVERAGE=yes -B
  gcc-7.2.0 -Wall -Wextra -std=gnu99 -g -I. --coverage -fPIC
-fvisibility=hidden -c foo.c -o foo.o 
  gcc-7.2.0 -Wl,-L. -Wl,--rpath-link=. --coverage -Wl,--export-dynamic -pie
foo.o -o foo.so
  gcc-7.2.0 -Wall -Wextra -std=gnu99 -g -I. --coverage -c bar.c -o bar.o 
  gcc-7.2.0 -Wl,-L. -Wl,--rpath-link=. --coverage -Wl,-rpath=. -l:foo.so -fPIC
bar.o foo.so -o bar

  $ time-out() {
local d="$1"; shift
timeout "$d" "$@"
[ "$?" -eq 124 ] && {
  echo >&2 "command timed out: $@"
  return 1
}
  }

  $ ./foo.so 
  foo.so: version: 0.1

  $ time-out 8 ./bar 
  bar: foo.so: version: 0.1
  command timed out: ./bar

  $ gdb -q --args ./bar
  Reading symbols from ./bar...done.
  (gdb) run
  Starting program: ./bar 
  bar: foo.so: version: 0.1
  ^C
  Program received signal SIGINT, Interrupt.
  0x77bd9012 in gcov_do_dump () from ./foo.so
  (gdb) backtrace
  #0  0x77bd9012 in gcov_do_dump () from ./foo.so
  #1  0x77bda3f2 in __gcov_exit () from ./foo.so
  #2  0x77bd84d9 in _GLOBAL__sub_D_00100_1_foo.c () from ./foo.so
  #3  0x77bd83df in __do_global_dtors_aux () from ./foo.so
  #4  0x in ?? ()

When `-pie' is replaced with `-shared' everything works nice.

Important to mention is that the behavior seen above doesn't occur
with GCC 4.3.4 and 4.8.0 (the only other GCC versions currently at
my disposal).

The story is presented in its entirety in the file 'test.txt' --
bundled within the attached tarball along with the source code
and Makefile that are producing the binaries 'foo.so' and 'bar'.

Sincerely,

Stefan Vargyas.

[Bug gcov-profile/83030] [8 regression] ICE in create_pseudo_cfg, at dwarf2cfi.c:2840

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Investigating.

[Bug tree-optimization/83041] redundant assignment from member array not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=23094

--- Comment #3 from Martin Sebor  ---
For what it's worth, I first noticed it in the following (arguably more
compelling) test case:

$ cat c.c && gcc -g -O2 -S -Wall -fdump-tree-strlen=/dev/stdout c.c
char a[4];

struct A { char a[4]; };

void f (struct A *p)
{
  __builtin_strcpy (a, p->a);
  __builtin_strcpy (a, p->a);
  __builtin_strcpy (a, p->a);
}

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

f (struct A * p)
{
  char[4] * _1;

   [local count: 1]:
  _1 = _2(D)->a;
  __builtin_strcpy (, _1);
  __builtin_strcpy (, _1);
  __builtin_strcpy (, _1);
  return;

}

[Bug debug/82933] [8 Regression] valgrind error in set_cur_line_info_table with -g

[jakub at gcc dot gnu.org]

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

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

Or we can just hack around this and hope dwarf2out or others don't rely on some
other hooks to be invoked before actually processing the RTL.

[Bug tree-optimization/83041] redundant assignment from member array not eliminated

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> I think we have a duplicate bug for this looking like

Yes bug 23094.

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Even if we allowed allocator you still can't use std::set
because the container code assumes a non-const value type in several places.

[Bug debug/82933] [8 Regression] valgrind error in set_cur_line_info_table with -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
The problem is that dwarf2out.c relies on
  (*debug_hooks->assembly_start) ();
being called before any RTL is finalized, which the __RTL handling in the C FE
violates.  This debug hook also can't be called more than once, and is invoked
by cgraph.
Would it be possible to stash the RTL somewhere into struct function or the
tree, just set some flag and only perform run_rtl_passes when such a function
is actually queued to be emitted?

[Bug gcov-profile/83030] [8 regression] ICE in create_pseudo_cfg, at dwarf2cfi.c:2840

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #1 from Martin Liška  ---
[...]
>> Can you please bisect to a single revision?
>
> Sure, will do.

The reghunt has now completed, identifying

2017-11-14  Jan Hubicka  

   * cfgloopmanip.c (duplicate_loop_to_header_edge): Cleanup profile
   manipulation.

Rainer

[Bug middle-end/79538] missing -Wformat-overflow with %s and non-member array arguments

[qing.zhao at oracle dot com]

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

Qing Zhao  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com

--- Comment #2 from Qing Zhao  ---
this is because the routine "get_range_strlen" misses the handling of regular
arrays. adding the support should fix this issue.

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

[qing.zhao at oracle dot com]

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

Qing Zhao  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com

--- Comment #2 from Qing Zhao  ---
This is reasonable. I will add the support for this into my implementation for
PR78809.

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
You can't allocate const memory, but in essence yes, that's the reason. The
standard says that an allocator's value type must be a non-const, non-volatile
object type, so std::allocator is undefined behaviour.

[Bug other/83048] wrap multi-statement macros in do {} while (0)

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> I wonder if we could use a macro like this:
> ...
> #define SAFE_MACRO_STMT(stmt) \

Submitted RFC at https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01782.html .

[Bug c/83056] GCC suggests the use of previously reported undeclared identifiers when reporting new undeclared identifiers

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

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

--- Comment #30 from Uroš Bizjak  ---
Another unhandled case:

--cut here--
typedef __SIZE_TYPE__ size_t;

void baz (char *buf, size_t base, unsigned int data)
{
  buf[base] = data;
  buf[base+1] = data >> 8;
}
--cut here--

compiles to:

movb%dl, (%rdi,%rsi)
movb%dh, 1(%rdi,%rsi)
ret

[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
Builds fine on powerpc64-linux, both trunk and 7.

[Bug libstdc++/48101] obscure error message with std::set

[gccbugs at jbapple dot com]

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

--- Comment #5 from gccbugs at jbapple dot com ---
What is the virtue of making std::allocator an error? Is this
required by the standard? Is it because calls to construct are writing to const
memory?

[Bug target/82981] [7 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 42662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42662=edit
gcc8-pr82981-arm.patch

Untested fix for the arm issue.

[Bug target/83052] [8 Regression] ICE in extract_insn, at recog.c:2305 starting from r254560

[andi-gcc at firstfloor dot org]

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

--- Comment #1 from Andi Kleen  ---
I'm not sure why you call it a regression? You must be running the test suite
manually with the new option. 

I haven't tested, but likely it will fail if you run that test with
-mcmodel=large too. The -mforce-indirect-call patch is really only a subset
of -mcmodel=large.  Then it would be more a latent bug.

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug c++/82882] [8 regression] ICE Segmentation fault

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #3 from Andrey Guskov  ---
Also seeing this in Qt. Confirmed.

[Bug c/83056] GCC suggests the use of previously reported undeclared identifiers when reporting new undeclared identifiers

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

Confirmed: this still affects trunk, with the C frontend (the "-O3 -Wall"
aren't needed).  The C++ frontend doesn't seem to be affected.

[Bug tree-optimization/83073] New: Range for VR_VARYING | [1, 1]

[glisse at gcc dot gnu.org]

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

Bug ID: 83073
   Summary: Range for VR_VARYING | [1, 1]
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Before r254954, for x | 1 where x is VR_VARYING, we would deduce a
VR_ANTI_RANGE ~[0, 0]. Since then, we deduce [-INT_MAX, INT_MAX]. Both make
sense, but it is strange that we get something different for VR_VARYING and for
a full range, and Richard thinks it is worth looking into (maybe
zero_nonzero_bits_from_vr).

-O2 -fdump-tree-optimized-all
int f(int x){return x|1;}

[Bug debug/82718] Bad DWARF5 .debug_loclists generation

[mark at gcc dot gnu.org]

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

--- Comment #6 from Mark Wielaard  ---
Building elfutils with -g -O2 -gdwarf-5 still fails without this patch with
current gcc trunk (just in a different file libdwfl/realloc.c instead of
elf_begin.c as reported originally). Using the proposed patch
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01895.html makes it build fine.

BTW. Building with -gdwarf-5 didn't fail with GCC 7.2.

[Bug target/82981] [7 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #13 from Christophe Lyon  ---
I have noticed that this patch (r254758) causes errors on several tests, for
instance:
c-c++-common/builtin-arith-overflow-2.c

target: arm-none-linux-gnueabi
--with-mode thumb
--with-cpu cortex-a9
and using -march=armv5t in the runtest flags/target board

spawn -ignore SIGHUP
/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-254758-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/xgcc
-B/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-254758-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c
-march=armv5t -fno-diagnostics-show-caret -fdiagnostics-color=never
-Wc++-compat -Wno-long-long -lm -o ./builtin-arith-overflow-2.exe^M
during RTL pass: expand^M
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c:
In function 'main':^M
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c:93:23:
internal compiler error: Segmentation fault^M
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c:103:3:
note: in expansion of macro 'RuntimeAssert'^M
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c:250:3:
note: in expansion of macro 'G_TEST'^M
0xba522f crash_signal^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/toplev.c:325^M
0xb3cd90 commutative_operand_precedence(rtx_def*)^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/rtlanal.c:3405^M
0xb3cedd swap_commutative_operands_p(rtx_def*, rtx_def*)^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/rtlanal.c:3475^M
0x7baa10 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*,
profile_probability)^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/dojump.c:996^M
0x9702c3 expand_mul_overflow^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/internal-fn.c:1841^M
0x970d1b expand_arith_overflow^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/internal-fn.c:2251^M
0x73749f expand_call_stmt^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/cfgexpand.c:2584^M
0x73749f expand_gimple_stmt_1^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/cfgexpand.c:3607^M
0x73749f expand_gimple_stmt^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/cfgexpand.c:3773^M
0x7393af expand_gimple_basic_block^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/cfgexpand.c:5774^M
0x73f1f6 execute^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-254758/gcc/cfgexpand.c:6375^M
Please submit a full bug report,^M

[Bug target/83068] Suboptimal code generated with -m32 using MMX reg

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Richard Biener  ---
STV pass "regression"

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83072] Late VRP optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look (after Jeff is finished moving stuff around).

[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Yes. r253955 to r253958 diff is:
--- pr50038.s.2539552017-11-20 09:52:43.0 -0500
+++ pr50038.s.2539582017-11-20 09:52:48.0 -0500
@@ -1,53 +1,55 @@
.file   "pr50038.c"
.text
.p2align 4,,15
.globl  test
.type   test, @function
 test:
 .LFB0:
.cfi_startproc
pushl   %edi
.cfi_def_cfa_offset 8
.cfi_offset 7, -8
pushl   %esi
.cfi_def_cfa_offset 12
.cfi_offset 6, -12
pushl   %ebx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl16(%esp), %eax
movl20(%esp), %edx
testl   %eax, %eax
jle .L1
movl24(%esp), %ecx
leal(%edx,%eax,2), %edi
.p2align 4,,10
.p2align 3
 .L3:
movzbl  (%edx), %esi
addl$2, %edx
addl$1, %ecx
movzbl  -1(%edx), %eax
-   imull   $19595, %esi, %esi
+   movl%esi, %ebx
imull   $38470, %eax, %eax
+   movzbl  %bl, %esi
+   imull   $19595, %esi, %esi
addl%esi, %eax
sarl$16, %eax
movb%al, -1(%ecx)
cmpl%edi, %edx
jne .L3
 .L1:
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 12
popl%esi
.cfi_restore 6
.cfi_def_cfa_offset 8
popl%edi
.cfi_restore 7
.cfi_def_cfa_offset 4
ret
.cfi_endproc
 .LFE0:
.size   test, .-test
.ident  "GCC: (GNU) 8.0.0 20171020 (experimental)"
.section.note.GNU-stack,"",@progbits
Before *.ira dump the IL is identical, RA makes different decisions because
MEMs are seen as more costly than before.
@@ -237,7 +237,7 @@ Ranges after the compression:
 Pressure: GENERAL_REGS=5
 Hard reg set forest:
   0:( 0-6 8-15)@0
-1:( 0-6)@135464
+1:( 0-6)@167080
   Allocno a0r99 of GENERAL_REGS(7) has 7 avail. regs  0-6, node:  0-6
(confl regs =  7-79)
   Allocno a1r104 of GENERAL_REGS(7) has 7 avail. regs  0-6, node:  0-6
(confl regs =  7-79)
   Allocno a2r103 of GENERAL_REGS(7) has 7 avail. regs  0-6, node:  0-6
(confl regs =  7-79)
@@ -266,9 +266,9 @@ Ranges after the compression:
 Making a0(r99,l0) colorable
 Making a1(r104,l0) colorable
 Making a3(r96,l0) colorable
-  Pushing a0(r99,l0)(cost 3058)
-  Pushing a3(r96,l0)(cost 9008)
-  Pushing a1(r104,l0)(cost 14358)
+  Pushing a0(r99,l0)(cost 3312)
+  Pushing a3(r96,l0)(cost 10962)
+  Pushing a1(r104,l0)(cost 16058)
   Pushing a13(r107,l0)(cost 0)
   Pushing a10(r108,l0)(cost 0)
   Pushing a8(r111,l0)(cost 0)
@@ -284,15 +284,12 @@ Ranges after the compression:
   Popping a11(r109,l0)  -- assign reg 4
   Popping a12(r93,l0)  -- assign reg 4
   Popping a2(r103,l0)  -- assign reg 0
-Spilling a0r99 for a12r93
-Assigning 3 to a12r93
-   a0(r99,l0)  -- assign hard reg 5
 Disposition:
-   12:r93  l0 33:r96  l0 20:r99  l0 52:r103 l0 0
+   12:r93  l0 43:r96  l0 20:r99  l0 32:r103 l0 0
 1:r104 l0 1   13:r107 l0 0   10:r108 l0 0   11:r109 l0 4
 9:r110 l0 48:r111 l0 07:r112 l0 0
 New iteration of spill/restore move
-+++Costs: overall 0, reg 0, mem 0, ld 0, st 0, move 0
Costs: overall 3400, reg 3400, mem 0, ld 0, st 0, move 0
 +++   move loops 0, new jumps 0

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[tschwinge at gcc dot gnu.org]

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

--- Comment #6 from Thomas Schwinge  ---
(In reply to Martin Liška from comment #5)
> Thanks for instructions, but apparently does not work for me:
> 
> make check-target-libgomp

>   === libgomp Summary ===
> 
> # of untested testcases   2

Oh, sorry, that must be the tests being skipped when you don't have a Nvidia
GPU.  Please remove the "dg-do run { target openacc_nvidia_accel_selected }"
directive from the test case file.

[Bug gcov-profile/83030] [8 regression] ICE in create_pseudo_cfg, at dwarf2cfi.c:2840

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Martin Liška  ---
> Thanks for the report. Unfortunately one needs native compiler for that. Do we
> have a working machine in GCC Compile Farm?

Not yet: I do have Solaris 11/SPARC and x86 zones for external access
that are meant to be integrated into the compile farm if possible.

> Can you please bisect to a single revision?

Sure, will do.

Rainer

[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED

--- Comment #3 from Jan Hubicka  ---
Looks like I set it to suspended instead of assigned and ignored ever since :(

[Bug target/82615] [8 Regression] SPEC CPU2006 453.povray ~10% performance deviation with r248863

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Yes, it fixed on Haswell, we're even slightly faster than before the
problematic revision. Tomorrow I'll measure Zen as well.

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Which causes the code to be accepted. I'd rather do:

template class allocator;  // undefined

so there's an error.

[Bug middle-end/82878] [7/8 Regression] ICE in assign_temp, at function.c:968 when using optimization

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Mon Nov 20 14:39:00 2017
New Revision: 254958

URL: https://gcc.gnu.org/viewcvs?rev=254958=gcc=rev
Log:
[PR c++/82878] pass-by-invisiref in lambda

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01115.html
PR c++/82878
PR c++/78495
* call.c (build_call_a): Don't set CALL_FROM_THUNK_P for inherited
ctor.
* cp-gimplify.c (cp_genericize_r): Restore THUNK dereference
inhibibition check removed in previous c++/78495 change.

PR c++/82878
* g++.dg/cpp0x/pr82878.C: New.
* g++.dg/cpp1z/inh-ctor38.C: Check moves too.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr82878.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C
trunk/gcc/testsuite/g++.dg/cpp1z/inh-ctor38.C

[Bug c++/78495] [7 regression][new inheriting ctors] invisible-ref parm has address taken

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Mon Nov 20 14:39:00 2017
New Revision: 254958

URL: https://gcc.gnu.org/viewcvs?rev=254958=gcc=rev
Log:
[PR c++/82878] pass-by-invisiref in lambda

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01115.html
PR c++/82878
PR c++/78495
* call.c (build_call_a): Don't set CALL_FROM_THUNK_P for inherited
ctor.
* cp-gimplify.c (cp_genericize_r): Restore THUNK dereference
inhibibition check removed in previous c++/78495 change.

PR c++/82878
* g++.dg/cpp0x/pr82878.C: New.
* g++.dg/cpp1z/inh-ctor38.C: Check moves too.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr82878.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C
trunk/gcc/testsuite/g++.dg/cpp1z/inh-ctor38.C

[Bug c++/83058] [6/7/8 Regression] ICE on C++ code with negative array index: in warn_placement_new_too_small, at cp/init.c:2666

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Target Milestone|8.0 |6.5
Summary|[8 Regression] ICE on C++   |[6/7/8 Regression] ICE on
   |code with negative array|C++ code with negative
   |index: in   |array index: in
   |warn_placement_new_too_smal |warn_placement_new_too_smal
   |l, at cp/init.c:2666|l, at cp/init.c:2666

--- Comment #1 from Jakub Jelinek  ---
Not so recent regression, started with r229827.
There are multiple bugs in that code:
if (CONSTANT_CLASS_P (adj))
should really be a test for TREE_CODE (adj) == INTEGER_CST, tree_to_shwi is
going to ICE on anything else.
  const_tree adj = TREE_OPERAND (oper, 1);
  if (!use_obj_size && CONSTANT_CLASS_P (adj))
adjust += tree_to_shwi (adj);
similarly, plus there is no checking of addition overflows.
I think it might be better to turn adjust into an offset_int in which you
compute everything and then check if it can actually be used (or force
use_obj_size otherwise).
  gcc_checking_assert (0 <= adjust);
this is where we ICE.  The comparison operand order is incorrect too.
  if (CONSTANT_CLASS_P (size))
Again, wrong check.  Should be probably if (tree_fits_uhwi_p (size)).
bytes_need = tree_to_uhwi (size);
  else if (nelts && CONSTANT_CLASS_P (nelts))
  bytes_need = tree_to_uhwi (nelts)
* tree_to_uhwi (TYPE_SIZE_UNIT (type));

The above is also misformatted, should be
bytes_need = tree_to_uhwi (nelts)
 * tree_to_uhwi (TYPE_SIZE_UNIT (type));
or
bytes_need = (tree_to_uhwi (nelts)
  * tree_to_uhwi (TYPE_SIZE_UNIT (type)));
or
bytes_need
  = tree_to_uhwi (nelts) * tree_to_uhwi (TYPE_SIZE_UNIT (type)));
What about the case when TYPE_SIZE_UNIT doesn't fit into uhwi?  That will ICE
too.

  else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (type)))
bytes_need = tree_to_uhwi (TYPE_SIZE_UNIT (type));

[Bug c++/83060] ICE on valid C++ code: in ignore_overflows, at cp/cvt.c:583

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
I recall discussion years back that concluded the
  int *p = [-1];
case was well formed (there being no access specifier between the two fields).

Of course the validity of the argument may have changed with updates to the
std.

[Bug target/82960] spu_machine_dependent_reorg does not handle jump_table_data insn

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Ulrich Weigand from comment #3)
> I'll have a look.

Thanks :)

>  I still need to get my SPU build environment back up and
> running, the build currently fails due to unrelated issues.
> 
> I remember looking at this a few years back:
> https://gcc.gnu.org/ml/gcc-patches/2013-04/msg00151.html
> 
> This seemed to have fixed the problem back then, not sure why this no longer
> works.

My guess would be that this problem in pad_bb was already present, but did not
show up when building without -fenable-checking=rtl.