[Bug tree-optimization/83311] New: Unable to optimize alloc calls with casts and string builtins

[denis.campredon at gmail dot com]

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

Bug ID: 83311
   Summary: Unable to optimize alloc calls with casts and string
builtins
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Hello,

The fix for #pr83128 does not optimize the following testcase which should
produce the same result

int fn() {
// same with malloc or calloc
char * s = __builtin_alloca(sizeof(*s));

   return ((char*)__builtin_memcpy(s, "a", 1))[0];
}
-

Regards,
Denis

[Bug ada/83310] New: Compiler crash

[porton at narod dot ru]

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

Bug ID: 83310
   Summary: Compiler crash
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru
  Target Milestone: ---

Created attachment 42805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42805=edit
The source causing the bug

Use the attached all.chop. Chop it with gnatchop.

I have not succeeded to create a minimal testing example, the attached sources
are rather long.

$ make
GPR_PROJECT_PATH="/usr/local/stow/rdf-ada/share/gpr" gprbuild
--relocate-build-tree -p -s -we libxmlboiler.gpr \
 -XLIBRARY_KIND=dynamic -XOBJ_DIR=./obj-dynamic
-Xsoversion=libxmlboiler.so.0.0.1 -XMODE=Install -XDEBUG_MODE=debug 
Compile
   [Ada]  boiler-global.adb
   [Ada]  boiler-rdf_format.ads
   [Ada]  boiler-rdf_format-resource-parser.adb
+===GNAT BUG DETECTED==+
| 7.2.0 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous memory
access|
| Error detected at boiler-rdf_format-resource-parser.adb:9:32 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/home/porton/Projects/bug/src/boiler-rdf_format-resource-parser.adb
/home/porton/Projects/bug/src/boiler-rdf_format-resource-parser.ads
/home/porton/Projects/bug/src/boiler-rdf_format-resource.ads
/home/porton/Projects/bug/src/boiler-rdf_format.ads
/home/porton/Projects/bug/src/boiler.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-uri.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-auxiliary.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-uri.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-auxiliary-handled_record.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-world.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-auxiliary-limited_handled_record.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-iostream.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-term.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-namespace_stack.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-namespace.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-world.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-rasqal.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-rasqal-world.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-log.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-node.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-model.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-statement.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-statement.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-stream.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-node_iterator.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-iterator.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-storage.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-query.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-raptor-syntaxes.ads
/usr/local/stow/rdf-ada/include/librdf.dynamic/rdf-redland-query_results.ads
/home/porton/Projects/bug/src/boiler-rdf_recursive_descent.ads
/home/porton/Projects/bug/src/boiler-global.ads
/home/porton/Projects/bug/src/boiler-directories.ads
/home/porton/Projects/bug/src/boiler-rdf_recursive_descent-enums.ads
/usr/share/ada/adainclude/simple-components/generic_directed_graph.ads
/usr/share/ada/adainclude/simple-components/generic_set.ads
/usr/share/ada/adainclude/simple-components/generic_unbounded_array.ads
/usr/share/ada/adainclude/simple-components/generic_address_order.ads
/home/porton/Projects/bug/src/boiler-rdf_recursive_descent.adb
/home/porton/Projects/bug/src/bindings/gettext_lib.ads
/home/porton/Projects/bug/src/boiler-auxiliary.ads
/home/porton/Projects/bug/src/boiler-auxiliary-string_formatter.ads

[Bug c/83309] New: Structure elements have O(n^2) compile time slowdown

[wsnyder at wsnyder dot org]

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

Bug ID: 83309
   Summary: Structure elements have O(n^2) compile time slowdown
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wsnyder at wsnyder dot org
  Target Milestone: ---

Created attachment 42804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42804=edit
Example program to make programs showing the slowdown

A program with >10K structure elements was taking hours to compile. The
attached program was used to make programs with different numbers of elements,
and the following was observed with G++ 7.2 (and also 5.4 and 4.4):

0.04 seconds to compile class with total of 2000 ints
0.11 seconds to compile class with total of 4000 ints
0.22 seconds to compile class with total of 6000 ints
0.41 seconds to compile class with total of 8000 ints
0.56 seconds to compile class with total of 1 ints

Which seems close to O(n^2).

The same is observed with a "typedef int"'ed type, but all times are
approximately 4 times longer:

0.15 seconds to compile class with total of 2000 typedef'ed ints
0.45 seconds to compile class with total of 4000 typedef'ed ints
0.90 seconds to compile class with total of 6000 typedef'ed ints
1.62 seconds to compile class with total of 8000 typedef'ed ints
2.58 seconds to compile class with total of 1 typedef'ed ints

If instead of having 2000 integers in a class, the program instead has 20
unique structures each with 100 members (the same 2000 total declarations), the
time is goes way down, as one would expect. This does show however the problem
is not related to file or total structure size. Not surprisingly, if enough
structures are used, a similar problem arises with a O(num_structures^2)
slowdown.

0.02 seconds to compile class with total of 2000 from 20 structs of 100
typedef'ed ints
0.03 seconds to compile class with total of 4000 from 40 structs of 100
typedef'ed ints
0.04 seconds to compile class with total of 6000 from 60 structs of 100
typedef'ed ints
0.07 seconds to compile class with total of 8000 from 80 structs of 100
typedef'ed ints
0.11 seconds to compile class with total of 1 from 100 structs of 100
typedef'ed ints

Thanks.

[Bug go/83308] Missing platform definitions for SH in libgo

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
I suspect you'll need other changes as well, such as a new file
libgo/go/internal/syscall/unix/getrandom_linux_sh.go.  For that matter you'll
need to add sh to libgo/go/go/build/syslist.go and to match.sh and
libgo/match.sh and libgo/testsuite/gotest.

[Bug go/83308] Missing platform definitions for SH in libgo

[bugdal at aerifal dot cx]

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

--- Comment #1 from Rich Felker  ---
If PCQUANTUM is the minimum unit/alignment for the program counter, which it
sounds like, then the value should be 2 not 4. SH has 16-bit opcodes.

[Bug go/83308] New: Missing platform definitions for SH in libgo

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 83308
   Summary: Missing platform definitions for SH in libgo
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: glaubitz at physik dot fu-berlin.de
CC: bugdal at aerifal dot cx, cmang at google dot com, ian at 
airs dot com,
jrtc27 at jrtc27 dot com, olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Trying to build gcc-7 with the Go frontend enabled fails with:

libtool: compile:  /<>/build/./gcc/xgcc
-B/<>/build/./gcc/ -B/usr/sh4-linux-gnu/bin/
-B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include
 -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<>/build/sys-include -DHAVE_CONFIG_H -I.
-I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../
../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config
-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc
-I../../../src/libgfortran/../libbacktr
ace -I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-d
eclaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections
-mieee -g -O2 -MT maxloc0_16_i16.lo -MD -MP -MF .deps/maxloc0_16_i16.Tpo -c
../../../src/libgf
ortran/generated/maxloc0_16_i16.c -o maxloc0_16_i16.o >/dev/null 2>&1
libtool: compile:  /<>/build/./gcc/gccgo
-B/<>/build/./gcc/ -B/usr/sh4-linux-gnu/bin/
-B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/includ
e -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<>/build/sys-include -O2 -g -I . -c
-fgo-pkgpath=runtime/internal/sys -fgo-compiling-runtime ../../../src/l
ibgo/go/runtime/internal/sys/intrinsics.go
../../../src/libgo/go/runtime/internal/sys/stubs.go
../../../src/libgo/go/runtime/internal/sys/sys.go version.go  -fPIC -o runtim
e/internal/.libs/sys.o
version.go:54:15: error: reference to undefined name 'unknown'
  ArchFamily = unknown
   ^

Looking at libgo/configure.ac, it seems that SH is missing here.

I'm currently testing the following change:

--- libgo/configure.ac.orig 2017-01-23 19:10:13.0 +0100
+++ libgo/configure.ac  2017-12-07 01:33:21.424493549 +0100
@@ -354,6 +354,13 @@
 GOARCH_CACHELINESIZE=256
 GOARCH_PCQUANTUM=2
 ;;
+  sh*-*-*)
+GOARCH=sh
+GOARCH_FAMILY=SH
+GOARCH_CACHELINESIZE=32
+GOARCH_PCQUANTUM=4
+GOARCH_MINFRAMESIZE=4
+;;
   sparc*-*-*)
 AC_COMPILE_IFELSE([
 #if defined(__sparcv9) || defined(__arch64__)

I know that PCQUANTUM=4 is the proper value for SH (jemalloc's source code has
4 for SH), but I'm not sure about CACHELINESIZE and MINFRAMESIZE. According to
[1], SH supports multiple page sizes, so the 4k default seems reasonable.

> [1] http://lars.nocrew.org/computers/processors/SuperH/sh4cpu_sh1.pdf

[Bug tree-optimization/80641] [7/8 Regression] Warning with std::vector resize in loop

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
So based my findings around c#5 we can classify this as a false positive.  GCC
has enough information lying around to prove the problematical memset can never
be reached, but fails to do so.

Martin's patch to drop some annotations into our std::vector implementation is
being discussed on the libstdc++ list.  I think if/when that patch goes forward
we reduce this to a non-regression misssed optimization -- and we'll probably
need to include cpp output for the testcase so that it's note tainted in the
future with Martin's annotations.

[Bug tree-optimization/69224] [6/7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Wed Dec  6 23:50:58 2017
New Revision: 255457

URL: https://gcc.gnu.org/viewcvs?rev=255457=gcc=rev
Log:
PR tree-optimization/69224
PR tree-optimization/80907
PR tree-optimization/82286
* gcc.dg/pr69224.c: New test.
* gcc.dg/pr80907.c: New test.
* gcc.dg/pr82286.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69224.c
trunk/gcc/testsuite/gcc.dg/pr80907.c
trunk/gcc/testsuite/gcc.dg/pr82286.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/82286] [6/7 Regression] Wrong array subscript is above array bounds

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Wed Dec  6 23:50:58 2017
New Revision: 255457

URL: https://gcc.gnu.org/viewcvs?rev=255457=gcc=rev
Log:
PR tree-optimization/69224
PR tree-optimization/80907
PR tree-optimization/82286
* gcc.dg/pr69224.c: New test.
* gcc.dg/pr80907.c: New test.
* gcc.dg/pr82286.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69224.c
trunk/gcc/testsuite/gcc.dg/pr80907.c
trunk/gcc/testsuite/gcc.dg/pr82286.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80907] [6/7 Regression] False positive: "warning: array subscript is above array bounds"

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Wed Dec  6 23:50:58 2017
New Revision: 255457

URL: https://gcc.gnu.org/viewcvs?rev=255457=gcc=rev
Log:
PR tree-optimization/69224
PR tree-optimization/80907
PR tree-optimization/82286
* gcc.dg/pr69224.c: New test.
* gcc.dg/pr80907.c: New test.
* gcc.dg/pr82286.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69224.c
trunk/gcc/testsuite/gcc.dg/pr80907.c
trunk/gcc/testsuite/gcc.dg/pr82286.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/83307] New: Miscompilation of range_for with initializer_list in constructors on MacOS (works on Linux)

[greenc at fnal dot gov]

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

Bug ID: 83307
   Summary: Miscompilation of range_for with
initializer_list in constructors on MacOS
(works on Linux)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: greenc at fnal dot gov
  Target Milestone: ---

Verified on G++ 6.3.0, 6.4.0 and 7.2.0 to work on Linux (RHEL7-ish) but fail on
Mac OS (at least El Capitan and Sierra), the test code *should* produce the
output:

s.x = 0.
s.x = 1.
s.x = 2.
s.x = 3.
Count = 4.
S.x = 4.
S.x = 5.
S.x = 6.
S.x = 7.
Xount = 4.
Final ...
S.x = 4.
S.x = 5.
S.x = 6.
S.x = 7.
Xount = 4.

On MacOS as specified above however, it produces:

Count = 0.
S.x = 4.
S.x = 5.
S.x = 6.
S.x = 7.
Xount = 4.
Final ...
S.x = 4.
S.x = 5.
S.x = 6.
S.x = 7.
Xount = 4.

instead. When the contents of the brace-enclosed initializer list are of basic
type (e.g. int or char const *) then the behavior of the range for in the
constructor is the same as that in the member function.

Changing the brace-enclosed initializer list to :

std::initializer_list { ... }

with -DTRY=1 makes no difference; changing it to:

std::vector { ... } however (with -DTRY=2), solves the problem.

It's possible this is a library rather than a C++ issue, but given the
constructor / non-constructor context dependence, and the OS dependence, and
the interaction between a brace-enclosed initializer list and
std::initializer_list, I flagged it as the latter.

Note also that optimizer level is irrelevant, as is language standard provided
it is C++11 or later, of course.

Test code:

// Compile with (e.g.):
//   g++ -DTRY=[012] -Wall -Wextra -Werror -pedantic -std=c++14 -O3 -g -o
test-ilist{,.cc}
#include 
#if (!defined TRY) || TRY == 0
#define CTYPE
#elif TRY == 1
#include 
#define CTYPE std::initializer_list
#elif TRY == 2
#include 
#define CTYPE std::vector
#else
#error "Uncrecognized value of TRY"
#define CTYPE
#endif

struct A {
  A();
  void f();
};

struct B {
  B(int i) : x(i) { }
  int x;
};

A::A()
{
  std::size_t count = 0ull;
  for ( auto const & s : CTYPE { B(0), B(1), B(2), B(3) } ) {
std::cerr << "s.x = " << s.x << ".\n";
++count;
  }
  std::cerr << "Count = " << count << ".\n";
  f();
}

void A::f()
{
  std::size_t xount = 0ull;
  for ( auto const & S : CTYPE { B(4), B(5), B(6), B(7) } ) {
std::cerr << "S.x = " << S.x << ".\n";
++xount;
  }
  std::cerr << "Xount = " << xount << ".\n";
}

int main()
{
  A a;
  std::cerr << "Final ...\n";
  a.f();
}

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[hainque at adacore dot com]

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

--- Comment #15 from hainque at adacore dot com  ---
And thanks Rainer for having confirmed that it resolves
the problem for you as well.

> On Dec 6, 2017, at 23:54 , hainque at adacore dot com 
>  wrote:
> 
>>> Confirmed, this patch solves the issue.
>>> 
>>> Thanks
>> 
>> Olivier, can we get the patch in, please?
> 
> As soon as I get an approval for it :)
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02537.html
> 
> will ping.

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[hainque at adacore dot com]

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

--- Comment #14 from hainque at adacore dot com  ---
> On Dec 6, 2017, at 21:16 , rai...@emrich-ebersheim.de 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470
>> 
>> Confirmed, this patch solves the issue.
>> 
>> Thanks
> 
> Olivier, can we get the patch in, please?

As soon as I get an approval for it :)

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02537.html

will ping.

[Bug c++/80259] [6/7 Regression] ICE deleting friend function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE  |[6/7 Regression] ICE
   |deleting friend function|deleting friend function

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

[Bug sanitizer/81281] [6/7 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] UBSAN:   |[6/7 Regression] UBSAN:
   |false positive, dropped |false positive, dropped
   |promotion to long type. |promotion to long type.

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

[Bug tree-optimization/83293] [8 regression] ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:278

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80259] [6/7/8 Regression] ICE deleting friend function

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  6 22:48:39 2017
New Revision: 255456

URL: https://gcc.gnu.org/viewcvs?rev=255456=gcc=rev
Log:
PR c++/80259
* decl2.c (grokfield): Diagnose = delete redefinition of a friend.

* g++.dg/cpp0x/pr80259.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr80259.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/83306] New: filesystem_error is not nothrow copyable

[rs2740 at gmail dot com]

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

Bug ID: 83306
   Summary: filesystem_error is not nothrow copyable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Since it stores two paths and a string directly as members. 

This violates [exception]/2:

Each standard library class T that derives from class exception shall have a
publicly accessible copy constructor and a publicly accessible copy assignment
operator that do not exit with an exception.

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Dec  6 21:42:02 2017
New Revision: 255454

URL: https://gcc.gnu.org/viewcvs?rev=255454=gcc=rev
Log:
PR c++/82115 - ICE with variable initialized with its own address.

* pt.c (value_dependent_expression_p): Add lval parameter.  Don't
consider DECL_INITIAL if it's true.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-self1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug preprocessor/83305] Some warnings are suppressed when compiling preprocessed files

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Jakub Jelinek  ---
Preprocessing discards information, so obviously lots of warnings are affected,
by not being able to track the preprocessor macros, by seeing the tokens coming
from different locations, or by comments used e.g. for -Wimplicit-fallthrough
being discarded.
You can use -fdirectives-only -E preprocessing instead, which keeps macros as
is.

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[rai...@emrich-ebersheim.de]

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

--- Comment #13 from Rainer Emrich  ---
(In reply to Rainer Emrich from comment #12)
> (In reply to Olivier Hainque from comment #11)
> > Comment on attachment 42747 [details]
> > don't emit .cfi_personality/.cfi_lsda for !dwarf2 eh
> > 
> > >diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> > >index 3d619b8..62b5c77 100644
> > >--- a/gcc/dwarf2out.c
> > >+++ b/gcc/dwarf2out.c
> > >@@ -958,10 +958,16 @@ dwarf2out_do_cfi_startproc (bool second)
> > > {
> > >   int enc;
> > >   rtx ref;
> > >-  rtx personality = get_personality_function (current_function_decl);
> > > 
> > >   fprintf (asm_out_file, "\t.cfi_startproc\n");
> > > 
> > >+  /* .cfi_personality and .cfi_lsda are only relevant to DWARF2
> > >+ eh unwinders.  */
> > >+  if (targetm_common.except_unwind_info (_options) != UI_DWARF2)
> > >+return;
> > >+
> > >+  rtx personality = get_personality_function (current_function_decl);
> > >+
> > >   if (personality)
> > > {
> > >   enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2, /*global=*/1);
> 
> Confirmed, this patch solves the issue.
> 
> Thanks

Olivier, can we get the patch in, please?

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be fixed on trunk as of r255453.

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec  6 20:02:55 2017
New Revision: 255453

URL: https://gcc.gnu.org/viewcvs?rev=255453=gcc=rev
Log:
C/C++: don't suggest implementation names as spelling fixes (PR c/83236)

gcc/c-family/ChangeLog:
PR c/83236
* c-common.c (selftest::c_family_tests): Call
selftest::c_spellcheck_cc_tests.
* c-common.h (selftest::c_spellcheck_cc_tests): New decl.
* c-spellcheck.cc: Include "selftest.h".
(name_reserved_for_implementation_p): New function.
(should_suggest_as_macro_p): New function.
(find_closest_macro_cpp_cb): Move the check for NT_MACRO to
should_suggest_as_macro_p and call it.
(selftest::test_name_reserved_for_implementation_p): New function.
(selftest::c_spellcheck_cc_tests): New function.
* c-spellcheck.h (name_reserved_for_implementation_p): New decl.

gcc/c/ChangeLog:
PR c/83236
* c-decl.c (lookup_name_fuzzy): Don't suggest names that are
reserved for use by the implementation.

gcc/cp/ChangeLog:
PR c/83236
* name-lookup.c (consider_binding_level): Don't suggest names that
are reserved for use by the implementation.

gcc/testsuite/ChangeLog:
PR c/83236
* c-c++-common/spellcheck-reserved.c: New test case.


Added:
trunk/gcc/testsuite/c-c++-common/spellcheck-reserved.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-spellcheck.cc
trunk/gcc/c-family/c-spellcheck.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/83305] New: Some warnings are suppressed when compiling preprocessed files

[rrendec at arista dot com]

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

Bug ID: 83305
   Summary: Some warnings are suppressed when compiling
preprocessed files
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rrendec at arista dot com
  Target Milestone: ---

Test sample code:

#include 
int foo() {
   return 1 != NULL;
}

When compiling directly, this produces the following warning:

$ g++ -c -o test.o test.cpp  
test.cpp: In function ‘int foo()’:
test.cpp:3:16: warning: NULL used in arithmetic [-Wpointer-arith]
return 1 != NULL;
^~~~

When preprocessing and compiling in separate steps, it produces no warnings:
$ g++ -c -E -o test.ii test.cpp
$ g++ -c -o test.o test.ii

The same happens when using -no-integrated-cpp or -save-temps.

The notable use case is ccache, which compiles the preprocessed file as an
optimization.

This looks very similar to BUG60014, but looking at the preprocessor output it
seems this is a different issue. It also looks very similar to BUG60723.

In fact, I believe this is a side effect of the patches that fix BUG60723. With
older gcc versions that don't have the patches (e.g. 4.7.2), the line markers
around __null in the preprocessed output are not present and the problem does
not appear.

[Bug c++/83300] Segmentation fault with template and __attribute__((vector_size (sizeof(int) * N)));

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Created attachment 42801 [details]
> > gcc8-pr83300.patch
> > 
> > Completely untested patch.
> 
> OK.

Unfortunately it breaks 
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++11  (test for warnings, line 11)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++11  (test for warnings, line 8)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++11 (internal compiler error)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++11 (test for excess errors)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++14  (test for warnings, line 11)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++14  (test for warnings, line 8)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp0x/alias-decl-59.C  -std=c++14 (test for excess errors)
so back to the drawing board.

[Bug c++/83300] Segmentation fault with template and __attribute__((vector_size (sizeof(int) * N)));

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 42801 [details]
> gcc8-pr83300.patch
> 
> Completely untested patch.

OK.

[Bug tree-optimization/83293] [8 regression] ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:278

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  6 19:27:41 2017
New Revision: 255451

URL: https://gcc.gnu.org/viewcvs?rev=255451=gcc=rev
Log:
PR tree-optimization/83293
* gimple-ssa-strength-reduction.c (insert_initializers): Use
GSI_NEW_STMT instead of GSI_SAME_STMT in gsi_insert_after that
might insert into empty bb.

* g++.dg/torture/pr83293.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr83293.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/83303] [8 Regression] FAIL: g++.dg/opt/new1.C on arm-none-eabi (extra -Walloc-size-larger-than warning)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #5 from Martin Sebor  ---
The failure should be gone with r255450.

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
But losing a clobber like that is just fine (even losing a SET is fine, if
its dest is REG_UNUSED, and combine actually does that in certain cases).

[Bug testsuite/83303] [8 Regression] FAIL: g++.dg/opt/new1.C on arm-none-eabi (extra -Walloc-size-larger-than warning)

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Wed Dec  6 19:22:55 2017
New Revision: 255450

URL: https://gcc.gnu.org/viewcvs?rev=255450=gcc=rev
Log:
PR testsuite/83303 - FAIL: g++.dg/opt/new1.C on arm-none-eabi
(extra -Walloc-size-larger-than warning

* g++.dg/opt/new1.C: Prune warning from test output.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/opt/new1.C

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  6 19:22:06 2017
New Revision: 255449

URL: https://gcc.gnu.org/viewcvs?rev=255449=gcc=rev
Log:
PR sanitizer/81281
* match.pd ((T)(P + A) - (T)P -> (T) A): Split into separate
simplify for plus with :c added, and pointer_plus without that.
((T)P - (T)(P + A) -> -(T) A): Likewise.  If type is integral
with undefined overflow and the conversion is not widening,
perform negation in utype and only convert to type afterwards.
((T)(P + A) - (T)(P + B) -> (T)A - (T)B): Split into separate
simplify for plus with :c added, and pointer_plus without that.
If type is integral with undefined overflow and the conversion is
not widening, perform minus in utype and only convert to type
afterwards.  Move the last pointer_diff_expr simplify into the
two outermost ifs.

* gcc.c-torture/execute/pr81281.c: New test.
* gcc.dg/pr81281-1.c: New test.
* gcc.dg/pr81281-2.c: New test.
* g++.dg/ubsan/pr81281.C: New test.
* g++.dg/ubsan/pr81281-aux.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr81281-aux.cc
trunk/gcc/testsuite/g++.dg/ubsan/pr81281.C
trunk/gcc/testsuite/gcc.c-torture/execute/pr81281.c
trunk/gcc/testsuite/gcc.dg/pr81281-1.c
trunk/gcc/testsuite/gcc.dg/pr81281-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug target/83252] [8 Regression] Wrong code with "-march=skylake-avx512 -O3"

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #12)
> This broke again with r255377.
> Testcase in patch form at
> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00133.html

I've started to work on it.  In any case the patch will need a lot of testing. 
I hope to have a fix on this week or at the start of next week.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
I am still working on this PR.  I hope to fix it on this week or on the next
one (the patch will need a lot of testing).

[Bug testsuite/83303] [8 Regression] FAIL: g++.dg/opt/new1.C on arm-none-eabi (extra -Walloc-size-larger-than warning)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-06
 CC||msebor at gcc dot gnu.org
  Component|middle-end  |testsuite
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
I can reproduce the warning with an arm-non-eabi cross-compiler.  Based on the
source code copied below the warning seems justified:

  template  void QScript::Buffer::resize(int s) {
if (m_capacity < s)   // s == 0 so m_capacity is negative
  reserve (s << 1);
  }

  template  void QScript::Buffer::reserve(int x) {
T *new_data = new T[m_capacity];   // m_capacity is negative
...
  }

  inline void QScriptObject::reset() { m_values.resize(0); }

Other compilers, and with -O2 also the arm-non-eabi cross-compiler, optimize
the test to a trap, further validating that a warning is justified (in fact,
I'd say not issuing one is suboptimal given that the emitted code will
unavoidably abort at runtime).

  QScript::Ecma::Boolean::newBoolean (struct Boolean * const this, struct
QScriptValueImpl * result, bool value)
  {
int _4;

 [local count: 1073741825]:
_4 ={v} MEM[(int *)0B + 4B];
__builtin_trap ();
  }

Since the purpose of the test is to verify the absence of an ICE (pr39367),
whether or not it triggers any warnings doesn't seem important and pruning them
from its output should be appropriate.

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
So I'm digging through the combine dumps...
Before the r255384 we have:

Trying 70 -> 19:
   70: r131:SI={(cc:CC!=0)?r130:SI:0x}
  REG_DEAD r130:SI
   19: {r134:SI=r131:SI!=0x;clobber cc:CC;}
  REG_UNUSED cc:CC
  REG_DEAD r131:SI
Can't combine i2 into i3.

But after we succeed:
Trying 70 -> 19:
   70: r131:SI={(cc:CC!=0)?r130:SI:0x}
  REG_DEAD r130:SI
   19: {r134:SI=r131:SI!=0x;clobber cc:CC;}
  REG_UNUSED cc:CC
  REG_DEAD r131:SI
Failed to match this instruction:
(parallel [
(set (reg:SI 134)
(ne:SI (reg:CC 100 cc)
(const_int 0 [0])))
(clobber (reg:CC 100 cc))
])
Successfully matched this instruction:
(set (reg:SI 134)
(ne:SI (reg:CC 100 cc)
(const_int 0 [0])))
(ne:SI (reg:CC 100 cc)
(const_int 0 [0]))

Hot cost: 12 (final)
allowing combination of insns 70 and 19
original costs 4 + 16 = 20
replacement cost 12
deferring deletion of insn with uid = 70.
deferring deletion of insn with uid = 9.
modifying insn i319: r134:SI=cc:CC!=0
  REG_DEAD cc:CC
deferring rescan insn with uid = 19.


I think the transformation is *almost valid*, but it lost the "clobber cc" that
was in parallel with insn 19.

Note that this happens after propagating some comparisons into their uses.
For example, this form of insn 19 is after munging together 14, 18 and 19:
(insn 14 70 16 3 (set (reg/v:SI 132 [ a ])
(plus:SI (reg:SI 131)
(const_int 1 [0x1]))) "bad.c":9 4 {*arm_addsi3}
 (expr_list:REG_DEAD (reg:SI 131)
(nil)))
(insn 18 16 19 3 (set (reg:CC 100 cc)
(compare:CC (reg/v:SI 132 [ a ])
(const_int 0 [0]))) "bad.c":10 193 {*arm_cmpsi_insn}
 (expr_list:REG_DEAD (reg/v:SI 132 [ a ])
(nil)))
(insn 19 18 21 3 (set (reg:SI 134)
(ne:SI (reg:CC 100 cc)
(const_int 0 [0]))) "bad.c":10 879 {*thumb2_mov_scc}
 (expr_list:REG_DEAD (reg:CC 100 cc)
(nil)))

Hope this helps

[Bug tree-optimization/83299] result of pointer addition can be assumed to be less than or equal to PTRDIFF_MAX

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Yes, I know the POINTER_PLUS operand is represented as sizetype.  But since
(when) we know the operand comes from an unsigned expression as in the test
case I'm wondering if that information could be used to constrain the
POINTER_PLUS operand (or other expressions derived from it) to just the
non-negetive subrange.

The pointer arithmetic in the test case isn't eliminated until cddce1.  There
the IL looks like this:

f (char * p, size_t i)
{
  char * q;
  long int _1;
  signed long _7;

   :
  q_4 = p_2(D) + i_3(D);
  _7 = (signed long) i_3(D);
  _1 = -_7;
  if (_7 > 0)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  return;
}

Since i_3(D) is unsigned it must not be greater than PTRDIFF_MAX, which means
that -(signed long) i_3(D) cannot be strictly positive.

[Bug tree-optimization/82646] bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Dec  6 17:59:01 2017
New Revision: 255448

URL: https://gcc.gnu.org/viewcvs?rev=255448=gcc=rev
Log:
PR tree-optimization/82646 - bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2
on strncpy with range to a member array

gcc/ChangeLog:

PR tree-optimization/82646
* builtins.c (maybe_emit_chk_warning): Use size as the bound for
strncpy, not maxlen.

gcc/testsuite/ChangeLog:

PR tree-optimization/82646
* gcc.dg/builtin-stringop-chk-1.c: Adjust.
* gcc.dg/builtin-stringop-chk-9.c: New test.
* g++.dg/ext/strncpy-chk1.C: Adjust.


Added:
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/strncpy-chk1.C
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c

[Bug tree-optimization/82646] bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed in r255448.

[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

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

--- Comment #5 from Martin Sebor  ---
Fixed.

[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

--- Comment #4 from Martin Sebor  ---
Fixed in r255446.

[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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Dec  6 17:47:45 2017
New Revision: 255446

URL: https://gcc.gnu.org/viewcvs?rev=255446=gcc=rev
Log:
PR tree-optimization/83075 - Invalid strncpy optimization

gcc/ChangeLog:

PR tree-optimization/83075
* tree-ssa-strlen.c (handle_builtin_stxncpy): Avoid assuming
strncat/strncpy don't change length of source string.

gcc/testsuite/ChangeLog:

PR tree-optimization/83075
* gcc.dg/tree-ssa/strncat.c: New test.
* gcc.dg/tree-ssa/strncpy-2.c: Same.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/strncat.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/strncpy-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/80641] [7/8 Regression] Warning with std::vector resize in loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
This warning will also disappear if we apply the vector patch submitted for bug
83229 (https://gcc.gnu.org/ml/libstdc++/2017-12/msg00023.html).

[Bug middle-end/41455] memcpy not tail called if it's a struct assignment

[jakub at gcc dot gnu.org]

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

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 42803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42803=edit
gcc8-pr41445.patch

Untested fix.

[Bug c++/64867] warning for passing non-POD to varargs function

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
No, because it doesn't have any tests.

It should probably adjust:

../gcc/testsuite/g++.dg/overload/ellipsis1.C
../gcc/testsuite/g++.dg/overload/ellipsis2.C
../gcc/testsuite/g++.old-deja/g++.pt/vaarg3.C

to use the new flag, and add a test that the new flag is enabled by
-Wconditionally-supported

[Bug tree-optimization/83298] [8 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
I see what's going on here.  I'm a bit concerned there's a deeper issue.  Some
planned gcc-9 work would take care of this, but I was hoping to avoid those
changes in the gcc-8 cycle.  Investigating the deeper concerns and alternate
(less intrusive) fixes.

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[law at redhat dot com]

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

--- Comment #15 from Jeffrey A. Law  ---
Yea, I just looked and it's somewhat painful to do because of how threading
works.  We walk statements forward and stop when we hit the limit.  But DCE
analysis is easier to formulate as a backwards walk.

We could probably pre-compute it at the start of pass as the property we're
looking for is most likely unchanged within the pass.  That would allow us to
query it during the forward walk through the block.   In fact, I think if we do
that, we don't have to keep the STMT_COUNT stuff at all.  We pre-compute the
cost of the copying the block.  If it's too large, we mark the block as not
copyable for jump threading.  Then we just query that property rather than
counting statements within block processing.

I'd almost prefer to defer that until gcc-9.

I think we probably could twiddle record_temporary_equivalences_from_phis to
not bump STMT_COUNT for a 2 argument PHI to address this BZ in the immediate
term.

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[aoliva at gcc dot gnu.org]

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

--- Comment #14 from Alexandre Oliva  ---
Created attachment 42802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42802=edit
patch, second try (following backlinks from dead uses to maybe-dead defs)

Here's an alternate patch that gets us the same generated code, but using a
different approach to determine dead stmts (that I described in my previous
comment): by following backlinks from uses found to be dead, to defs that may
also be dead.  A worklist of size 4 was enough to build nearly all of the
target libraries, much smaller than I'd anticipated.  This, and the extra work
I put into deciding when to record (and remove) information about a SSA_NAME in
the hash_map, and the reduced work to determine dead nodes, makes me confident
that this approach is superior.  I'm yet to regstrap it, though.

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #4)
> With r255384 combine manages to do many more combinations.  Without it, it
> can get rid of most of the loop body (which should have been optimised
> away in gimple already really).
> 
> I don't see how it would abort, but I find that "it" stuff really hard
> to read, so I might be missing something.

Sorry, some commentary on the code from me would have been in order...
The "it" stuff can be ignored, it's just a way of prefixing a conditional
instruction. So
it  eq
moveq   r1, #0

is really just a moveq r1, #0 where moveq is a conditional 'mov' with 'eq' as
the condition code.

One of the conditional jumps to L22 would have to have been taken in order to
abort. I haven't looked at the compiler dumps yet to figure out what's going
on...

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
With r255384 combine manages to do many more combinations.  Without it, it
can get rid of most of the loop body (which should have been optimised
away in gimple already really).

I don't see how it would abort, but I find that "it" stuff really hard
to read, so I might be missing something.

[Bug c++/64867] warning for passing non-POD to varargs function

[egallager at gcc dot gnu.org]

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

--- Comment #20 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #17)
> This adds -Wnon-pod-varargs, enabled by -Wconditionally-supported, allowing
> e.g.
> -Wconditionally-supported -Werror=non-pod-varargs
> 
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 3435fe90cca..b6ac29cda64 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -714,6 +714,10 @@ Wnamespaces
>  C++ ObjC++ Var(warn_namespaces) Warning
>  Warn on namespace definition.
>  
> +Wnon-pod-varargs
> +C++ ObjC++ Var(warn_non_pod_varargs) Warning LangEnabledBy(C++
> ObjC++,Wconditionally-supported)
> +Warn if passing a non-POD object through the \"...\" of a varargs function.
> +
>  Wpacked-not-aligned
>  C ObjC C++ ObjC++ Var(warn_packed_not_aligned) Warning LangEnabledBy(C ObjC
> C++ ObjC++,Wall)
>  Warn when fields in a struct with the packed attribute are misaligned.
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index 9e4a5c1b9ae..fc9f74f5968 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -7164,10 +7164,12 @@ convert_arg_to_ellipsis (tree arg, tsubst_flags_t
> complain)
>   || TYPE_HAS_NONTRIVIAL_DESTRUCTOR (arg_type)))
> {
>   if (complain & tf_warning)
> -   warning (OPT_Wconditionally_supported,
> -"passing objects of non-trivially-copyable "
> -"type %q#T through %<...%> is conditionally supported",
> -arg_type);
> +   {
> + warning (OPT_Wnon_pod_varargs,
> +  "passing objects of non-trivially-copyable "
> +  "type %q#T through %<...%> is conditionally
> supported",
> +  arg_type);
> +   }
>   return cp_build_addr_expr (arg, complain);
> }
>  }

Has this patch been posted to the gcc-patches mailing list yet?

[Bug c++/79228] 'i' suffix for __complex__ extension interferes with C++14 UDLs for std::complex

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #4)
> Incidentally, why doesn't complex have a constructor from __complex T?

I guess because the primary template doesn't store a __complex T, but two
separate T members (which isn't a techncial obstacle, but might be the reason
anyway).

The float, double, and long double specializations do have that constructor.

[Bug tree-optimization/83253] -ftree-slsr causes performance regression

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Perhaps slsr should then if it is considering
Y = B + (i' * S)
X = B + (i * S)
to
Y = B + (i' * S)
X = Y + (i - i') * S
and if i and i' are INTEGER_CSTs call choose_mult_variant on both
i and (i - i') and see which one is more expensive (of course, even before that
with the check that power of 2 multiplication is always faster than anything
else, as expand_mult uses that unconditionally).

[Bug target/70216] [SH] Implement __builtin_trap

[joseph at codesourcery dot com]

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

--- Comment #31 from joseph at codesourcery dot com  ---
On Wed, 6 Dec 2017, glaubitz at physik dot fu-berlin.de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
> 
> --- Comment #30 from John Paul Adrian Glaubitz  fu-berlin.de> ---
> (In reply to jos...@codesourcery.com from comment #29)
> > I don't see the issue building glibc with build-many-glibcs.py any more, 
> > hence it no longer uses -fno-isolate-erroneous-paths-dereference 
> > -fno-isolate-erroneous-paths-attribute for SH.
> 
> Is this particular patch part of glibc_2.25?

No, d40dbe7 is first in 2.26.

[Bug target/70216] [SH] Implement __builtin_trap

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #30 from John Paul Adrian Glaubitz  ---
(In reply to jos...@codesourcery.com from comment #29)
> I don't see the issue building glibc with build-many-glibcs.py any more, 
> hence it no longer uses -fno-isolate-erroneous-paths-dereference 
> -fno-isolate-erroneous-paths-attribute for SH.

Is this particular patch part of glibc_2.25?

We still need the __builtin_trap() for the kernel in any case which is why the
issue was recently brought up again. Without the patch, it's not possible to
build the kernel with gcc-7.

[Bug target/70216] [SH] Implement __builtin_trap

[joseph at codesourcery dot com]

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

--- Comment #29 from joseph at codesourcery dot com  ---
I don't see the issue building glibc with build-many-glibcs.py any more, 
hence it no longer uses -fno-isolate-erroneous-paths-dereference 
-fno-isolate-erroneous-paths-attribute for SH.

commit c89721e25d609ec4f3366a3956b2f3e5acd76e77
Author: Adhemerval Zanella 
Date:   Mon Mar 13 08:04:22 2017 -0300

build-many-glibcs: Remove no_isolate from SH config

Now with d40dbe7 SH build does not require more the no_isolate gcc
options to correct build glibc (since SH build now does not generate
a trap anymore).  This patch removes the unrequired options from
SH config.

Checked with a build for sh3-linux-gnu, sh3eb-linux-gnu, sh4-linux-gnu,
and sh4eb-linux-gnu.

* scripts/build-many-glibcs.py (Context.add_all_configs): Remove
no_isolate usage for SH.

[Bug libgomp/83295] libgomp complains about trying to map data that is already mapped

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This testcase is invalid in OpenMP 4.0 and 4.5, it will be valid only in the
upcoming OpenMP 5.0 which isn't supported yet.

The bug is that because there is no explicit mapping or data sharing clause on
the #pragma omp target construct and c is used in the region, it implies
map(to:c) and so asks mapping 1024*sizeof (int) bytes when the previous target
enter data directive only mapped 768*sizeof (int) bytes from that array.

The fix is easy, just add map(to:c[0:size]) (or map(alloc:c[0:size]) or
whatever, if not using always the mapping kind is irrelevant when it is already
mapped) to the #pragma omp target construct.

OpenMP 5.0 will make this valid by saying in 2.20.6.1 map Clause section of
http://www.openmp.org/wp-content/uploads/openmp-TR6.pdf :
"If a single contiguous part of the original storage of a list item with an
implicit data-mapping attribute has corresponding storage in the device data
environment prior to a task encountering the construct associated with the
map clause, only that part of the original storage will have corresponding
storage in the device data environment as a result of the map clause."

Without this paragraph, implicit map clause is treated the same as explicit one
and there is the requirement that if it is asking for the whole array storage
and only a portion of it is mapped, then it is unspecified behavior, in gcc
runtime error.

[Bug target/83292] __builtin_apply(), __builtin_return() trigger x87 stack exception on 32-bit x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Alternatively, we could arrange for the saving of %mm0/%mm1 registers (if
TARGET_MMX) not by generic code, but through fxsave (if TARGET_FXSR), or
fnsave;frstor (otherwise), in __builtin_apply do fxrstor or frstor to get back
the %mm0/%mm1 registers if needed and after the call save the %mm0 or %st(0)
with
another fxsave or fnsave;frstor and in __builtin_return restore again with
fxrstor or frstor.

[Bug target/83292] __builtin_apply(), __builtin_return() trigger x87 stack exception on 32-bit x86

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The i?86 ABI never passes anything in %st* registers, so in theory
__builtin_apply_args could through some target hook or similar do the %mm0/%mm1
stores conditional on whether the current function has any arguments passed in
MMX registers, and store before those also a flag whether any of them were,
then
at __builtin_apply time check that flag and only conditionally load the regs.
But with the return, I don't see how it is implementable at all, we don't know
if the function __builtin_apply calls returns in %mm0 or %st(0), so we don't
know what to save.  Is there a way to query if the CPU is in MMX or 387 state? 
How do we handle functions that take %mm0/%mm1 args and returns
float/double/long double in %st(0)?
If that is not solveable, perhaps we should either declare
__builtin_{apply*,return} unsupported with MMX functions and simply ignore the
mmx registers in there say through a target hook.

[Bug middle-end/83303] [8 Regression] FAIL: g++.dg/opt/new1.C on arm-none-eabi (extra -Walloc-size-larger-than warning)

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
I saw this on arm-non-eabi, but not on arm-linux-gnueabi*.

Bisect indicates it started with r255387

[Bug target/70216] [SH] Implement __builtin_trap

[olegendo at gcc dot gnu.org]

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

--- Comment #28 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #27)
> 
> The problem is that with gcc-7 as the default compiler in Debian, this issue
> always results in glibc and the Linux kernel failing to build from source.

That's not my fault, is it?  If you want to hotfix the debian build something,
then you already have the patch and it's working for you...

I'll try to get this issue done by the end of this month.

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
hmm, I'm getting some weird behaviour.
I see the test failing in a testsuite run.
When I try to build and run the test outside the testsuite harness it doesn't
abort.

However, the generated code between trunk (which fails in the testsuite) and
trunk with r255384 reverted (which doesn't fail) differs greatly with the
options:

-O3  -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions  -mthumb -march=armv8-a -mfpu=crypto-neon-fp-armv8
-mfloat-abi=hard 

clean trunk:
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
mvn r2, #126
push{lr}
.L2:
addsr3, r2, #1
cmp r3, #129
add r2, r2, #5
bne .L2
movsr0, #0
ldr pc, [sp], #4


trunk with r255384 reverted (which fails in the testsuite):
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, lr}
mvn r3, #126
b   .L2
.L4:
mov r1, #1
it  eq
moveq   r1, #0
cmp r2, #0
it  ne
movne   r1, #0
cbnzr1, .L22
mov r1, #1
it  eq
moveq   r1, #0
addsr0, r2, #1
and r0, r1, #1
it  ne
movne   r0, #0
cbnzr0, .L22
addsr0, r3, #3
it  eq
moveq   r2, #1
it  ne
movne   r2, #0
it  eq
moveq   r2, #0
cbnzr2, .L22
addsr1, r3, #4
it  eq
moveq   r2, #1
it  ne
movne   r2, #0
it  eq
moveq   r2, #0
cbnzr2, .L22
addsr3, r3, #5
mov r2, #1
it  eq
moveq   r2, #0
it  ne
movne   r2, #0
cbnzr2, .L22
.L2:
addsr2, r3, #1
cmp r2, #129
bne .L4
movsr0, #0
pop {r3, pc}
.L22:
bl  abort

[Bug tree-optimization/83298] [8 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/70216] [SH] Implement __builtin_trap

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #27 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #26)
> What's the matter anyway?  This issue has been around for like
> 2 years and now it can't wait a week or two?

The problem is that with gcc-7 as the default compiler in Debian, this issue
always results in glibc and the Linux kernel failing to build from source.

For gcc-5 and gcc-6, it was enough to add "extra_cflags +=
-fno-delete-null-pointer-checks" for glibc, but that no longer works with gcc-7
and the glibc build will always fail. For the kernel, there is no workaround I
know of.

Sorry, I did not mean to pressure anyone.

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #8)
> 
> Should we mark this as resolved?

No, because it has not been resolved for GCC 6.

[Bug target/70216] [SH] Implement __builtin_trap

[olegendo at gcc dot gnu.org]

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

--- Comment #26 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Send it to gcc-patches@?  If it is approved, I can commit it, sure.
> 
> Ok, thanks! Will do!

Thanks, I can apply my own patch.  No worries.  But like I wrote in comment #10
and in comment #19, I would like to extend the patch.  What's the matter
anyway?  This issue has been around for like 2 years and now it can't wait a
week or two?

[Bug tree-optimization/83298] [8 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This goes wrong during dom2, before that we have:
   [local count: 161061274]:
  b.1_11 = b;
  if (b.1_11 <= 0)
goto ; [85.00%]
  else
goto ; [15.00%]

   [local count: 136902083]:

   [local count: 912680551]:
  # b.1_12 = PHI 
  # RANGE [-2147483647, 1]
  _1 = b.1_12 + 1;
  b = _1;
  b.1_2 = b;
  if (b.1_2 <= 0)
goto ; [85.00%]
  else
goto ; [15.00%]

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

   [local count: 161061274]:
  a.2_3 = a;
  c.3_4 = c;
  _5 = a.2_3 <= 0 ? c.3_4 : 0;
  if (_5 == 0)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  # USE = nonlocal null
  # CLB = nonlocal null
  __builtin_abort ();

   [local count: 160996849]:
  return 0;

and so all paths from ENTRY go through bb 4.  dom2 decides to thread this:
   [local count: 161061274]:
  b.1_11 = b;
  if (b.1_11 <= 0)
goto ; [85.00%]
  else
goto ; [15.00%]

   [local count: 912680551]:
  # b.1_12 = PHI 
  # RANGE [-2147483647, 1]
  _1 = b.1_12 + 1;
  b = _1;
  b.1_2 = _1;
  if (_1 <= 0)
goto ; [85.00%]
  else
goto ; [15.00%]

   [local count: 161061274]:
  a.2_3 = a;
  c.3_4 = c;
  _5 = a.2_3 <= 0 ? c.3_4 : 0;
  if (_5 == 0)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  # USE = nonlocal null
  # CLB = nonlocal null
  __builtin_abort ();

   [local count: 160996849]:
  return 0;

   [count: 0]:
  a.2_10 = a;
  c.3_15 = c;
  _16 = a.2_10 <= 0 ? c.3_15 : 0;
  goto ; [0.00%]

which is wrong, the ranges of b*/_1 are in no way related to the ranges of
a*/c*, so _16 isn't guaranteed to be 0.

Jeff, can you please have a look?

[Bug c++/83300] Segmentation fault with template and __attribute__((vector_size (sizeof(int) * N)));

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Completely untested patch.

[Bug c++/83300] Segmentation fault with template and __attribute__((vector_size (sizeof(int) * N)));

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This ICEs due to endless recursion:
#11 0x0091c7f4 in write_CV_qualifiers_for_type (type=) at ../../gcc/cp/mangle.c:2396
#12 0x0091a965 in write_type (type=)
at ../../gcc/cp/mangle.c:2050
#13 0x00920049 in write_expression (expr=)
at ../../gcc/cp/mangle.c:2971
#14 0x0092283a in write_expression (expr=) at
../../gcc/cp/mangle.c:3313
#15 0x00923764 in write_template_arg (node=)
at ../../gcc/cp/mangle.c:3477
#16 0x0091c7f4 in write_CV_qualifiers_for_type (type=) at ../../gcc/cp/mangle.c:2396
#17 0x0091a965 in write_type (type=)
at ../../gcc/cp/mangle.c:2050
#18 0x00920049 in write_expression (expr=)
at ../../gcc/cp/mangle.c:2971
#19 0x0092283a in write_expression (expr=) at
../../gcc/cp/mangle.c:3313
#20 0x00923764 in write_template_arg (node=)
at ../../gcc/cp/mangle.c:3477
during mangling.

[Bug target/70216] [SH] Implement __builtin_trap

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #25 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #24)
> Send it to gcc-patches@?  If it is approved, I can commit it, sure.

Ok, thanks! Will do!

[Bug target/70216] [SH] Implement __builtin_trap

[segher at gcc dot gnu.org]

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

--- Comment #24 from Segher Boessenkool  ---
Send it to gcc-patches@?  If it is approved, I can commit it, sure.

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
I do not see any differences in generated asm code between before r255384
and trunk.  Some other options are needed as well?

[Bug target/70216] [SH] Implement __builtin_trap

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #23 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #22)
> ?
> 
> Why me?  What do I have to do with this?  It's SH code, I'm not
> an SH maintainer.  /confused

I was wondering whether you could help with merging Oleg's patch from comment
#6 as Oleg said he doesn't have much time at the moment.

[Bug target/70216] [SH] Implement __builtin_trap

[segher at gcc dot gnu.org]

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

--- Comment #22 from Segher Boessenkool  ---
?

Why me?  What do I have to do with this?  It's SH code, I'm not
an SH maintainer.  /confused

[Bug gcov-profile/82614] GCOV crashes while parsing gcda file

[tulipawn at gmail dot com]

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

--- Comment #13 from PeteVine  ---
Almost certainly not related, but there's been some sort of regression in
gcov-dump from GCC 8 branch. Trying to dump any *.gcda file (ver. 8 included)
ends like this:

$ gcov-dump-8 Unified_cpp_js_src25.gcda 
Unified_cpp_js_src25.gcda:data:magic `gcda':version `504*'
Unified_cpp_js_src25.gcda:warning:current version is `A80e'
Unified_cpp_js_src25.gcda:stamp 532248120
Unified_cpp_js_src25.gcda:tag `01ba' is invalid
Unified_cpp_js_src25.gcda:01ba:3336454216:UNKNOWN

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #13 from Alexandre Oliva  ---
Created attachment 42800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42800=edit
patch, first try

This is my first cut at it.  I couldn't quite figure out how to determine
whether stmts were dead efficiently with a forward-pass (I'd have to keep track
of all potentially dead stmts, probably without knowing for sure what's dead
and what isn't till the very end), so I introduced it as a backward scan of all
copied blocks in the path, that we only perform when we reach the stmt count
limit, and that can tell right away whether each stmt is dead, so it also knows
when to stop because we're past the limit.

This indeed solves the problem reported here, but in a kind of weird way.  We
perform very different threading in earlier passes, and we end up with all the
computation in the loop entry test all the way to dse3, past even thread4. 
It's cddce3 that optimizes it out, and later we further simplify the
conditional set of t1, and its use, into a single (x1&1)!=0 (testl;je), even
better than the code we generated at 7.x.  However, the code at e.g. dom2 looks
much uglier than what we get without this patch.

One thing I haven't done, but I kind of feel might be useful, is to cache the
killed_stmts computation per block within a single pass.  I tried to cache it
in the path itself, but (unsurprisingly) then we didn't ever get any hits :-) 
Do you believe this would be worthwhile?  I gather it will have to touch a
number of passes that call into the jump threading infrastructure to reset the
cache.

Another thought that occurred to me was that, instead of scanning insns
backwards, I could start at the final control-flow stmt, and just follow the
links from uses to defs.  It seems like this could avoid the linear scan, but
it would require a bit more complexity and additional memory than the hash_map
I'm using; I can see it working efficiently with one hash_map mapping SSA_NAMEs
to remaining uses within the block, and one vector or bitmap to hold dead defs
pending back-propagation to their uses.  It feels like this could be more
efficient, but I'm hesitant because of the far more random access patterns it
would entail.  I guess I'll have to implement it and benchmark it to know for
sure...

[Bug target/80863] [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
Oops, I didn't mean to add Segher to this PR, but PR/70216.

[Bug target/70216] [SH] Implement __builtin_trap

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #21 from John Paul Adrian Glaubitz  ---
Maybe Segher could extende Oleg's patch and merge it?

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
So this is likely dup of PR80693.

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
This particular bug does no longer reproduce with gcc-7_7.2.0, the package
builds fine with gcc-7:

gcc-6:

> https://buildd.debian.org/status/fetch.php?pkg=totem-pl-parser=sh4=3.10.8-3=1500830087=0

gcc-7:

> https://buildd.debian.org/status/fetch.php?pkg=totem-pl-parser=sh4=3.10.8-3=1505470413=0

In both cases, the package is totem-pl-parser_3.10.8-3.

Should we mark this as resolved?

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
Let me know if any other input is necessary from my side.

[Bug target/80863] [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
Current gcc-8 pre-release versions don't show this bug anymore and gcc-8 builds
fine on Debian sh4:

> https://buildd.debian.org/status/logs.php?pkg=gcc-8=sh4

The gcc-snapshot version still has this issue though:

> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=sh4=20170823-1=1503734911=0
> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=sh4=20170830-1=1504517630=0
> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=sh4=20170910-1=1505152481=0

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
In my testing, it appears only when generating thumb code (so when GCC is
configured --with-mode thumb, or when adding -mthumb to RUNTESTFLAGS)

[Bug rtl-optimization/83304] [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||7.2.0
   Target Milestone|--- |8.0
  Known to fail||8.0

[Bug rtl-optimization/83304] New: [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

[ktkachov at gcc dot gnu.org]

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

Bug ID: 83304
   Summary: [8 Regression] FAIL: gcc.c-torture/execute/pr61725.c
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
Target: arm

I see the above test fail on arm-none-linux-gnueabihf. Bisection showed it
started with r255384

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #11)
> (In reply to Richard Biener from comment #10)
> > There's nothing wrong with the GIMPLE (looked at aarch64) so it must be some
> > other RTL optimization issue.
> > 
> > aarch64 assembler is
> > 
> > foo:
> > adrpx1, .LANCHOR0
> > ldr w1, [x1, #:lo12:.LANCHOR0]
> > orr w0, w1, w0
> > ret
> > 
> > that looks indeed bogus (just does return v | x;?)
> 
> Indeed, bisection points to the combine.c commit at r255384

Err, sorry. That was meant for another bug, I confused my PRs. Please ignore
the above comment.

[Bug libgomp/66756] libgfortran: ThreadSanitizer: lock-order-inversion

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
I tried configuring GCC with --enable-linux-futex=no, but that did not really
solve the problem for me.

Maybe I'm using that flag in a wrong way?

[Bug target/80101] ICE in store_data_bypass_p, at recog.c:3737

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Note, the patch has been committed to trunk and backported to 6.x, but not 7.x
in between those.

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #10)
> There's nothing wrong with the GIMPLE (looked at aarch64) so it must be some
> other RTL optimization issue.
> 
> aarch64 assembler is
> 
> foo:
> adrpx1, .LANCHOR0
> ldr w1, [x1, #:lo12:.LANCHOR0]
> orr w0, w1, w0
> ret
> 
> that looks indeed bogus (just does return v | x;?)

Indeed, bisection points to the combine.c commit at r255384

[Bug tree-optimization/83293] [8 regression] ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:278

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 42799 [details]
> gcc8-pr83293.patch
> 
> Untested fix.  The gsi is unused afterwards, but we don't have a
> GSI_DONT_CARE
> and GSI_SAME_STMT is invalid if the bb was empty and we gsi_insert_after
> with GSI_SAME_STMT.  Another possibility would be to change
> if (!gsi_end_p (gsi) && stmt_ends_bb_p (gsi_stmt (gsi)))
> to
> if (gsi_end_p (gsi) || stmt_ends_bb_p (gsi_stmt (gsi)))

Looks good.

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
Summary|[6/7 Regression] wrong code |[6/7/8 Regression] wrong
   |with -O -fno-tree-bit-ccp   |code with -O
   |-fno-tree-coalesce-vars |-fno-tree-bit-ccp
   |-fno-tree-vrp   |-fno-tree-coalesce-vars
   ||-fno-tree-vrp

--- Comment #10 from Richard Biener  ---
There's nothing wrong with the GIMPLE (looked at aarch64) so it must be some
other RTL optimization issue.

aarch64 assembler is

foo:
adrpx1, .LANCHOR0
ldr w1, [x1, #:lo12:.LANCHOR0]
orr w0, w1, w0
ret

that looks indeed bogus (just does return v | x;?)

[Bug middle-end/81876] [7 Regression] bogus -Wstrict-overflow warning with -O3

[bunk at stusta dot de]

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

--- Comment #6 from Adrian Bunk  ---
(In reply to Jeffrey A. Law from comment #4)
> WRT locations/diagnostics for things like ldist where GCC conjures up code
> that has little resemblance to what the user wrote.  It's a real issue once
> we issue the warning -- the user has no clue what it meant.
> 
> On the other hand those warnings (particularly those that result from ldist)
> are highlighting real issues.  Bogus user code, poor optimization, even
> under-specified language from ISO.  Examples of all can be found in BZ.

If in doubt, don't issue any warning to the user.

As far as I am aware, the testcase in this bug does not warrant any warning in
that line - even "comparison is always true" would be wrong.

If a warning option sometimes generates bogus warnings for issues not present
in the code, the only reasonable option for a user would be to always disable
this warning.

[Bug middle-end/81876] [7 Regression] bogus -Wstrict-overflow warning with -O3

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 5 Dec 2017, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876
> 
> --- Comment #4 from Jeffrey A. Law  ---
> Richi.
> 
> I do worry about cases where we exploit strict-overflow semantics.  It'd be
> nice to be able to warn about them, but I certainly agree that stability is a
> problem.

The main issue with this warning is that it warns about perfectly valid
code...  IMHO warning about simplifying a_1 + 1 > a_1 is not about
strict-overflow but is in the "comparison is always true" class.  But
suggesting that there's a overflow issue in the code is misleading.

> On the other hand those warnings (particularly those that result from ldist)
> are highlighting real issues.  Bogus user code, poor optimization, even
> under-specified language from ISO.  Examples of all can be found in BZ.

Well...  see above.  Optimization is never perfect and passes doing
code-generation do rely on followup passes to optimize things.

[Bug ipa/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 #8 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #7)
> Martin J., any progress on this?

Unfortunately not yet, seems to always be number four on my todo-list.
At the moment I hope to get to it just before Christmas or just after
them (of course, I will not obbject to someone taking over but it
should not be necessary).

[Bug rtl-optimization/81020] [6/7 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu,
   ||aarch64
 CC||ktkachov at gcc dot gnu.org

--- Comment #9 from ktkachov at gcc dot gnu.org ---
FWIW this test fails currently on aarch64

[Bug libgomp/66756] libgfortran: ThreadSanitizer: lock-order-inversion

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #14)
> Following the discussion at
> 
> https://gcc.gnu.org/ml/fortran/2017-10/msg2.html
> 
> all the false positives go away if --enable-linux-futex=no
> is specified during compilation

Is this equivalent to --disable-linux-futex? Why are these flags not documented
at https://gcc.gnu.org/install/configure.html?

[Bug c++/66099] _Pragma diagnostic 'ignored' in macro with strict-overflow not suppressing warning fully with -Werror

[l.lunak at centrum dot cz]

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

Luboš Luňák  changed:

   What|Removed |Added

 CC||l.lunak at centrum dot cz

--- Comment #3 from Luboš Luňák  ---
I've noticed that using -save-temps also avoids the bug (I've run into a
similar problem).

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
Thanks for the patch.

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Dec  6 09:42:57 2017
New Revision: 255441

URL: https://gcc.gnu.org/viewcvs?rev=255441=gcc=rev
Log:
PR ada/66205
* bindgen.adb (Gen_AdaFinal): If the restriction No_Task_Termination is
set, generate a null body.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/bindgen.adb