[Bug lto/82757] New: [8 regression] plugin needed to handle lto object

[trippels at gcc dot gnu.org]

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

Bug ID: 82757
   Summary: [8 regression] plugin needed to handle lto object
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

ld.gold warns when using -flto -g:

markus@x4 ~ % echo "int main(){}" | gcc -fuse-ld=bfd  -g -flto -x c -
markus@x4 ~ % echo "int main(){}" | gcc -fuse-ld=gold -g -flto -x c -
/tmp/ccRPpSUedebugobj: plugin needed to handle lto object

[Bug c++/82756] New: Poor error message from control flow at global scope

[david at doublewise dot net]

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

Bug ID: 82756
   Summary: Poor error message from control flow at global scope
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at doublewise dot net
  Target Milestone: ---

If you compile the following code:


while(true) {}


You get the not especially helpful error message:

:1:1: error: expected unqualified-id before 'while'
 while(true) {}
 ^


This came up for me in the context of calling a macro that wrapped a few
statements in a `do { ... } while(false);` construct, and I spend a fair amount
of time looking for a missing semicolon somewhere before I finally found the
problem. I would have preferred to get a message along the lines of "while
loops not allowed outside of functions" or something else that directly says
the problem from the user's perspective.

[Bug fortran/82173] [meta-bug] Parameterized derived type errors

[kargl at gcc dot gnu.org]

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

Bug 82620 Summary: [PDT] ICE: free_expr0(): Bad expr type (at 
fortran/expr.c:497)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82620

   What|Removed |Added

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

[Bug fortran/82620] [PDT] ICE: free_expr0(): Bad expr type (at fortran/expr.c:497)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Not a regression.  Closing.

[Bug fortran/82620] [PDT] ICE: free_expr0(): Bad expr type (at fortran/expr.c:497)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Oct 28 01:06:18 2017
New Revision: 254193

URL: https://gcc.gnu.org/viewcvs?rev=254193=gcc=rev
Log:
2017-10-27  Steven G. Kargl  

PR fortran/82620
* match.c (gfc_match_allocate): Exit early on syntax error.

2017-10-27  Steven G. Kargl  

PR fortran/82620
* gfortran.dg/allocate_error_7.f90: new test.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_error_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82755] New: Misleading error message "incompatible type for argument"

[Keith.S.Thompson at gmail dot com]

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

Bug ID: 82755
   Summary: Misleading error message "incompatible type for
argument"
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

I'm using gcc 7.2.0-8ubuntu3 on Ubuntu 17.10, x86_64.

$ cat c.c
void f(double a) { }

int main(void) {
int i;
f();
}
$ gcc -c -std=c11 -pedantic c.c
c.c: In function ‘main’:
c.c:5:7: error: incompatible type for argument 1 of ‘f’
 f();
   ^
c.c:1:6: note: expected ‘double’ but argument is of type ‘int *’
 void f(double a) { }
  ^

The problem is the phrase "incompatible type" in the error message. It's true
that the types int* and double are incompatible, but that's not why the call
is invalid. Types int and double are also incompatible (as the C standard
defines the term), but the call
f(42);
would be valid.

I suggest changing "incompatible type" to "incorrect type".

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #13 from Segher Boessenkool  ---
I have a simpler patch.  It is testing...

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[sje at gcc dot gnu.org]

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

--- Comment #12 from Steve Ellcey  ---
Created attachment 42491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42491=edit
Patch that fixes the test case

Here is a possible patch.  It fixes the test case and I am doing a bootstrap
and make check on it.

[Bug c++/82218] [C++1x] constexpr on static member function causes segfault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Fixed in 7.1.0. I added a version of Jakub's testcase not using includes.

[Bug c++/82218] [C++1x] constexpr on static member function causes segfault

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Oct 27 23:14:43 2017
New Revision: 254189

URL: https://gcc.gnu.org/viewcvs?rev=254189=gcc=rev
Log:
2017-10-27  Paolo Carlini  

PR c++/82218
* g++.dg/cpp1y/constexpr-82218.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-82218.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug driver/82754] -m32 -B doesn't work with crtn.o

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
GCC first looks for crt files under ./32.  It checks ./ only if the installed
crt files don't exist.

[Bug driver/82754] -m32 -B doesn't work with crtn.o

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
crt1.o and crti.o have the same issue.

[Bug driver/82754] New: -m32 -B doesn't work with crtn.o

[hjl.tools at gmail dot com]

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

Bug ID: 82754
   Summary: -m32 -B doesn't work with crtn.o
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
  Host: x86_64
Target: i386

[hjl@gnu-6 tmp]$ cat foo.c
#include 

int
main ()
{
  printf ("hello\n");
  return 0;
}
[hjl@gnu-6 tmp]$ /usr/gcc-8.0.0-x32/bin/gcc -c foo.c
[hjl@gnu-6 tmp]$ cp /lib64/crtn.o .
[hjl@gnu-6 tmp]$ /usr/gcc-8.0.0-x32/bin/gcc -v -B./ foo.o
Using built-in specs.
COLLECT_GCC=/usr/gcc-8.0.0-x32/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/gnu/import/git/sources/gcc/configure
--with-demangler-in-ld --enable-languages=c,c++,fortran,lto,objc,ada,obj-c++,go
--prefix=/usr/gcc-8.0.0-x32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-libmpx --with-multilib-list=m32,m64,mx32 --enable-linker-build-id
--enable-gnu-unique-object --with-fpmath=sse : (reconfigured)
/export/gnu/import/git/sources/gcc/configure --with-demangler-in-ld
--enable-languages=c,c++,fortran,lto,objc,ada,obj-c++,go
--prefix=/usr/gcc-8.0.0-x32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-libmpx --with-multilib-list=m32,m64,mx32 --enable-linker-build-id
--enable-gnu-unique-object --with-fpmath=sse : (reconfigured)
/export/gnu/import/git/sources/gcc/configure --with-demangler-in-ld
--enable-languages=c,c++,fortran,lto,objc,ada,obj-c++,go
--prefix=/usr/gcc-8.0.0-x32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-libmpx --with-multilib-list=m32,m64,mx32 --enable-linker-build-id
--enable-gnu-unique-object --with-fpmath=sse
Thread model: posix
gcc version 8.0.0 20171024 (experimental) (GCC) 
COMPILER_PATH=./:/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/:/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/:/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/:/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/:/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=./:/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/:/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-B' './' '-mtune=generic' '-march=x86-64'
 /usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/collect2 -plugin
/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/liblto_plugin.so
-plugin-opt=/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccyafVxV.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/lib/../lib64/crt1.o /lib/../lib64/crti.o
/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/crtbegin.o -L.
-L/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0
-L/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../.. foo.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/gcc-8.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.0/crtend.o ./crtn.o
COLLECT_GCC_OPTIONS='-v' '-B' './' '-mtune=generic' '-march=x86-64'
[hjl@gnu-6 tmp]$ 

./crtn.o is used.  But with -m32:


[hjl@gnu-6 tmp]$ /usr/gcc-8.0.0-x32/bin/gcc -c foo.c -m32
[hjl@gnu-6 tmp]$ cp /lib/crtn.o .
[hjl@gnu-6 tmp]$ /usr/gcc-8.0.0-x32/bin/gcc -v -B./ foo.o -m32
Using built-in specs.
COLLECT_GCC=/usr/gcc-8.0.0-x32/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc-8.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/gnu/import/git/sources/gcc/configure
--with-demangler-in-ld --enable-languages=c,c++,fortran,lto,objc,ada,obj-c++,go
--prefix=/usr/gcc-8.0.0-x32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-libmpx --with-multilib-list=m32,m64,mx32 --enable-linker-build-id
--enable-gnu-unique-object --with-fpmath=sse : (reconfigured)
/export/gnu/import/git/sources/gcc/configure --with-demangler-in-ld
--enable-languages=c,c++,fortran,lto,objc,ada,obj-c++,go
--prefix=/usr/gcc-8.0.0-x32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-libmpx --with-multilib-list=m32,m64,mx32 --enable-linker-build-id
--enable-gnu-unique-object --with-fpmath=sse : 

[Bug target/82268] [8 regression] i386/pr82196-1.c fail

[dansan at gcc dot gnu.org]

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

--- Comment #5 from dansan at gcc dot gnu.org ---
Author: dansan
Date: Fri Oct 27 22:15:32 2017
New Revision: 254186

URL: https://gcc.gnu.org/viewcvs?rev=254186=gcc=rev
Log:
PR target/82268 Correct FAIL when configured --with-cpu

* gcc.target/i386/pr82196-1.c (dg-options): Add -mno-avx.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr82196-1.c

[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to helge from comment #4)
> (In reply to Jonathan Wakely from comment #2)
> > Narrowing conversions only cause a diagnostic in braced-init-list, not in
> > other contexts. This is how C++ has worked since day one.
> 
> I must admit that I'm no compiler expert, nor do I have any deep knowledge
> of the standard.  However, I think you must be mistaken here.

I assure you that "narrowing conversion" is a new term introduced by C++11, in
the context of list initialization.

Like C, C++ has always allowed implicit conversions that lose precision. They
are only disallowed inside a braced-init-list, because C++11 introduced that
that as a new form of initialization that doesn't affect historical code (well,
most historical code, except for aggregate initialization).

-Wsystem-headers will give you -Wconversion warnings for the code inside
:

/usr/include/c++/7/bits/unique_ptr.h:825:30: warning: conversion to ‘unsigned
char’ from ‘unsigned int’ may alter its value [-Wconversion]
 { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
  ^

This is the same issue as PR 58876, namely that the problem happens inside a
system header, so the diagnostics are suppressed by default. It has nothing to
do with perfect forwarding or std::forward.

[Bug target/82674] ICE with -fstack-clash-protection

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
True that 64k may be interesting because of pagesize considerations.  But I'm
not sure how to make it work reliably on ppc because I'm not aware of another
scratch register we can use if we have that large of a probing interval.

[Bug c++/82159] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 20:35:06 2017
New Revision: 254181

URL: https://gcc.gnu.org/viewcvs?rev=254181=gcc=rev
Log:
Backported from mainline
2017-10-12  Jakub Jelinek  

PR c++/82159
* expr.c (store_field): Don't optimize away bitsize == 0 store
from CALL_EXPR with addressable return type.

* g++.dg/opt/pr82159-2.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/opt/pr82159-2.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/82373] syntax error in error message

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 20:34:22 2017
New Revision: 254180

URL: https://gcc.gnu.org/viewcvs?rev=254180=gcc=rev
Log:
Backported from mainline
2017-10-04  Jakub Jelinek  

PR c++/82373
* error.c (dump_function_decl): If show_return, call dump_type_suffix
on the same return type dump_type_prefix has been called on.

* g++.dg/cpp1y/pr82373.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/pr82373.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/error.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 20:33:35 2017
New Revision: 254179

URL: https://gcc.gnu.org/viewcvs?rev=254179=gcc=rev
Log:
Backported from mainline
2017-09-21  Jakub Jelinek  

PR sanitizer/81715
* tree-inline.c (expand_call_inline): Emit clobber stmts for
VAR_DECLs to which addressable non-volatile parameters are mapped
and for id->retvar after the return value assignment, though
for -fsanitize=kernel-address only.  Clear id->retval and id->retbnd
after inlining.

* g++.dg/asan/pr81715.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/asan/pr81715.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-inline.c

[Bug c/82234] __builtin_shuffle is not in the keyword index

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 20:32:47 2017
New Revision: 254178

URL: https://gcc.gnu.org/viewcvs?rev=254178=gcc=rev
Log:
Backported from mainline
2017-09-18  Jakub Jelinek  

PR c/82234
* doc/extend.texi: Add @findex entry for __builtin_shuffle.

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

[Bug rtl-optimization/82192] [6/7 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 20:32:21 2017
New Revision: 254177

URL: https://gcc.gnu.org/viewcvs?rev=254177=gcc=rev
Log:
Backported from mainline
2017-09-15  Jakub Jelinek  

PR rtl-optimization/82192
* combine.c (make_extraction): Don't look through non-paradoxical
SUBREGs or TRUNCATE if pos + len is or might be bigger than
inner's mode.

* gcc.c-torture/execute/pr82192.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/pr82192.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82753] (PDT) Invalid error for generic interface with different KIND parameter values

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

[helge at penne dot no]

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

--- Comment #4 from helge at penne dot no ---
(In reply to Jonathan Wakely from comment #2)
> Narrowing conversions only cause a diagnostic in braced-init-list, not in
> other contexts. This is how C++ has worked since day one.

I must admit that I'm no compiler expert, nor do I have any deep knowledge of
the standard.  However, I think you must be mistaken here.

Try compiling the example I provided (with the command line options that I
specified).  If you compile it as-is it will pass, but if you remove the
comment to enable the last line (the one using unique_ptr instead of
make_unique) then it will issue a warning.  That line is not using
braced-init-list.

Btw. that line should probably ideally not have used auto and assignment, but
that should not affect the issue here.

The compiler will also correctly issue warnings about narrowing conversions on
assignment from a "wide" to a "narrow" integer type, including when the signs
don't match.  It will also warn when narrowing happens when passing parameters
to functions.

In fact, when enabled it warns about just about any narrowing conversion of
ints that I can think of, except those involving std::forward, hence the bug
report.

Please also have a look a the link I provided to the discussion on the
standards forum.  I believe these people know a thing or two, and some of them
were quite horrified that narrowing in std::forward did not result in a
warning.

Best regards,
H. Penne

[Bug libfortran/81938] valgrind error message and heap-buffer-overflow on address sanitized libgfortran.so

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
I think this can be closed now.

[Bug libfortran/81938] valgrind error message and heap-buffer-overflow on address sanitized libgfortran.so

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Oct 27 18:51:35 2017
New Revision: 254169

URL: https://gcc.gnu.org/viewcvs?rev=254169=gcc=rev
Log:
2017-10-27  Jerry DeLisle  
Rimvydas (RJ)

Backport from trunk
PR libgfortran/81938
io/format.c (free_format_data): Don't try to free vlist
descriptors past the end of the fnode array.

Modified:
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/format.c

[Bug target/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Uroš Bizjak  ---
Fixed.

[Bug target/82674] ICE with -fstack-clash-protection

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Yeah.  The only problem is 64kB is actually an interesting case to
support, since that is the page size on modern systems :-(

[Bug target/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[uros at gcc dot gnu.org]

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

--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Oct 27 18:13:14 2017
New Revision: 254167

URL: https://gcc.gnu.org/viewcvs?rev=254167=gcc=rev
Log:
PR target/82692
* config/i386/i386-modes.def (CCFPU): Remove definition.
* config/i386/i386.c (put_condition_mode): Remove CCFPU mode handling.
(ix86_cc_modes_compatible): Ditto.
(ix86_expand_carry_flag_compare): Ditto.
(ix86_expand_int_movcc): Ditto.
(ix86_expand_int_addcc): Ditto.
(ix86_reverse_condition): Ditto.
(ix86_unordered_fp_compare): Rename from ix86_fp_compare_mode.
Return true/false for unordered/ordered fp comparisons.
(ix86_cc_mode): Always return CCFPmode for float mode comparisons.
(ix86_prepare_fp_compare_args): Update for rename.
(ix86_expand_fp_compare): Update for rename.  Generate unordered
compare RTXes wrapped with UNSPEC_NOTRAP unspec.
(ix86_expand_sse_compare_and_jump): Ditto.
* config/i386/predicates.md (fcmov_comparison_operator):
Remove CCFPU mode handling.
(ix86_comparison_operator): Ditto.
(ix86_carry_flag_operator): Ditto.
* config/i386/i386.md (UNSPEC_NOTRAP): New unspec.
(*cmpu_i387): Wrap compare RTX with UNSPEC_NOTRAP unspec.
(*cmpu_cc_i387): Ditto.
(FPCMP): Remove mode iterator.
(unord): Remove mode attribute.
(unord_subst): New define_subst transformation
(unord): New define_subst attribute.
(unordered): Ditto.
(*cmpi): Rewrite using unord_subst transformation.
(*cmpixf_i387): Ditto.
* config/i386/sse.md (_comi): Merge
from _comi and _ucomi
using unord_subst transformation.
* config/i386/subst.md (SUBST_A): Remove CCFP and CCFPU modes.
(round_saeonly): Also handle CCFP mode.
* reg-stack.c (subst_stack_regs_pat): Handle UNSPEC_NOTRAP unspec.
Remove UNSPEC_SAHF unspec handling.

testsuite/ChangeLog:

PR target/82692
* gcc.dg/torture/pr82692.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr82692.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-modes.def
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/config/i386/sse.md
trunk/gcc/config/i386/subst.md
trunk/gcc/reg-stack.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[brycm001 at gmail dot com]

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

--- Comment #6 from Matti Bryce  ---
I have figured out more information. For some reason the build command in the
log was (erroneously) listed as -O2, but the actual trigger of the segfault is
-O3.

I am running creduce right now, but the size of the file means that it is going
to take many many hours more. However, I have uploaded the .i.cpp file and the
python3 detector script so you can easily run it if you have a more beefy
computer. The folder containing all 3 things is:

https://bitbucket.org/TheEdenCrazy/gassim/src/a01812e2f7d95e667f67d400bb9d57caad1a5709/_gcc_bug_test/?at=master

(just cp Manager.cpp.i -> Manager.cpp.i.cpp), then do

creduce ./attempt_compilation.sh Manager.cpp.i.cpp

To reduce it.

[Bug fortran/82753] New: (PDT) Invalid error for generic interface with different KIND parameter values

[pault at gcc dot gnu.org]

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

Bug ID: 82753
   Summary: (PDT) Invalid error for generic interface with
different KIND parameter values
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

As reported by FortranFan on clf:

module m
   type :: t(k)
  integer, kind :: k = 1
   contains
  procedure, pass(this) :: p1
  procedure, pass(this) :: p2
  generic :: p => p1, p2
   end type
contains
   subroutine p1( this )
  class(t(k=1)), intent(inout) :: this
   end subroutine
   subroutine p2( this )
  class(t(k=2)), intent(inout) :: this
   end subroutine
end module 

   generic :: p => p1, p2
 1
Error: 'p1' and 'p2' for GENERIC 'p' at (1) are ambiguous
C:\dev\Fortran\temp\sor\m.f90:5:15:
   procedure, pass(this) :: p1
   1
Error: Argument 'this' of 'p1' with PASS(this) at (1) must be of the
derived-type 't'
C:\dev\Fortran\temp\sor\m.f90:6:15:
   procedure, pass(this) :: p2
   1
Error: Argument 'this' of 'p2' with PASS(this) at (1) must be of the
derived-type 't'
Process terminated with status 1 (0 minute(s), 0 second(s))
3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) 

This is clearly incorrect. I am slightly surprised that this is happening,
since it should be the instances that are compared in the interface, but will
investigate asap.

Cheers

Paul

[Bug libfortran/81938] valgrind error message and heap-buffer-overflow on address sanitized libgfortran.so

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Oct 27 17:50:22 2017
New Revision: 254163

URL: https://gcc.gnu.org/viewcvs?rev=254163=gcc=rev
Log:
2017-10-27  Jerry DeLisle  
Rimvydas (RJ)

PR libgfortran/81938
io/format.c (free_format_data): Don't try to free vlist
descriptors past the end of the fnode array.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/format.c

[Bug c/82752] Support %OB, %Ob strftime formats

[zackw at panix dot com]

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

Zack Weinberg  changed:

   What|Removed |Added

 CC||zackw at panix dot com

--- Comment #1 from Zack Weinberg  ---
And in strptime, %OB, %Ob, and %Oh should be supported.

[Bug target/82674] ICE with -fstack-clash-protection

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
So while fixing the expander that allocates dynamic space is easy.  Fixing the
other cases is harder, particularly since we need another scratch.

Given it's always been expected that the probing internval might be limited by
such things, I think it's best to just error out for too-large a probing
interval.

[Bug libstdc++/82749] piecewise_linear_distribution::densities() non conformity

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 Ever confirmed|0   |1

[Bug c++/82734] -Wignored-qualifiers is maybe too strict when using decltype

[sylvestre at debian dot org]

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

--- Comment #2 from Sylvestre Ledru  ---
I could, the code would be just more complex for no gain.

Just like with bug 82711, gcc is way too careful here and the warning is just
adding noise.

[Bug c/82752] New: Support %OB, %Ob strftime formats

[jsm28 at gcc dot gnu.org]

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

Bug ID: 82752
   Summary: Support %OB, %Ob strftime formats
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

There is a POSIX proposal http://austingroupbugs.net/view.php?id=258 accepted
for issue 8 (the next major revision of POSIX, not yet in progress) for adding
a strftime %OB format (for nominative as opposed to genitive month names, in
languages where standalone months needs a different case from months used with
a day number).  This has apparently been in FreeBSD since 1999, and should soon
be going in glibc, along with corresponding %Ob (since it turns out abbreviated
months also need different cases in some languages).

GCC should support %OB and %Ob strftime formats in -Wformat (with due warning
for being extensions over ISO C with -Wformat -Wpedantic).  This will be needed
to avoid warnings for glibc tests of the new feature.

[Bug fortran/56342] MATMUL with PARAMETER: Simplification usually doesn't work

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

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

[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #2)
> Narrowing conversions only cause a diagnostic in braced-init-list, not in
> other contexts. This is how C++ has worked since day one.

I would even go so far and say: Since day zero ;-)

[Bug libstdc++/82749] piecewise_linear_distribution::densities() non conformity

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I agree, that problem still exists in the current trunk as well. For the
record, the original specification was in terms of std::vector, that
was changed with LWG 1439:

http://cplusplus.github.io/LWG/lwg-defects.html#1439

Similar to the change request by that issue, class
piecewise_constant_distribution needs a similar correction.

[Bug fortran/56342] MATMUL with PARAMETER: Simplification usually doesn't work

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Oct 27 17:11:42 2017
New Revision: 254157

URL: https://gcc.gnu.org/viewcvs?rev=254157=gcc=rev
Log:
2017-10-27  Thomas Koenig  

PR fortran/56342
* simplify.c (is_constant_array_expr): If the expression is
a parameter array, call gfc_simplify_expr.

2017-10-27  Thomas Koenig  

PR fortran/56342
* gfortran.dg/matmul_const.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/matmul_const.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82751] New: g++ 8 is breaking assert_lt (gtest) called from a lambda function

[sylvestre at debian dot org]

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

Bug ID: 82751
   Summary: g++ 8 is breaking assert_lt (gtest) called from a
lambda function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sylvestre at debian dot org
  Target Milestone: ---

Created attachment 42490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42490=edit
the ii file

With
---
#include "gtest/gtest.h"

TEST(foo, bar)
{
  const size_t kExpectedCount = 0;
  const size_t count = 0;
  auto f  = []() {
  ASSERT_LT(count, kExpectedCount);
};
}
---

$ /usr/bin/g++-7  
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include   
-fno-exceptions  TestNSPRLogModulesParser.cpp -c
$ /usr/bin/g++-8   -I/root/firefox-gcc-last/xpcom/tests/gtest
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/xpcom/tests/gtest
-I/root/firefox-gcc-last/xpcom/base
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include   
-fno-exceptions  TestNSPRLogModulesParser.cpp -c
In file included from
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/gtest/gtest.h:1874:0,
 from TestNSPRLogModulesParser.cpp:1:
TestNSPRLogModulesParser.cpp: In lambda function:
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/gtest/gtest_pred_impl.h:147:45:
error: lvalue required as unary '&' operand
   GTEST_ASSERT_(pred_format(#v1, #v2, v1, v2), \
 ^
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/gtest/gtest_pred_impl.h:77:52:
note: in definition of macro 'GTEST_ASSERT_'
   if (const ::testing::AssertionResult gtest_ar = (expression)) \
^~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/gtest/gtest_pred_impl.h:166:3:
note: in expansion of macro 'GTEST_PRED_FORMAT2_'
   GTEST_PRED_FORMAT2_(pred_format, v1, v2, GTEST_FATAL_FAILURE_)
   ^~~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/gtest/gtest.h:1946:3:
note: in expansion of macro 'ASSERT_PRED_FORMAT2'
   ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperLT, val1, val2)
   ^~~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/gtest/gtest.h:1968:32:
note: in expansion of macro 'GTEST_ASSERT_LT'
 # define ASSERT_LT(val1, val2) GTEST_ASSERT_LT(val1, val2)
^~~
TestNSPRLogModulesParser.cpp:8:7: note: in expansion of macro 'ASSERT_LT'
   ASSERT_LT(count, kExpectedCount);
   ^

[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Narrowing conversions only cause a diagnostic in braced-init-list, not in other
contexts. This is how C++ has worked since day one.

[Bug tree-optimization/82750] Incorrect code for mednafen's array copy test with -O3

[cand at gmx dot com]

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

--- Comment #2 from Lauri Kasanen  ---
Thanks, passing to mednafen devs.

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #42487|0   |1
is obsolete||

--- Comment #46 from Jakub Jelinek  ---
Created attachment 42489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42489=edit
gcc8-pr22141-improvements.patch

The previous version passed bootstrap on x86_64, i686 and powerpc64le, but
regtest on x86_64 and i686 showed another bug in the gimple-ssa-store-merging.c
changes and a testcase issue in one case.  Will bootstrap/regtest this updated
version now on all 3 again.

[Bug c++/82629] OpenMP 4.5 Target Region mangling problem

[thorstenkurth at me dot com]

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

--- Comment #4 from Thorsten Kurth  ---
Hello Richard,

Was the test case received?

Best Regards
Thorsten Kurth

[Bug tree-optimization/82750] Incorrect code for mednafen's array copy test with -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
([0][0])[i] = i;

Is undefined when i >= 5.

[Bug tree-optimization/82750] New: Incorrect code for mednafen's array copy test with -O3

[cand at gmx dot com]

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

Bug ID: 82750
   Summary: Incorrect code for mednafen's array copy test with -O3
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
  Target Milestone: ---

Mednafen's TestGCC81740 test fails with gcc 7.2 using -O3, but it works with
-O2 and -O3 -fno-tree-loop-vectorize. It also fails with gcc 5.2, but works
with gcc 4.8, so this is a regression somewhere between those two versions.

Source:
#include 
#include 

#define NO_CLONE __attribute__((noclone))
#define NO_INLINE __attribute__((noinline))

NO_INLINE NO_CLONE void TestGCC81740_Sub(int* p, unsigned count)
{
 static const int good[20] = { 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 10, 5, 6, 7, 8,
15, 10, 11, 12, 13 };

 assert(count == 20);

 for(unsigned i = 0; i < count; i++) {
 if (good[i] != p[i]) printf("got %u expected %u (%u)\n", p[i], good[i], i);
  assert(good[i] == p[i]);
  }
}

int TestGCC81740_b;

NO_INLINE NO_CLONE void TestGCC81740(void)
{
 int v[4][5] = { 0 };

 for(unsigned i = 0; i < sizeof(v) / sizeof(int); i++)
  ([0][0])[i] = i;

 for(int a = 3; a >= 0; a--)
  for(TestGCC81740_b = 0; TestGCC81740_b < 3; TestGCC81740_b++)
   v[TestGCC81740_b + 1][a + 1] = v[TestGCC81740_b][a];

 TestGCC81740_Sub([0][0], sizeof(v) / sizeof(int));
}


int main() {
  TestGCC81740();
  return 0;
}

[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from palmer at gcc dot gnu.org ---
Thanks!

[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation

[palmer at gcc dot gnu.org]

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

--- Comment #6 from palmer at gcc dot gnu.org ---
Author: palmer
Date: Fri Oct 27 15:22:43 2017
New Revision: 254153

URL: https://gcc.gnu.org/viewcvs?rev=254153=gcc=rev
Log:
RISC-V: Correct and improve the "-mabi" documentation

The documentation for the "-mabi" argument on RISC-V was incorrect.  We
chose to treat this as a documentation bug rather than a code bug, and
to make the documentation match what GCC currently does.  In the
process, I also improved the documentation a bit.

Thanks to Alex Bradbury for finding the bug!

PR target/82717: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717

gcc/ChangeLog

2017-10-27  Palmer Dabbelt  

PR target/82717
* doc/invoke.texi (RISC-V) <-mabi>: Correct and improve.

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

[Bug target/82621] [6/7/8 Regression] wrong code with -Og -fgcse -fweb

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce the wrong code natively on powerpc64-linux-gnu, with
gcc-5/6/7/8 and -m32.  With -m64 the test case works.  Also works with gcc-4.9.

[Bug target/82748] ICE with __builtin_fabsq and __float128 in copy_to_mode_reg, at explow.c:612

[gabriel at inconstante dot eti.br]

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

--- Comment #1 from Gabriel F. T. Gomes  ---
Some additional information:

Replacing __builtin_fabsq (x) with __builtin_copysignq (x, x), in the test
program, causes a similar error.

Replacing the 'q'-suffixed builtin with its 'f128'-suffixed counterpart makes
the error go away.

[Bug libstdc++/82749] New: piecewise_linear_distribution::densities() non conformity

[christophe.cous...@meso-star.com]

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

Bug ID: 82749
   Summary: piecewise_linear_distribution::densities() non
conformity
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.cous...@meso-star.com
  Target Milestone: ---

piecewise_linear_distribution::densities() should be of type vector and
is vector.

[Bug target/82748] New: ICE with __builtin_fabsq and __float128 in copy_to_mode_reg, at explow.c:612

[gabriel at inconstante dot eti.br]

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

Bug ID: 82748
   Summary: ICE with __builtin_fabsq and __float128 in
copy_to_mode_reg, at explow.c:612
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel at inconstante dot eti.br
CC: gabriel at inconstante dot eti.br,
meissner at linux dot vnet.ibm.com
  Target Milestone: ---
Target: powerpc64le-linux-gnu

The following code, when compiled with -mfloat128 -mabi=ieeelongdouble for
powerpc64le-linux-gnu, produces the following ICE.  The error message was
produce with GCC 7.  With GCC 8, it also fails and -mfloat128 is not required. 
With GCC 6 it doesn't fail.

__float128 d;

__float128
foobar (__float128 x)
{
  d = __builtin_fabsq (x);
  return d;
}

gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
test.c: In function ‘foobar’:
test.c:6:7: internal compiler error: in copy_to_mode_reg, at explow.c:612
   d = __builtin_fabsq (x);
   ^~~
0x105176af copy_to_mode_reg(machine_mode, rtx_def*)
/home/meissner/fsf-src/gcc-7-branch/gcc/explow.c:612
0x10dbacf3 rs6000_expand_unop_builtin
/home/meissner/fsf-src/gcc-7-branch/gcc/config/rs6000/rs6000.c:14628
0x10e00a93 rs6000_expand_builtin
/home/meissner/fsf-src/gcc-7-branch/gcc/config/rs6000/rs6000.c:17312
0x10383b1b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/meissner/fsf-src/gcc-7-branch/gcc/builtins.c:6368
0x10539263 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/meissner/fsf-src/gcc-7-branch/gcc/expr.c:10821
0x105483ff store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/meissner/fsf-src/gcc-7-branch/gcc/expr.c:5552
0x1054a10f expand_assignment(tree_node*, tree_node*, bool)
/home/meissner/fsf-src/gcc-7-branch/gcc/expr.c:5321
0x103b509b expand_call_stmt
/home/meissner/fsf-src/gcc-7-branch/gcc/cfgexpand.c:2656
0x103b509b expand_gimple_stmt_1
/home/meissner/fsf-src/gcc-7-branch/gcc/cfgexpand.c:3571
0x103b509b expand_gimple_stmt
/home/meissner/fsf-src/gcc-7-branch/gcc/cfgexpand.c:3737
0x103bc327 expand_gimple_basic_block
/home/meissner/fsf-src/gcc-7-branch/gcc/cfgexpand.c:5744
0x103bf467 execute
/home/meissner/fsf-src/gcc-7-branch/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 CC||meissner at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-reduction
 Status|WAITING |NEW
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #5 from Martin Liška  ---
Confirmed with cross compiler, I reduce a test-case.

[Bug c/82747] New: -Wpacked-not-aligned does not work on targets with STRICT_ALIGNMENT==1

[nsz at gcc dot gnu.org]

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

Bug ID: 82747
   Summary: -Wpacked-not-aligned does not work on targets with
STRICT_ALIGNMENT==1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

new packed-not-aligned warning introduced for bug 53037 disappears
when STRICT_ALIGNMENT==1:

+FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 6)

+FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 16)
+FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 32)
+FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 8)
+FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 16)
+FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 32)
+FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 8)


now on aarch64, -mstrict-align flag changes whether there is
a warning for

struct __attribute__ ((aligned (8))) S8 { char a[8]; };
struct __attribute__ ((packed)) S1 { struct S8 s8; };

even though the flag does not change the semantics of these
type declarations so the warning should be independent of it.
so i think the wrong constraint is checked for issuing the
warning.

same for all targets where STRICT_ALIGNMENT is defined
to 1 (arm, sparc, sh, mips, hppa,...) or may not be 0
under some conditions.

[Bug ada/82746] New: strange error on BIP function returning private type with Disable_Controlled

[demoonlit at panathenaia dot halfmoon.jp]

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

Bug ID: 82746
   Summary: strange error on BIP function returning private type
with Disable_Controlled
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demoonlit at panathenaia dot halfmoon.jp
  Target Milestone: ---

Created attachment 42488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42488=edit
bug triggering source code

The compiler outputs strange error message ("" is undefined) on a
build-in-place function returning a type derived from a private type with
Disable_Controlled => True.

Compile the attached file:

% gcc -c pkg.adb
pkg.adb:17:07: "" is undefined


   function BIP_2 return T is
   begin
  return Result : T do -- pkg.adb:17:07: "" is undefined
 null;
  end return;
   end BIP_2;

[Bug libgomp/81688] libgomp.c/target-3{3,4}.c fails: GOMP_OFFLOAD_async_run unimplemented for nvptx

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openmp, patch

--- Comment #5 from Tom de Vries  ---
patch submitted: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02079.html

[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
What I am trying to do is to have only one version of each
library routine (the one using gfc_index_kind), and then
convert to the KIND parameter that the user specified (or to
default integer if the user didn't specify anything). This would
also allow to reduce library bloat.

This works fine with the attached patch. I did not yet touch the
library, but removing the then-unneeded versions of the library
functions would be fairly trivial. We're breaking binary
compatibility anyway, so we might as well do that.

The only problem is that it causes regressions in bounds
checking - the __convert_i8_i4 function call (in case where
gfc_index_type has 8 bytes and normal integers have 4 bytes).
This is a more or less unrelated problem, and is PR82660.

Now, we could argue that the bounds violations for minloc and
maxloc are not very important, since the dimension of the
return array is the rank of the argument - in the normal
case, compile-time checking will catch the problem anyway.
We would then accept a regression in return for implementing
an (IMHO) important part of F2003 - without these KIND argumetns,
MINLOC and MAXLOC are useless for long linear arrays with > 2^31
elements.

Of course, we should also focus on PR 82660.

What do you think?

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

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Did this change help?  Would it be beneficial to backport to 7.x or even 6.x? 
As is it is certainly too dangerous, but wonder about additionally guarding the
3 hunks either with (flag_sanitize & SANITIZE_ADDRESS) != 0 or even
(flag_sanitize & SANITIZE_KERNEL_ADDRESS) != 0, so it would affect only people
using -fsanitize={,kernel-}address or even just -fsanitize=kernel-address.

[Bug objc/53943] Compiler ICE with -fobjc-direct-dispatch flag on Linux

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2017-07-27 00:00:00 |2017-10-27

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Konstantin Osipov from comment #2)
> > kostja@atlas ~ % gcc -fobjc-direct-dispatch foo.m -lobjc
> 
> You still left off the -fobjc-exceptions flag

Update: I now have access to Linux on the GCC compile farm, and can confirm
that the ICE still happens even when adding -fobjc-exceptions:

[egallager@gcc1-power7 build]$ ${HOME}/.local/bin/gcc -fobjc-direct-dispatch
-fobjc-exceptions 53943.m -lobjc
53943.m: In function ‘main’:
53943.m:14:2: internal compiler error: Segmentation fault
  @throw [Interface new];
  ^
0x1078317b crash_signal
../../gcc/toplev.c:326
0x101bd670 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc/c/c-typeck.c:3023
0x101697d3 build_objc_method_call
../../gcc/objc/objc-gnu-runtime-abi-01.c:706
0x101697d3 gnu_runtime_abi_01_build_objc_method_call
../../gcc/objc/objc-gnu-runtime-abi-01.c:741
0x10153b33 objc_finish_message_expr(tree_node*, tree_node*, tree_node*,
tree_node**)
../../gcc/objc/objc-act.c:5663
0x1015490f objc_build_message_expr(tree_node*, tree_node*)
../../gcc/objc/objc-act.c:5293
0x101f6e87 c_parser_postfix_expression
../../gcc/c/c-parser.c:8530
0x101df6eb c_parser_unary_expression
../../gcc/c/c-parser.c:7369
0x101e0623 c_parser_cast_expression
../../gcc/c/c-parser.c:7201
0x101e08db c_parser_binary_expression
../../gcc/c/c-parser.c:7007
0x101e15fb c_parser_conditional_expression
../../gcc/c/c-parser.c:6745
0x101e1c17 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6662
0x101e1f97 c_parser_expression
../../gcc/c/c-parser.c:8880
0x101f26f3 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5570
0x101f3673 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5150
0x101f3dd7 c_parser_compound_statement
../../gcc/c/c-parser.c:4983
0x101d6487 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2314
0x101fe2ab c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x101fed6f c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x101fed6f c_parse_file()
../../gcc/c/c-parser.c:18441
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[egallager@gcc1-power7 build]$ 

So, confirmed.

[Bug fortran/82743] uncaught character truncation in derived type initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0).

[Bug objc/25361] structures containing vectors are not encoded correctly

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #11 from Eric Gallager  ---
(In reply to Eric Gallager from comment #10)
> (In reply to Dominique d'Humieres from comment #9)
> > objc.dg-struct-layout-encoding-1/t026_main.m seems to pass on all platforms
> > I have looked at. The other tests pass on several platforms, except
> > Intel/AMD ones (see pr45989).
> 
> pr45989 has been closed; can this one be closed now too?

No response so I'm assuming this can be closed with the same resolution as that
one (FIXED) now too.

[Bug objc/24867] many N^2 loops in objc frontend

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Nathan Froyd from comment #5)
> > Subject: Bug 24867
> > 
> > Author: froydnj
> > Date: Sat Jul  3 19:00:52 2010
> > New Revision: 161777
> > 
> > URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=161777
> > Log:
> > PR objc/24867
> > * objc-act.c (build_sized_array_type): New function.
> > (add_objc_string): Use it.
> > (generate_protocol_list): Likewise.
> > (generate_objc_image_info): Likewise.
> > (add_field_decl): New function.
> > (objc_build_struct): Use a VEC rather than building a TREE_LIST.
> > (generate_struct_by_value_array): Use add_field_decl.
> > (build_objc_symtab_template): Likewise.
> > (build_module_descriptor): Likewise.
> > (build_objc_exception_stuff): Likewise.
> > (build_protocol_template): Likewise.
> > (build_method_prototype_list_template): Likewise.
> > (build_method_prototype_template): Likewise.
> > (build_category_template): Likewise.
> > (build_selector_template): Likewise.
> > (build_class_template): Likewise.
> > (build_super_template): Likewise.
> > (build_ivar_template): Likewise.
> > (build_ivar_list_template): Likewise.
> > (build_method_list_template): Likewise.
> > (build_method_template): Likewise.
> > 
> > Modified:
> > trunk/gcc/objc/ChangeLog
> > trunk/gcc/objc/objc-act.c
> 
> Did this fix it?

Since there's been no response, I'm going to assume that it did fix it.

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #42485|0   |1
is obsolete||

--- Comment #45 from Jakub Jelinek  ---
Created attachment 42487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42487=edit
gcc8-pr22141-improvements.patch

That patch failed to bootstrap due to undesirable -W*uninitialized warnings,
the following (still untested) should fix that.

[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

[helge at penne dot no]

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

helge at penne dot no changed:

   What|Removed |Added

Summary|Fails to warn on narrowing  |Fails to warn on narrowing
   |conversion when using   |conversion by std::forward
   |make_unique |(e.g. when calling
   ||make_unique)

--- Comment #1 from helge at penne dot no ---
Some further experiments show that the compiler also fails to detect narrowing
conversions in calls to std::vector::emplace_back and std::map::emplace.  It
seems fair to guess that anything that uses perfect forwarding and std::forward
is suspect.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #46 from Jonathan Wakely  ---
Thanks, Chris. It seems like APFS probably has a bug where the dentries for
symlinks are not flushed to disk, and so later attempts to open the file fail.

[Bug fortran/82743] uncaught character truncation in derived type initialization

[simon.kluepfel at gmail dot com]

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

--- Comment #1 from Simon Klüpfel  ---
One more thing I tested. When the default initialization is too long, it is
caught as expected.

PROGRAM TEST
TYPE A
CHARACTER(LEN=1) :: C="123"
END TYPE A
END PROGRAM TEST

gives 

main.f95:3:30:

 CHARACTER(LEN=1) :: C="123"
  1
Warning: CHARACTER expression at (1) is being truncated (3/1)
[-Wcharacter-truncation]

[Bug c++/82745] New: Fails to warn on narrowing conversion when using make_unique

[helge at penne dot no]

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

Bug ID: 82745
   Summary: Fails to warn on narrowing conversion when using
make_unique
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helge at penne dot no
  Target Milestone: ---

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

I may possibly have found a bug with some serious implications for developers
wanting to write secure code.  I would expect the attached program to produce a
compiler warning about the narrowing conversion in make_unique, but it does
not.  Compiler options were "-Wall -Wextra -Wconversion -pedantic"

Removing the comment on the line doing the equivalent construction with
unique_ptr and new will produce the expected warning.

Some digging around seems to imply that this is probably not just a problem
with make_unique, but perhaps a problem with perfect forwardning
(std::forward?) in general.  The following discussion in the standards forum
might indicate a problem in the language definition itself, but I would still
expect the compiler to warn about this:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/yt3eizKwGjI

The gcc -v options says:
GNU C++14 (GCC) version 7.1.0 (x86_64-gcc710-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version 3.1.1,
MPC version 1.0.1, isl version none

Warnings on narrowning conversions are quite important when writing secure
code, and this bug is therefore rather serious.

I could always refactor the code base to use my own variant of make_unique that
uses move semantics instead of perfect forwarding and gain security at the
expense of some runtime perfomance, but if perfect forwarding is the problem
then that is not going to be enough.

Or perhaps I have missed something.  In fact, I would prefer to be wrong rather
than right in this case.  If this is something that I can fix in my own code
then that is far preferable to the compiler or languge being broken.  

Best regards,
H. Penne

[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 12:25:34 2017
New Revision: 254146

URL: https://gcc.gnu.org/viewcvs?rev=254146=gcc=rev
Log:
PR target/82703
* config/i386/i386-protos.h (maybe_get_pool_constant): Removed.
* config/i386/i386.c (maybe_get_pool_constant): Removed.
(ix86_split_to_parts): Use avoid_constant_pool_reference instead of
maybe_get_pool_constant.
* config/i386/predicates.md (zero_extended_scalar_load_operand):
Likewise.

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

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr82703.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386-protos.h
branches/gcc-7-branch/gcc/config/i386/i386.c
branches/gcc-7-branch/gcc/config/i386/predicates.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct 27 12:20:55 2017
New Revision: 254145

URL: https://gcc.gnu.org/viewcvs?rev=254145=gcc=rev
Log:
PR target/82703
* config/i386/i386-protos.h (maybe_get_pool_constant): Removed.
* config/i386/i386.c (maybe_get_pool_constant): Removed.
(ix86_split_to_parts): Use avoid_constant_pool_reference instead of
maybe_get_pool_constant.
* config/i386/predicates.md (zero_extended_scalar_load_operand):
Likewise.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr82703.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[jakub at gcc dot gnu.org]

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

--- Comment #44 from Jakub Jelinek  ---
With the #c43 patch, the included store_merging_10.c improves on x86_64 from:
movzbl  (%rdi), %eax
-   andl$-19, %eax
+   andl$-32, %eax
orl $13, %eax
movb%al, (%rdi)
in foo and
-   orb $1, (%rdi)
movl(%rdi), %eax
-   andl$-131071, %eax
+   andl$2147352576, %eax
+   orl $1, %eax
movl%eax, (%rdi)
-   shrl$24, %eax
-   andl$127, %eax
-   movb%al, 3(%rdi)
in bar.  foo is something combine.c managed to optimize too, but bar it
couldn't.
In store_merging_11.c on x86_64, bar is the same and foo changed:
-   movabsq $578437695752115969, %rax
-   movl$0, 9(%rdi)
-   movb$0, 15(%rdi)
-   movq%rax, 1(%rdi)
-   xorl%eax, %eax
-   movw%ax, 13(%rdi)
+   movl$23, %eax
+   movb$1, 1(%rdi)
+   movl$117835012, 4(%rdi)
+   movw%ax, 2(%rdi)
+   movq$8, 8(%rdi)
which is not only shorter, but all the stores are aligned.
On ppc64le in store_merging_10.c the difference is:
-   lwz 9,0(3)
+   lbz 9,0(3)
rlwinm 9,9,0,0,26
ori 9,9,0xd
-   stw 9,0(3)
+   stb 9,0(3)
in foo and
lwz 9,0(3)
+   rlwinm 9,9,0,1,14
ori 9,9,0x1
-   rlwinm 9,9,0,31,14
-   rlwinm 9,9,0,1,31
stw 9,0(3)
in bar, and store_merging_11.c the difference is:
-   lis 8,0x807
-   li 9,0
-   ori 8,8,0x605
-   li 10,0
-   sldi 8,8,32
-   stw 9,9(3)
-   sth 9,13(3)
-   oris 8,8,0x400
-   stb 10,15(3)
-   ori 8,8,0x1701
-   mtvsrd 0,8
-   stfd 0,1(3)
+   lis 9,0x706
+   li 7,1
+   li 8,23
+   ori 9,9,0x504
+   li 10,8
+   stb 7,1(3)
+   sth 8,2(3)
+   stw 9,4(3)
+   std 10,8(3)
in foo and no changes in bar.

What the patch doesn't implement yet, but could be also possible for
allow_unaligned case is in store_merging_11.c when we are storing 15 bytes
store
8 bytes at offset 1 and 8 bytes at offset 8 (i.e. create two overlapping
stores, in this case one aligned and one unaligned).

[Bug libgomp/81688] libgomp.c/target-3{3,4}.c fails: GOMP_OFFLOAD_async_run unimplemented for nvptx

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> Created attachment 42484 [details]
> Patch that moves async_run from plugin-hsa.c to default_sync_run
> 
> I wonder if this will work.

That got me this error for target-33.c:
...
libgomp: 
libgomp: cuMemAlloc error: invalid device context
cuMemAlloc error: invalid device context

libgomp: cuCtxPushCurrent_v2 error: unknown cuda error

libgomp: device finalization failed
...

Using this patch in addition, both target-33.c and target34.c pass:
...
diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index d5262639578..4e0009f650e 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -2127,6 +2127,8 @@ GOMP_OFFLOAD_run (int ord, void *tgt_fn, void *tgt_vars,
void **args)
   const char *maybe_abort_msg = "(perhaps abort was called)";
   int teams = 0, threads = 0;

+  nvptx_attach_host_thread_to_device (ord);
+
   if (!args)
 GOMP_PLUGIN_fatal ("No target arguments provided");
   while (*args)
...

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #43 from Jakub Jelinek  ---
Created attachment 42485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42485=edit
gcc8-pr22141-improvements.patch

Untested store merging improvements, mainly written to address #c30, but also
containing various other improvements and fixes.

[Bug middle-end/82744] Better handling equivalence+common for FORTRAN

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/71385] Internal compiler error when using concept as placeholder

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed in 6.2.0.

[Bug c++/71385] Internal compiler error when using concept as placeholder

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Oct 27 10:45:25 2017
New Revision: 254139

URL: https://gcc.gnu.org/viewcvs?rev=254139=gcc=rev
Log:
2017-10-27  Paolo Carlini  

PR c++/71385
* g++.dg/concepts/pr71385.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr71385.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Alexander Cherepanov from comment #8)
> On 2017-10-27 12:41, rguenth at gcc dot gnu.org wrote:
> >> And with allocated memory (C; add placement new's for C++):
> >>
> >> --
> >> #include 
> >> #include 
> >> #include 
> >>
> >> static long test(long *px, long long *py, void *pu)
> >> {
> >>*px = 0;
> >>*py = 1;
> >>
> >>// change effective type from long long to long
> >>long tmp;
> >>memcpy(, pu, sizeof(tmp));
> >>memcpy(pu, , sizeof(tmp));
> > 
> > I believe this one is invalid - memcpy transfers the dynamic
> > type and *pu is currently 'long long'.  So it's either not
> > changing the dynamic type because, well, the type transfers
> > through 'tmp' or you are accessing 'tmp' with declared type
> > long as 'long long'.
> AIUI memcpy is always valid if there is enough space, no matter what 
> types its source and destination have. It accesses both of them as 
> arrays of chars -- C11, 7.24.1p1: "The header  declares one 
> type and several functions, and defines one  macro useful for 
> manipulating arrays of character type and other objects treated as 
> arrays of character type."
> 
> OTOH memcpy transfers effective type from the source to the destination 
> but only if the destination has no declared type -- C11, 6.5p6: "If a 
> value is copied into an object having no declared type using memcpy or 
> memmove, or is copied as an array of character type, then the effective 
> type of the modified object for that access and for subsequent accesses 
> that do not modify the value is the effective type of the object from 
> which the value is copied, if it has one."
> Placement new in C++ can change dynamic types of objects with declared 
> type but I don't think there are such facilities in C.
> 
> So in this example the first memcpy copies the value of *pu to tmp but 
> drops its effective type (long long) and the second memcpy copies the 
> value and passes the effective type of 'tmp' (long) along.

Hmm, ok.  For GCC internals the memcpy changes the dynamic type to
"anything" (it uses alias-set zero reads/writes) so for GCC internals
the testcase is valid in that the later read needs to consider the
memcpy store as aliasing.

[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
One complication when deciding whether the downstream uses are fine is
that we assign the same alias set to union accesses u->x and u->y.

That said, the union read/write pairs we remove essentially act as
an optimization barrier - they "union" the alias sets of all components
of the unions (not only of those accessed).  I think that's what other
readings of the standard ask for (there's a bug about this as well).
A mere declaration of a union needs to union the alias-sets and the
following should be valid:

union { long l; long long ll; };

long foo (long *p)
{
  *p = 0;
  *(long long *)p = 1;
  return *p;
}

this means (from an implementation perspective) that iff we do not
want to go this far then accessing a union member via a non-union
type isn't valid.

Anyway ;)  I don't see an easy way to fix the testcases in this PR
without removing the optimization entirely.  It's currently guarded
like

  /* If the TBAA state isn't the same for downstream reads
 we cannot value-number the VDEFs the same.  */
  alias_set_type set = get_alias_set (lhs);
  if (! vnresult
  || vnresult->set == set
  || alias_set_subset_of (set, vnresult->set))

but we don't know whether vnresult is from a load or a store so we
don't know whether it fully specifies the "TBAA state".  So even
dumbing that down to

  if (vnresult->set != set
  || set != get_alias_set (TREE_TYPE (lhs)))
resultsame = false;

where the latter test sees if the alias set for the access and for an
access using a pointer is the same might keep some holes open.

Some of the more interesting cases _did_ involve unions and the above
would likely make them not optimized again (I remember sth with vector
intrinsics and initialization / copying via unions).  Oh, even more
trivial union->x = union->x; will stop from being optimized.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 254135)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -3800,11 +3800,11 @@ visit_reference_op_store (tree lhs, tree
   resultsame = expressions_equal_p (result, op);
   if (resultsame)
{
- /* If the TBAA state isn't compatible for downstream reads
+ /* If the TBAA state isn't the same for downstream reads
 we cannot value-number the VDEFs the same.  */
  alias_set_type set = get_alias_set (lhs);
  if (vnresult->set != set
- && ! alias_set_subset_of (set, vnresult->set))
+ || set != get_alias_set (TREE_TYPE (lhs)))
resultsame = false;
}
 }
@@ -5628,9 +5628,9 @@ eliminate_dom_walker::before_dom_childre
 at least all accesses the later one does or if the store
 was to readonly memory storing the same value.  */
  alias_set_type set = get_alias_set (lhs);
- if (! vnresult
- || vnresult->set == set
- || alias_set_subset_of (set, vnresult->set))
+ if (vnresult
+ && vnresult->set == set
+ && set == get_alias_set (TREE_TYPE (lhs)))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
{
Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c  (revision 254135)
+++ gcc/tree-ssa-dom.c  (working copy)
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3.
 #include "gimplify.h"
 #include "tree-cfgcleanup.h"
 #include "dbgcnt.h"
+#include "alias.h"

 /* This file implements optimizations on the dominator tree.  */

@@ -1953,7 +1954,8 @@ dom_opt_dom_walker::optimize_stmt (basic
  gimple_set_vuse (new_stmt, gimple_vuse (stmt));
  cached_lhs = m_avail_exprs_stack->lookup_avail_expr (new_stmt, false,
   false);
- if (cached_lhs && operand_equal_p (rhs, cached_lhs, 0))
+ if (cached_lhs && operand_equal_p (rhs, cached_lhs, 0)
+ && get_alias_set (lhs) == get_alias_set (TREE_TYPE (lhs)))
{
  basic_block bb = gimple_bb (stmt);
  unlink_stmt_vdef (stmt);

FAILs at least gcc.dg/tree-ssa/ssa-pre-26.c

as said I'm not 100% convinced the more strict handling avoids all of the
cases.

[Bug middle-end/82744] New: Better handling equivalence+common for FORTRAN

[amker at gcc dot gnu.org]

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

Bug ID: 82744
   Summary: Better handling equivalence+common for FORTRAN
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Hi,
Given below fortran code:
  subroutine test (res1, res2)

   integeri, j
   real*8  a(100) , b(100) ,  c(100) , d(100)
   common /area/  a, b, c, d
   real*8 src1(100), temp1(100), temp2(100), src2(100)
   equivalence(src1, a), (src2, b), (temp1, c), (temp2, d)
   real*8 res1(100,100), res2(100,100)

   do 20 j=1,100
do 30 i=1,100
  temp1(i) = 1.0
  temp2(i) = 2.0
  temp1(i) = temp1(i) * src1(i)
  temp2(i) = temp2(i) * src2(i)
  res1(i,j) = temp2(i) * 3.0 + res1(i,j) / 2
  res2(i,j) = temp1(i) * 3.0 + res2(i,j) / 2
 30 continue
 20continue

   return
  end

Fortran FE generates type like:
union
{
  real(kind=8) src1[100];
  real(kind=8) a[100];
  real(kind=8) src2[100];
  real(kind=8) b[100];
  real(kind=8) temp1[100];
  real(kind=8) c[100];
  real(kind=8) temp2[100];
  real(kind=8) d[100];
}
but (src1/a), (src2/b), (temp1/c), (temp2/d) have different DECL_FIELD_OFFSET.
There are two questions here:
A) Should Fortran FE generate better type here?  In this case, it could be
structure of unions.  Thus to make middle-end's life a bit easier.  This maybe
not always straightforward, considering below example:
   real*8  a(100) , b(100) ,  c(100) , d(100)
   common /area/  a, b, c, d
   real*8 src1(100), temp1(100), temp2(1000), src2(100)
   equivalence(src1, a), (src2, b), (temp1, c), (temp2, d)

B) Support arbitrary offset layout in union type.  This is not easy either
because we can have arbitrary overlap with equivalence.  We also need to check
if a field is the "last" one so it can access beyond size of union/record. 
Again, this is not easy with arbitrary layout, though FE may help by setting
some flags.

Back to above example, there are various missed optimizations about dead store
and redundant load.

For the moment, I will categorize this one as middle-end issue.

Thanks.

[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[ch3root at openwall dot com]

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

--- Comment #8 from Alexander Cherepanov  ---
On 2017-10-27 12:41, rguenth at gcc dot gnu.org wrote:
>> And with allocated memory (C; add placement new's for C++):
>>
>> --
>> #include 
>> #include 
>> #include 
>>
>> static long test(long *px, long long *py, void *pu)
>> {
>>*px = 0;
>>*py = 1;
>>
>>// change effective type from long long to long
>>long tmp;
>>memcpy(, pu, sizeof(tmp));
>>memcpy(pu, , sizeof(tmp));
> 
> I believe this one is invalid - memcpy transfers the dynamic
> type and *pu is currently 'long long'.  So it's either not
> changing the dynamic type because, well, the type transfers
> through 'tmp' or you are accessing 'tmp' with declared type
> long as 'long long'.
AIUI memcpy is always valid if there is enough space, no matter what 
types its source and destination have. It accesses both of them as 
arrays of chars -- C11, 7.24.1p1: "The header  declares one 
type and several functions, and defines one  macro useful for 
manipulating arrays of character type and other objects treated as 
arrays of character type."

OTOH memcpy transfers effective type from the source to the destination 
but only if the destination has no declared type -- C11, 6.5p6: "If a 
value is copied into an object having no declared type using memcpy or 
memmove, or is copied as an array of character type, then the effective 
type of the modified object for that access and for subsequent accesses 
that do not modify the value is the effective type of the object from 
which the value is copied, if it has one."
Placement new in C++ can change dynamic types of objects with declared 
type but I don't think there are such facilities in C.

So in this example the first memcpy copies the value of *pu to tmp but 
drops its effective type (long long) and the second memcpy copies the 
value and passes the effective type of 'tmp' (long) along.

[Bug c++/71888] internal compiler error: in force_type_die, at dwarf2out.c:23236

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Fixed in 6.3.0.

[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Alexander Cherepanov from comment #6) 
> And with allocated memory (C; add placement new's for C++):
> 
> --
> #include 
> #include 
> #include 
> 
> static long test(long *px, long long *py, void *pu)
> {
>   *px = 0;
>   *py = 1;
> 
>   // change effective type from long long to long
>   long tmp;
>   memcpy(, pu, sizeof(tmp));
>   memcpy(pu, , sizeof(tmp));

I believe this one is invalid - memcpy transfers the dynamic
type and *pu is currently 'long long'.  So it's either not
changing the dynamic type because, well, the type transfers
through 'tmp' or you are accessing 'tmp' with declared type
long as 'long long'.

>   return *px;
> }
> 
> int main(void)
> {
>   void *p = malloc(10);
> 
>   printf("%ld\n", test(p, p, p));
> }
> --
> 
> Results:
> 
> --
> $ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
> 1
> $ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
> 0
> --
> 
> gcc version: gcc (GCC) 8.0.0 20171023 (experimental)

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[marco at hulten dot org]

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

Marco van Hulten  changed:

   What|Removed |Added

 CC||marco at hulten dot org

--- Comment #6 from Marco van Hulten  ---
The problem still exists in GCC 5.4.0, which was released in June 2016.

In what version is this fixed?

[Bug libgomp/81688] libgomp.c/target-3{3,4}.c fails: GOMP_OFFLOAD_async_run unimplemented for nvptx

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Created attachment 42484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42484=edit
Patch that moves async_run from plugin-hsa.c to default_sync_run

I wonder if this will work.

[Bug fortran/82743] New: uncaught character truncation in derived type initialization

[simon.kluepfel at gmail dot com]

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

Bug ID: 82743
   Summary: uncaught character truncation in derived type
initialization
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.kluepfel at gmail dot com
  Target Milestone: ---

Initializing a derived type with a character component with a string too long
is not caught by -Wcharacter-truncation.

PROGRAM TEST
TYPE A
CHARACTER(LEN=1) :: C
END TYPE A
TYPE(A) :: A1
A1=A("123")
A1=A(C="123")
A1%C="123"
END PROGRAM TEST

compiling with gfortran 7.1.1 and -Wall -Wextra gives only one warning:

main.f95:8:14:

 A1%C="123"
  1
Warning: CHARACTER expression will be truncated in assignment (1/3) at (1)
[-Wcharacter-truncation]

[Bug c++/80739] Accessing value of X through a Y glvalue in a constant expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Paolo Carlini  ---
Fixed in 7.1.0.

[Bug c++/80739] Accessing value of X through a Y glvalue in a constant expression

[paolo at gcc dot gnu.org]

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

--- Comment #1 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Oct 27 08:53:08 2017
New Revision: 254138

URL: https://gcc.gnu.org/viewcvs?rev=254138=gcc=rev
Log:
2017-10-27  Paolo Carlini  

PR c++/80739
* g++.dg/cpp1y/constexpr-80739.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-80739.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/82457] libgcov fork and exec hooks not always used

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Fri Oct 27 08:34:56 2017
New Revision: 254137

URL: https://gcc.gnu.org/viewcvs?rev=254137=gcc=rev
Log:
Document --coverage and fork-like functions (PR gcov-profile/82457).

2017-10-27  Martin Liska  

PR gcov-profile/82457
* doc/invoke.texi: Document that one needs a non-strict ISO mode
for fork-like functions to be properly instrumented.

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

[Bug bootstrap/82670] UBSAN bootstrap broken after recent libsanitizer merge

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Simple steps to reproduce (using r253887):

$ cat main.c
int main(int argc, char **argv)
{
  return 0;
}

$ g++ -g main.c -fpermissive -fsanitize=address && ./a.out
$ g++ -g main.c -fpermissive -fsanitize=address -fsanitize=undefined && ./a.out 
Segmentation fault (core dumped)

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x76f1a4ed in __sanitizer::MaybeInstallSigaction (signum=11,
handler=0x76f02130 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at
../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:200
#2  0x76f1a8fe in __sanitizer::InstallDeadlySignalHandlers
(handler=0x76f02130 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at
../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:209
#3  0x76f08654 in __asan::AsanInitInternal () at
../../../../libsanitizer/asan/asan_rtl.cc:424
#4  0x77de6cee in _dl_init (main_map=0x77ffe110, argc=1,
argv=0x7fffdff8, env=0x7fffe008) at dl-init.c:105
#5  0x77dd7eda in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0001 in ?? ()
#7  0x7fffe3ec in ?? ()
#8  0x in ?? ()

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> I can build the preprocessed source when changing the long long size_t and
> friend
> types to 'long'.  But then I cannot reproduce the segfault with -std=c++1z
> -g -O2,
> it might require MS ABI stuff if it occurs in the dwarf output machinery,
> I checked on x86_64-linux.

Can you please upload the modified file somewhere? I can try a cross compiler.

[Bug libstdc++/82739] [6/7/8 Regression] Sort is 30% slower compared to gcc44 on presorted array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5
Summary|[5/6/7/8 Regression] Sort   |[6/7/8 Regression] Sort is
   |is 30% slower compared to   |30% slower compared to
   |gcc44 on presorted array|gcc44 on presorted array

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I can build the preprocessed source when changing the long long size_t and
friend
types to 'long'.  But then I cannot reproduce the segfault with -std=c++1z -g
-O2,
it might require MS ABI stuff if it occurs in the dwarf output machinery,
I checked on x86_64-linux.

[Bug libstdc++/82739] [5/6/7/8 Regression] Sort is 30% slower compared to gcc44 on presorted array

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-27
 CC||marxin at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
Summary|Sort is 30% slower compared |[5/6/7/8 Regression] Sort
   |to gcc44 on presorted array |is 30% slower compared to
   ||gcc44 on presorted array
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I see one regression that happened in r217669:

Author: jason
* cp-gimplify.c (genericize_cp_loop): Use LOOP_EXPR.
(genericize_for_stmt): Handle null statement-list.

It's revision that is firstly in version 4.9.

It caused following change (I slightly reduced # of iterations):

after: 5.376292
before: 4.322826

In between 4.5.0 and 4.9.0 I see just small regression. Key question is how
changed std::__introsort_loop<__gnu_cxx::__normal_iterator >, long,
__gnu_cxx::__ops::_Iter_less_iter> function with that revision. Jonathan, can
you please take a look?

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Indeed as far as I understand an unspec volatile isn't sth clobbering
registers (not even memory?!).  The insn is missing inputs/outputs
(we might be able to model that lowparts are preserved).

[Bug middle-end/81659] ICE in verify_dominators, at dominance.c:1184

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

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

[Bug middle-end/81659] ICE in verify_dominators, at dominance.c:1184

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Fri Oct 27 08:03:16 2017
New Revision: 254136

URL: https://gcc.gnu.org/viewcvs?rev=254136=gcc=rev
Log:
2017-10-27  Richard Biener  

PR middle-end/81659
* tree-eh.c (pass_lower_eh_dispatch::execute): Free dominator
info when we redirected EH.

* g++.dg/torture/pr81659.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr81659.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug debug/68836] GCC can't properly emit debug info for function arguments in a back-trace when using -Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-10-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Without a (guality?) testcase there's nothing to do here.  But quite likely the
reason is inlining.  Alex new work _might_ help here.

[Bug debug/59515] -Og doesn't generate out-of-line copies of inline functions like -O0 does

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
-fkeep-inline-functions results for

extern void foobar();
struct Foo {
void baz () {
foobar();
foobar();
}
void bar () {
baz();
baz();
}
};
int main()
{
  Foo foo;
  foo.bar();
  return 0;
}

in

_ZN3Foo3bazEv:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_Z6foobarv
call_Z6foobarv
addq$8, %rsp
.cfi_def_cfa_offset 8
ret

_ZN3Foo3barEv:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_Z6foobarv
call_Z6foobarv
call_Z6foobarv
call_Z6foobarv
addq$8, %rsp
.cfi_def_cfa_offset 8
ret

main:
.LFB2:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_Z6foobarv
call_Z6foobarv
call_Z6foobarv
call_Z6foobarv
movl$0, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret


that's undesirable and for some testcases can lead to exponential increase
of compile-time and binary size.  So what we want is for the functions
just kept because of -fkeep-inline-functions is restricting inlining
even more (_really_ only optimize if the size shrinks), or maybe even
disable inlining completely.

As said the implementation side would require keeping offline copy clones
due to the way early inlining works.

Another option would be to reduce --param early-inlining-insns for -Og
and live with the theoretical exponential explosion issue.
With that --param set to zero we do not inline into main but we do inline
into bar () (weird).  The threshold to inline into main is 10.
Something is wrong with size accounting it seems?

Analyzing function body size: void Foo::baz()
Accounting size:2.00, time:0.00 on new predicate:(not inlined)

 BB 2 predicate:(true)
  foobar ();
freq:1.00 size:  1 time: 10
  foobar ();
freq:1.00 size:  1 time: 10
  return;
freq:1.00 size:  1 time:  2
Will be eliminated by inlining
Accounting size:1.00, time:2.00 on predicate:(not inlined)

Inline summary for void Foo::baz()/0 inlinable
  self time:   22
  global time: 0
  self size:   5
  global size: 0
  min size:   0
  self stack:  0
  global stack:0
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)

  calls:
void Foo::baz()/0 function not considered for inlining
  loop depth: 0 freq:1000 size: 2 time: 11 callee size: 2 stack: 0
void Foo::baz()/0 function not considered for inlining
  loop depth: 0 freq:1000 size: 2 time: 11 callee size: 2 stack: 0

so it seems the call with the this parameter is size 2 and the inlined
function with two calls w/o parameters is 2 as well.  Makes sense in
a simplistic way...

That said, a bandaid fix would be the following - some benchmarking
(compile-time / runtime / code-size) for whether adjusting the
early inlining param is necessary would be nice.  Documentation should
be adjusted to reflect the -fkeep-inline-functions default for -Og.

Index: gcc/opts.c
===
--- gcc/opts.c  (revision 254074)
+++ gcc/opts.c  (working copy)
@@ -673,11 +673,17 @@ default_options_optimization (struct gcc
   default_param_value (PARAM_MIN_CROSSJUMP_INSNS),
   opts->x_param_values, opts_set->x_param_values);

-  /* Restrict the amount of work combine does at -Og while retaining
- most of its useful transforms.  */
   if (opts->x_optimize_debug)
-maybe_set_param_value (PARAM_MAX_COMBINE_INSNS, 2,
-  opts->x_param_values, opts_set->x_param_values);
+{
+  /* Restrict the amount of work combine does at -Og while retaining
+most of its useful transforms.  */
+  maybe_set_param_value (PARAM_MAX_COMBINE_INSNS, 2,
+opts->x_param_values, opts_set->x_param_values);
+  /* Restrict early inlining to avoid -fkeep-inline-functions kept
+ functions to grow too large.  */
+  maybe_set_param_value (PARAM_EARLY_INLINING_INSNS, 4,
+opts->x_param_values, opts_set->x_param_values);
+}

   /* Allow default optimizations to be specified on a per-machine basis.  */
   maybe_default_options (opts, opts_set,
@@ -948,6 +954,11 @@ finish_options (struct gcc_options *opts
 maybe_set_param_value (PARAM_MAX_STORES_TO_SINK, 0,
opts->x_param_values, opts_set->x_param_values);

+  /* When using -Og enable -fkeep-inline-functions.  */
+  if (opts->x_optimize_debug
+  && !opts_set->x_flag_keep_inline_functions)
+opts->x_flag_keep_inline_functions = 1;
+
   /* The 

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-10-27
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Hi. I can't build your pre-process source file. Please follow steps to reduce
the segfault:
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

And please try to run it in gdb (adding -wrapper gdb,--args), and print
back-trace. Thanks.