[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[rguenth at gcc dot gnu.org]

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

--- Comment #46 from Richard Biener  ---
(In reply to Richard Biener from comment #44)
> Created attachment 45523 [details]
> workaround
> 
> So I am testing the following workaround, at least "most suitable" for
> branches.
> It avoids generating affected BIT_FIELD_REFs (with bases with integral types
> that have a precision not matching the size of the mode).
> 
> Can arm folks please test this patch and aid me (provide) a dg-torture
> testcase that currently fails?
> 
> It builds OK on x86_64-linux, I'll test it with the endianess test commented
> out to see if there's any testsuite fallout.
> 
> Thanks.

No regressions on x86_64-linux when also enabling there.

[Bug debug/87295] [early debug] ICE with -ffat-lto-objects -fdebug-types-section -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|nathan at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Let me take this bug, looks like we fail to "undo" some effects of the early
write-out.

[Bug c/33719] "#pragma omp for firstprivate(shared_var)" in function labelled 'shared_var' as private

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
That is a correct diagnostics.  The firstprivate is about shared_var itself,
not what it points to, and for firstprivate on the working construct you need a
variable that is shared in the parallel and only privatized in the worksharing
region.  Thus for firstprivate on an orphaned worksharing construct the
variable needs to be file scope/namespace scope, or static, or a reference that
binds to a shared variable.
"A list item that is private within a parallel region must not appear in a
firstprivate clause on a worksharing construct if any of the worksharing
regions arising from the worksharing construct ever bind to any of the parallel
regions arising from the parallel construct."
While the value of shared_var may be the same in all threads of a parallel, it
is still private in the parallel, consider what happens if you take the address
of shared_var, different threads will have different addresses.  Function
parameters passed by value are like if you do { double *shared_var = something;
... } within parallel region, even if something is a shared variable,
shared_var is a local variable and as such it is predetermined to be private. 
Just remove the bogus firstprivate(shared_var) in this case.
Note, if in C++ it is double *_var, then firstprivate(shared_var) might
be ok, it will depend on whether what it binds to is shared or not.
See https://godbolt.org/z/l1v1NF that it is equally rejected by other compilers
too.  They don't get the double *_var case right, but properly diagnose
double *shared_var argument.

[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Brooks Moses from comment #4)
> It turns out that we do need these symbols in libssp despite having a nice
> plain x86-Linux environment.  We've got some precompiled blobs from
> who-knows-where that want the "LIBSSP_1.0" version of the __vsnprintf_chk
> symbol -- and, although our glibc exports __vsnprintf_chk, it of course
> exports it with a "GLIBC_2.3.4" version.  Failure ensues.
> 
> So, for consistency for things that either explicitly declare -lssp or
> otherwise end up with the LIBSSP symbol versions, I think it's nonetheless
> useful to fix the libssp configure file for cross-compilation.
> 
> Thus, patch posted:
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00174.html

Is that patch still relevant?

[Bug middle-end/51677] don't suggest giving main() __attribute__((const))

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Martin Sebor from comment #3)
> > It should be easy to white-list the main function in the
> > -Wsuggest-attribute= checker.  At the same time, I'm not sure it's necessary
> > or that the problem is unique to main.  The reasons noted in comment #0
> > apply to other functions as well.  Defining empty functions is useful for a
> > variety of reasons (e.g., default no-op handlers or, in C++, default no-op
> > implementations of virtual functions).  Similarly, without perfect data flow
> > analysis across the whole program it's impossible to tell whether an extern
> > function is ever called.  Why should main be treated differently from those?
> 
> Because it's an easy first step that doesn't require doing all of those
> extra data flow analyses

Also main() is already treated specially for -Wmain

[Bug c++/52202] [C++11][DR 1376] Should not extend lifetime of temporary wrapped in static_cast to reference type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jens.maurer at gmx dot net

--- Comment #4 from Eric Gallager  ---
(In reply to ensadc from comment #2)
> Superseded by issue 1299? See http://wg21.link/p0727.

cc-ing Jens from that

[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #2 from Eric Gallager  ---
cc-ing libiberty maintainer

[Bug c/33719] "#pragma omp for firstprivate(shared_var)" in function labelled 'shared_var' as private

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing openmp maintainer

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Patch submitted.

https://gcc.gnu.org/ml/fortran/2019-01/msg00236.html

[Bug c/89045] [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-25
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

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

It's unexpectedly reaching this case in get_parm_decl with a VAR_DECL:

7513  /* Other things that might be encountered.  */
7514case LABEL_DECL:
7515case VAR_DECL:
7516default:
7517  gcc_unreachable ();

(gdb) p *b
$3 = {u = {type = , label = 0x0}, decl = ,
id = , prev = 0x0, shadowed = 0x0, 
  depth = 3, invisible = 0, nested = 0, inner_comp = 0, in_struct = 0, locus =
169024}
(gdb) call inform (b->locus, "b->locus")
z1.c: In function ‘f’:
z1.c:3:21: note: b->locus
3 |   void g (int [(int){ x }]);
  | ^

(gdb) call debug_tree (decl)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718c65e8 precision:32 min  max

pointer_to_this >
used ignored read SI z1.c:3:21 size 
unit-size 
align:32 warn_if_not_align:0 context 
initial >

[Bug c++/89036] [8/9 Regression] ICE if destructor has a requires

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from kargl at gcc dot gnu.org ---
My original patch simply fixed the ICE, which then
allowed the code to compile.  In reality, an alternate
return is not ISO C interoperable, so an error message
is a more appropriate response.  I have a patch.  So,
re-open.

[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value

[darryl_okahata at keysight dot com]

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

--- Comment #4 from Darryl Okahata  ---
This seems rather draconian but, if the standard allows for that, so be it.

Thanks.

[Bug middle-end/89052] excessive data segment size causes a hang

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I'd say it's a bug for GCC to need to allocate memory for the trailing 
zero-initialized part of such an object at all; it should only need to 
allocate memory for the initial part and remember that the rest is zero 
(and then tell the assembler that the rest is zero, leaving it to the 
assembler to fail / try to produce a huge object file / ...).

[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86761#c4 on the differences
between C and C++.

[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
You can use -fsanatizer=undefined to find this behavior at runtime.

[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
In C++ it is undefined what happens when a return happens without a value. 
This is different from C.  So these returns are marked as calling
__builtin_unreachable().

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

[Bug c++/86761] Code corruption with missing pointer return

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||darryl_okahata at keysight dot 
com

--- Comment #6 from Andrew Pinski  ---
*** Bug 89056 has been marked as a duplicate of this bug. ***

[Bug c++/89056] New: Optimizer generates bad code for non-void function that fails to return a value

[darryl_okahata at keysight dot com]

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

Bug ID: 89056
   Summary: Optimizer generates bad code for non-void function
that fails to return a value
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: darryl_okahata at keysight dot com
  Target Milestone: ---

Created attachment 45530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45530=edit
preprocessed file

System: ancient Red Hat Enterprise Linux Server release 6.10 (Santiago)
Intel x86_64 system.


g++ -v

Using built-in specs.
COLLECT_GCC=/hped/builds/tfstools/gcc540/linux_x86_64//gcc/8.2.0/bin/g++_x86_64
COLLECT_LTO_WRAPPER=/a/new/sr/proton/d11/build/tfstools/gcc472/linux_x86_64/gcc/8.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-checking=release --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --with-system-zlib
--prefix=/hped/builds/tfstools/gcc472/linux_x86_64/gcc/8.2.0_rebld
--with-gmp=/gfs/sr/sherry/d1/local/dbjornba/btmp
--with-mpfr=/gfs/sr/sherry/d1/local/dbjornba/btmp
--with-mpc=/gfs/sr/sherry/d1/local/dbjornba/btmp
Thread model: posix
gcc version 8.2.0 (GCC)


If you have cruddy code with a non-void function that fails to return a value,
the gcc optimizer can generate an "infinite" loop for a simple iterative loop
(see the end of the *.ii file):

bool test::bah(void)
{
std::deque::iterator iter;

for (iter = values.begin(); iter != values.end(); iter++)
iter->myval -= 0.1;
// returning a value here causes correct code to be generated.
}

The bug can be easily seen using:

g++ -S -O badbad.cc
badbad.cc: In member function 'bool test::bah()':
badbad.cc:42:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^

The generated assembly code shows an "infinite" loop for the simple iterative
loop (which only "terminates" when a bus error occurs).  The correct code is
generated if you add a proper return value.

Yes, this is a poster child for using -Werror=return-type, but gcc should still
not generate bad code (the return value will, of course, still be undefined).

[Bug c++/89055] New: wrong location with predefined macros

[msebor at gcc dot gnu.org]

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

Bug ID: 89055
   Summary: wrong location with predefined macros
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While adding tests for a fix for bug 87996 I noticed that the location in
diagnostic messages for excessive array size expressions involving predefined
constants like __SIZE_MAX__ (or macros like SIZE_MAX) isn't quite the same as
without such constants.  It's a minor aesthetic glitch but one that suggests
there's some underlying bug somewhere that might be worth investigating.

$ cat t.C && gcc -S t.C
char a[~0LU << 1];
char b[__SIZE_MAX__ << 1];

t.C:1:13: error: size of array ‘a’ is negative
1 | char a[~0LU << 1];
  |~^~~~
t.C:2:21: error: size of array ‘b’ is negative
2 | char b[__SIZE_MAX__ << 1];
  | ^

[Bug d/89054] New: libphobos/src/std/math.d:5279:18: error: undefined iden tifier 'ControlState'

[danglin at gcc dot gnu.org]

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

Bug ID: 89054
   Summary: libphobos/src/std/math.d:5279:18: error: undefined
iden tifier 'ControlState'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

libtool: compile:  /home/dave/gnu/gcc/objdir/./gcc/gdc
-B/home/dave/gnu/gcc/objd
ir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-9/hppa-linux-gnu/bin/
-B/home/dave/opt/gn
u/gcc/gcc-9/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-9/hppa-linux
-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-9/hppa-linux-gnu/sys-include
-f
checking=1 -fPIC -O2 -g -nostdinc -I ../../../../gcc/libphobos/src -I
../../../.
./gcc/libphobos/libdruntime -I ../libdruntime -I . -c
../../../../gcc/libphobos/
src/std/json.d -fversion=Shared -o std/.libs/json.o
/home/dave/gnu/gcc/gcc-9/libphobos/src/std/math.d:5279:18: error: undefined
iden
tifier 'ControlState'
 5279 | ControlState savedState;
  |  ^
/home/dave/gnu/gcc/gcc-9/libphobos/src/std/math.d:5326:25: error: undefined
iden
tifier 'ControlState'
 5326 | static ControlState getControlState() @trusted nothrow @nogc
  | ^
/home/dave/gnu/gcc/gcc-9/libphobos/src/std/math.d:5392:17: error: undefined
iden
tifier 'ControlState'
 5392 | static void setControlState(ControlState newState) @trusted nothrow
@nogc
  | ^
make[4]: *** [Makefile:1628: std/json.lo] Error 1
make[4]: Leaving directory
'/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src'

[Bug libgomp/81691] libgomp.fortran/target2.f90 fails for nvptx at -O0 and -O1

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #4 from Tom de Vries  ---
The main failure is "libgomp: cuCtxSynchronize error: an illegal memory access
was encountered".

Presumably, the root cause for the main failure is fixed by the OpenMP 5.0
changes in r265930, which should also fix it for intelmic.

Marking this resolved-fixed.

[Bug libgomp/87834] nvptx offloading: "WARNING: program timed out" for libgomp.fortran/target2.f90 execution test at -O0, -O1

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #1 from Tom de Vries  ---
This test fails in this mode until r265929. At r265938, this test-case starts
passing. Inbetween, build problems.

The main failure is "libgomp: cuCtxSynchronize error: an illegal memory access
was encountered", and is as mentioned in PR81691 comment 2 not specific to the
target.

Presumably, the root cause for the main failure is fixed by the OpenMP 5.0
changes in r265930.

Consequently, the npvtx libgomp plugin errors following the main failure, be it
either the hang in this PR or the PR81691 "libgomp: cuMemFreeHost
error/libgomp: device finalization failed" errors don't trigger anymore.

Going back to the failing r265929, and applying:
- [nvptx, libgomp] Fix cuMemAlloc with size zero
- [nvptx, libgomp] Fix assert (!s->map->active) in map_fini
- [nvptx, libgomp] Fix map_push
gets us back the main failure:
...
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
FAIL: libgomp.fortran/target2.f90   -O0  execution test
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
FAIL: libgomp.fortran/target2.f90   -O1  execution test
...

So it seems this is a duplicate of one or a combination of the PRs fixed by
those three commits. Marking it resolved-fixed, since I'm not sure which one to
mark it a duplicate of.

[Bug c++/89053] New: initializer-string too long for a large char array initialized with empty string

[msebor at gcc dot gnu.org]

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

Bug ID: 89053
   Summary: initializer-string too long for a large char array
initialized with empty string
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While experimenting with the test case for pr89052 I came across the following
error issued by the G++ front-end for the string literal initializer.  Since
the equivalent brace-enclosed initializer is accepts the error looks like a bug
rather than a simple limitation.

$ cat a.c && gcc -S -Wall -xc++ a.c 
#include 

char a[INT_MAX >> 2] = { '\0' };   // accepted
char b[INT_MAX >> 2] = ""; // error

a.c:4:24: error: initializer-string for array of chars is too long
[-fpermissive]
4 | char b[INT_MAX >> 2] = ""; // error
  |^~

[Bug middle-end/89052] excessive data segment size causes a hang

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Clang seems to use SIZE_MAX / 8 as the maximum object size and gives an error
for any object whose size exceeds that.  But it doesn't seem to doesn't track
total object sizes and crashes in LLVM as it runs out of memory for the test
case below:

#include 

char a[SIZE_MAX / 8] = "1";
char b[SIZE_MAX / 8] = "x";

In C mode, GCC compiles the code above without hanging anywhere but G++ gives
errors.  In fact, it fails with the same error even for 'char a[INT_MAX >> 2] =
"1";'

a.c:3:24: error: initializer-string for array of chars is too long
[-fpermissive]
3 | char a[SIZE_MAX / 8] = "1";
  |^~~
a.c:4:24: error: initializer-string for array of chars is too long
[-fpermissive]
4 | char b[SIZE_MAX / 8] = "x";
  |^~~

[Bug middle-end/89052] New: excessive data segment size causes a hang

[msebor at gcc dot gnu.org]

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

Bug ID: 89052
   Summary: excessive data segment size causes a hang
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Making a silly mistake and using the wrong macro such as SIZE_MAX instead of
MAX_SIZE as the array size when defining a global object seems to cause as to
hang presumably while trying to allocate huge amounts of memory.  It's not
immediately obvious what the problem might be in such a case.

GCC already warns when the size of any single object exceeds some maximum but
it could help prevent this kind of a mistake by computing the size of all
global objects (or even the size of local objects in each function) and issuing
a warning such as -Wlarger-than= or even an error when the total size of all of
them exceeds the same limit.  The current permissive limit is PTRDIFF_MAX but I
don't think there are too many 64-bit systems that can actually handle that
much memory so using a lower limit lower would be even better.

$ (cat a.c && ulimit -v 1 && gcc -Wall -c a.c)
#include 

#define MAX_SIZE 32

char a[SIZE_MAX / 2] = "1";   // typo: should have been MAX_SIZE / 2
char b[SIZE_MAX / 2] = "x";   // ditto

xgcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug debug/87295] [early debug] ICE with -ffat-lto-objects -fdebug-types-section -g

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenther at suse dot de

--- Comment #2 from Jan Hubicka  ---
I suppose it is early debug tooling not knowing that it needs to copy the
section as well?

[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/89051] New: -Wno-error= does not work for warning groups

[m101010a at gmail dot com]

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

Bug ID: 89051
   Summary: -Wno-error= does not work for warning groups
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.c
void f() { g(1); }
$ gcc -fsyntax-only -Wall -Wno-implicit x.c
$ gcc -fsyntax-only -Werror=all -Wno-error=implicit x.c
x.c: In function ‘f’:
x.c:1:12: error: implicit declaration of function ‘g’
[-Werror=implicit-function-declaration]
 void f() { g(1); }
^
cc1: some warnings being treated as errors
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

-Wno-error=* should work like -Wno-* and disable errors for more specific
groups of warnings.

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
template  struct dn 
{
  static void execute (long *ary)
  {
constexpr int index = 0;

[&] { auto  = ary [index]; };
  }
};

void foo ()
{
  dn::execute;
}

[Bug lto/88643] -Wl,--wrap not supported with LTO

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #3 from Sergei Trofimovich  ---
One of Gentoo users rediscovered similar bug on cmocka-1.1.3 project:
https://bugs.gentoo.org/675876

It exhibits as a linker failure:

# LANG=C make V=1 VERBOSE=1
/usr/lib64/ccache/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -flto
-fdiagnostics-show-option -frecord-gcc-switches  -Wl,-O1 -Wl,--as-needed -O2
-pipe -flto -Wl,--hash-style=gnu  -Wl,--wrap=uptime
CMakeFiles/test_uptime.dir/test_uptime.c.o  -o test_uptime
-Wl,-rpath,/dev/shm/portage/dev-util/cmocka-1.1.3/work/cmocka-1.1.3-abi_x86_64.amd64/src
../../../src/libcmocka.so.0.5.1 /usr/lib/librt.so 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/cc3ig6Xu.ltrans0.ltrans.o: in function `calc_uptime':
:(.text+0x46): undefined reference to `__wrap_uptime'
collect2: error: ld returned 1 exit status

Would extracting another example be useful here?

[Bug c/88956] [9 Regression] ICE: Floating point exception on a memcpy from an zero-length constant array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01340.html

[Bug fortran/88821] Inline packing of non-contiguous arguments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #45514|0   |1
is obsolete||

--- Comment #4 from Thomas Koenig  ---
Created attachment 45529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45529=edit
Updated patch

This one is cleaner - at least it is clearer why it is working :-)

[Bug c++/89001] g++ uses wrong mangling for lifetime-extended temporaries

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 9.

[Bug c++/89036] [8/9 Regression] ICE if destructor has a requires

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-24
Summary|ICE if destructor has a |[8/9 Regression] ICE if
   |requires|destructor has a requires
 Ever confirmed|0   |1

[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0
  Known to fail||8.2.0

--- Comment #6 from Martin Sebor  ---
The warning has been enhanced to detect the strlen mismatch in r268251, but it
requires -Wextra.  This was done to avoid diagnosing some more-or-less benign
mismatches (like in const qualifiers) but I don't think it applies as well when
the mismatch is between an integer and pointer.  But I suppose tightening that
up will need to wait for the future.  Let me resolve this as fixed and think
about opening a new bug for that.

$ gcc -S -Wall -Wextra pr86125.c
pr86125.c:1:7: warning: conflicting types for built-in function ‘strdup’;
expected ‘char *(const char *)’ [-Wbuiltin-declaration-mismatch]
1 | char* strdup (int);// warning (good)
  |   ^~
pr86125.c:2:7: warning: mismatch in return type of built-in function ‘strlen’;
expected ‘long unsigned int’ [-Wbuiltin-declaration-mismatch]
2 | char* strlen (const char*);// missing warning
  |   ^~

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Better testcase for debugging:

program pr85858
  implicit none
  integer, pointer :: t(:)
  integer  :: i, lb
  lb = -1
  allocate (t(lb:5))
  do i = lb, 5
 t(i) = i
  end do
  call te (t(  :))  ! Full array: OK
  call te (t(lb:))  ! Array section, but effectively full array: OK
  call te (t( 0:))  ! Offset should depend on 0-lb !
  call te (t( 1:))  ! Offset should depend on 1-lb !
contains
  subroutine te (a)
integer, pointer, intent(in) :: a(:)
print *, a(1)   !, lbound (a, dim=1)
  end subroutine te
end program

Expected output: four 1s.

Current trunk prints:
   1
   1
   2
   3

(Outputs of 7.x and 8.x are also quite strange).

Dump-tree-original shows for the generated descriptors (excerpt):

for call te (t(lb:))

  D.3893 = (integer(kind=8)) lb;
  parm.3.dim[0].lbound = D.3893;
  D.3901 = t.dim[0].stride;
  parm.3.data = (void *) &(*(integer(kind=4)[0:] *) t.data)[(D.3893 -
t.dim[0].lbound) * D.3901];
  parm.3.offset = t.offset;

for call te (t( 0:))

  parm.4.dim[0].lbound = 0;
  parm.4.data = (void *) &(*(integer(kind=4)[0:] *)
t.data)[-t.dim[0].lbound * D.3909];
  parm.4.offset = t.offset;

while the subroutine references:

(a->data + (sizetype) ((a->offset + NON_LVALUE_EXPR dim[0].stride>) *
a->span))

Can this be right?  If .data changes, shouldn't .offset change accordingly?

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-24
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Somewhat further reduced:
typedef enum {} a;
typedef enum { b, c, d, e, f } g;
typedef enum {
  h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, aa, ab, ac, ad, ae,
af, ag, ah, ai, aj, ak, al, am, an
} ao;
typedef struct {
  long aq[];
} ar;
struct as;
using ay = a;
using az = g;
const az ba = b;
const az bb = c;
const az bc = d;
const az bd = e;
const az be = f;
using bf = ao;
const bf any = h;
const bf bg = i;
const bf bh = j;
const bf bi = k;
const bf bj = l;
const bf bk = m;
const bf bl = n;
const bf bm = o;
const bf bn = p;
const bf bo = q;
const bf bp = r;
const bf bq = s;
const bf br = t;
const bf bs = u;
const bf bt = v;
const bf bu = w;
const bf bv = x;
const bf bw = y;
const bf bx = z;
const bf by = aa;
const bf bz = ab;
const bf ca = ac;
const bf cb = ad;
const bf cc = ae;
const bf cd = af;
const bf ce = ag;
const bf cf = ah;
const bf cg = ai;
const bf ch = aj;
const bf ci = ak;
const bf cj = al;
const bf ck = am;
const bf cl = an;
using cm = ar;
using cn = as;
using cp = int;
using cq = int;
using cr = int;
class cx {
public:
  template  cx(cy, cy);
};
struct da {
  da(int );
  cm db();
};
struct at {
  virtual ay dc(int **, const int *, const int **) const;
};
struct as {
  typedef ay (*dd)(at **, const int *, const int *, const int *);
};
struct de {
  de(at *, cx, cx);
};
struct dg {
  ~dg();
};
struct dh : at {
  using di = dg;
  di dj;
};
namespace dk {
const bool dl = true;
const bool dm = false;
} template  struct dn ;
template  struct dn {
  static ay execute() {
da input_d = 0;
constexpr bool w_groups = by;
auto _g_oihw_d = input_d;
[&] { auto _g_oihw_off = _g_oihw_d.db().aq[w_groups]; };
return ay();
  }
};
template 
struct srt : de {
  struct dg : dh {
dg(di *, di *, const cp *);
ay dc(cq **, const cr *inputs, const cq **outputs) const {
  cx ins(inputs, inputs);
  cx outs(outputs, outputs);
  srt(this, ins, outs);
  return ay();
}
static ay ct(at **, const int *input_pd, const int *output_pd, const cp
*attr) {
  auto _pd = new dg((di *)input_pd, (di *)output_pd, attr);
  delete _pd;
  return ay();
}
  };
  srt(const dg *pd, cx inputs, cx outputs) : de(_, inputs, outputs),
conf_(*pd) {
dn<1, spec>::execute;
  }
  dg conf_;
};
template  struct wrt {
  struct dg {
static ay ct(at **, const int *, const int *, const cp *);
  };
};
using rpd_ct_f = cn::dd;
rpd_ct_f cql[]{
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
wrt<2, by, bd, cl, dk::dl>::dg::ct,
wrt<2, bl, bd, cl, dk::dl>::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,
srt::dg::ct,

[Bug c++/89036] ICE if destructor has a requires

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Fails this assertion in cp/class.c:add_method:

1136  /* A class should never have more than one destructor.  */
1137  gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P
(method));

[Bug tree-optimization/89043] strcat (strcpy (d, a), b) not folded to stpcpy (strcpy (d, a), b)

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Ah, makes sense.  I briefly wondered how stpcpy could have been "updated for
alignment with the ISO/IEC 9899:1999 standard."  That's the trade-off of a 4k
monitor: it fits tons of stuff on the screen but everything is so tiny that I
end up guessing as much as reading.

[Bug c/88886] [9 Regression] ice in get_constant, at c-family/c-format.c:292

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed via r268251.  GCC issues the following warnings for the test case in
comment #0:

$ cat pr6.c && gcc -S -Wall -Wextra pr6.c
int sscanf(long, unsigned[], ...);
void a() { sscanf(0, ""); }
pr6.c:1:5: warning: conflicting types for built-in function ‘sscanf’;
expected ‘int(const char *, const char *, ...)’
[-Wbuiltin-declaration-mismatch]
1 | int sscanf(long, unsigned[], ...);
  | ^~
pr6.c:1:1: note: ‘sscanf’ is declared in header ‘’
  +++ |+#include 
1 | int sscanf(long, unsigned[], ...);
pr6.c: In function ‘a’:
pr6.c:2:22: warning: passing argument 2 of ‘sscanf’ from incompatible
pointer type [-Wincompatible-pointer-types]
2 | void a() { sscanf(0, ""); }
  |  ^~
  |  |
  |  char *
pr6.c:1:18: note: expected ‘unsigned int *’ but argument is of type ‘char
*’
1 | int sscanf(long, unsigned[], ...);
  |  ^~

[Bug c++/89001] g++ uses wrong mangling for lifetime-extended temporaries

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Jan 24 21:23:33 2019
New Revision: 268252

URL: https://gcc.gnu.org/viewcvs?rev=268252=gcc=rev
Log:
PR c++/89001 - mangling of reference temporaries

It used to be the case that the mangled name of a reference temporary didn't
need to be standardized, because all access would be through the reference.
But now constant expressions can look through references and so different
translation units need to agree on the address of a temporary in the
initializer of a reference with vague linkage.

* cp-tree.h (struct saved_scope): Add ref_temp_count.
(current_ref_temp_count): New macro.
* mangle.c (mangle_ref_init_variable): Use it.
* typeck2.c (store_init_value): Clear it.
* call.c (make_temporary_var_for_ref_to_temp): Copy public and
comdat.

Added:
trunk/gcc/testsuite/g++.dg/abi/ref-temp1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/mangle.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/cpp1z/decomp34.C

[Bug target/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
Created attachment 45528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45528=edit
gcc9-pr87214-wip.patch

Untested fix.  Still need to cover all the changes with testcases.

[Bug middle-end/86308] [7/8 Regression] ICE in verify_gimple calling an invalid index() declaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |verify_gimple calling an|verify_gimple calling an
   |invalid index() declaration |invalid index() declaration

--- Comment #8 from Martin Sebor  ---
Fixed for GCC 9 via r268251.  GCC now issues the following warnings:

$ cat pr86308.c && /build/arm-none-eabi/gcc-svn/gcc/xgcc -B
/build/arm-none-eabi/gcc-svn/gcc -S -Wall -Wextra pr86308.c
int index (int, int);

void foo(const short *input)
{
short a0 = input[index(0, 0)];
}
pr86308.c:1:5: warning: conflicting types for built-in function ‘index’;
expected ‘char *(const char *, int)’ [-Wbuiltin-declaration-mismatch]
1 | int index (int, int);
  | ^
pr86308.c: In function ‘foo’:
pr86308.c:5:11: warning: unused variable ‘a0’ [-Wunused-variable]
5 | short a0 = input[index(0, 0)];
  |   ^~

[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Thu Jan 24 21:06:01 2019
New Revision: 268251

URL: https://gcc.gnu.org/viewcvs?rev=268251=gcc=rev
Log:
PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return type
PR middle-end/86308 - ICE in verify_gimple calling index() with an invalid
declaration
PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return type
PR c/6 - [9 Regression] ice in get_constant, at c-family/c-format.c:292

gcc/c/ChangeLog:

PR c/86125
PR c/6
PR middle-end/86308
* c-decl.c (match_builtin_function_types): Add arguments.
(diagnose_mismatched_decls): Diagnose mismatched declarations
of built-ins more strictly.

gcc/testsuite/ChangeLog:

PR c/86125
PR c/6
PR middle-end/86308
* gcc.dg/Wbuiltin-declaration-mismatch-6.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-7.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-8.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-9.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-10.c: New test.
* gcc.dg/builtins-69.c: New test.
* gcc.dg/Wint-conversion-2.c: Add expected warning.
* gcc.c-torture/execute/eeprof-1.c: Adjust function signatures.


Added:
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-10.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-6.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-8.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-9.c
trunk/gcc/testsuite/gcc.dg/builtins-69.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/eeprof-1.c
trunk/gcc/testsuite/gcc.dg/Wint-conversion-2.c

[Bug c/88886] [9 Regression] ice in get_constant, at c-family/c-format.c:292

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Jan 24 21:06:01 2019
New Revision: 268251

URL: https://gcc.gnu.org/viewcvs?rev=268251=gcc=rev
Log:
PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return type
PR middle-end/86308 - ICE in verify_gimple calling index() with an invalid
declaration
PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return type
PR c/6 - [9 Regression] ice in get_constant, at c-family/c-format.c:292

gcc/c/ChangeLog:

PR c/86125
PR c/6
PR middle-end/86308
* c-decl.c (match_builtin_function_types): Add arguments.
(diagnose_mismatched_decls): Diagnose mismatched declarations
of built-ins more strictly.

gcc/testsuite/ChangeLog:

PR c/86125
PR c/6
PR middle-end/86308
* gcc.dg/Wbuiltin-declaration-mismatch-6.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-7.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-8.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-9.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-10.c: New test.
* gcc.dg/builtins-69.c: New test.
* gcc.dg/Wint-conversion-2.c: Add expected warning.
* gcc.c-torture/execute/eeprof-1.c: Adjust function signatures.


Added:
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-10.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-6.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-8.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-9.c
trunk/gcc/testsuite/gcc.dg/builtins-69.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/eeprof-1.c
trunk/gcc/testsuite/gcc.dg/Wint-conversion-2.c

[Bug middle-end/86308] [7/8/9 Regression] ICE in verify_gimple calling an invalid index() declaration

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Thu Jan 24 21:06:01 2019
New Revision: 268251

URL: https://gcc.gnu.org/viewcvs?rev=268251=gcc=rev
Log:
PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return type
PR middle-end/86308 - ICE in verify_gimple calling index() with an invalid
declaration
PR c/86125 - missing -Wbuiltin-declaration-mismatch on a mismatched return type
PR c/6 - [9 Regression] ice in get_constant, at c-family/c-format.c:292

gcc/c/ChangeLog:

PR c/86125
PR c/6
PR middle-end/86308
* c-decl.c (match_builtin_function_types): Add arguments.
(diagnose_mismatched_decls): Diagnose mismatched declarations
of built-ins more strictly.

gcc/testsuite/ChangeLog:

PR c/86125
PR c/6
PR middle-end/86308
* gcc.dg/Wbuiltin-declaration-mismatch-6.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-7.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-8.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-9.c: New test.
* gcc.dg/Wbuiltin-declaration-mismatch-10.c: New test.
* gcc.dg/builtins-69.c: New test.
* gcc.dg/Wint-conversion-2.c: Add expected warning.
* gcc.c-torture/execute/eeprof-1.c: Adjust function signatures.


Added:
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-10.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-6.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-8.c
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-9.c
trunk/gcc/testsuite/gcc.dg/builtins-69.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/eeprof-1.c
trunk/gcc/testsuite/gcc.dg/Wint-conversion-2.c

[Bug tree-optimization/89043] strcat (strcpy (d, a), b) not folded to stpcpy (strcpy (d, a), b)

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Thu, 24 Jan 2019, msebor at gcc dot gnu.org wrote:

> The CHANGE HISTORY section for stpcpy says the function was first released in
> Issue 1 and derived from Issue 1 of the SVID:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html

That's a CHANGE HISTORY for the page as a whole (also covering strcpy) - 
the addition of stpcpy is listed there under issue 7 "The stpcpy() 
function is added from The Open Group Technical Standard, 2006, Extended 
API Set Part 1.".  I checked and stpcpy is not in issue 1 or 3 of XPG or 
issue 1 or 2 of SVID.

[Bug rtl-optimization/88948] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r264148

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 24 20:48:01 2019
New Revision: 268249

URL: https://gcc.gnu.org/viewcvs?rev=268249=gcc=rev
Log:
PR target/88948
* rtl.h (prepare_copy_insn): New prototype.
* gcse.c (prepare_copy_insn): New function, split out from
process_insert_insn.
(process_insert_insn): Use prepare_copy_insn.
* store-motion.c (replace_store_insn): Use prepare_copy_insn
instead of gen_move_insn.

testsuite/ChangeLog:

PR target/88948
* gcc.target/i386/pr88948.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr88948.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcse.c
trunk/gcc/rtl.h
trunk/gcc/store-motion.c
trunk/gcc/testsuite/ChangeLog

[Bug target/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Even more reduced testcase:
typedef long long int V __attribute__((vector_size (4 * sizeof (long long
int;

__attribute__((noipa))
void foo (V *p)
{
  p[0] = __builtin_shuffle (p[1], p[2], (V) { 2, 3, 5, 6 });
}

int
main ()
{
  V a[3] = { { 0, 0, 0, 0 }, { 10, 11, 12, 13 }, { 14, 15, 16, 17 } };
  foo (a);
  if (a[0][0] != 12 || a[0][1] != 13 || a[0][2] != 15 || a[0][3] != 16)
__builtin_abort ();
  return 0;
}

Works with -O2 -mavx2, aborts with -O2 -mavx512vl.

[Bug c++/55319] Using -fwhole-program inhibits optimization

[m101010a at gmail dot com]

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

m101010a at gmail dot com changed:

   What|Removed |Added

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

--- Comment #4 from m101010a at gmail dot com ---
This is no longer an issue in GCC 8.2.1

[Bug tree-optimization/89043] strcat (strcpy (d, a), b) not folded to stpcpy (strcpy (d, a), b)

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The CHANGE HISTORY section for stpcpy says the function was first released in
Issue 1 and derived from Issue 1 of the SVID:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html

[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #2)
> Richard, can you have a look?

Sure.  And yeah, agree an extract_uhwi-based sequence is the way to go.

[Bug c/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-24
  Known to work||8.2.0
 Blocks||85741
Summary|GCC 9 -Wformat-overflow=2   |[9 Regression] GCC 9
   |should reflect real libc|-Wformat-overflow=2 should
   |limits  |reflect real libc limits
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #7 from Martin Sebor  ---
Thanks.  I've built qemu 3.1.0 with -Wformat-overflow=2 myself and reproduced
the warnings below.  Of those, 16 are for fprintf, 106 for printf, and 20 for
sprintf.  At least some of these look like they would be hard to deal with and
for little gain.  For example:

qemu-3.1.0/linux-user/main.c:484:27: warning: ‘%-*s’ directive output
 between 0 and 2147483648 bytes may exceed minimum required size of 4095
[-Wform
at-overflow=]
  484 | printf("-%-*s %-*s %s\n", maxarglen, arginfo->argv,
  |   ^~~~

Let me confirm this as a regression and look into doing something about it for
GCC 9.

DiagnosticCount   UniqueFiles
-Wstringop-truncation   24711
-Waddress-of-packed-member  189  134   15
-Wformat-overflow=  143   246

-Wformat-overflow Instances:
  /build/tmp/qemu-3.1.0/hw/intc/exynos4210_gic.c:316
  /build/tmp/qemu-3.1.0/hw/intc/exynos4210_gic.c:326
  /build/tmp/qemu-3.1.0/hw/vfio/pci.c:2220
  /build/tmp/qemu-3.1.0/linux-user/main.c:475
  /build/tmp/qemu-3.1.0/linux-user/main.c:480
  /build/tmp/qemu-3.1.0/linux-user/main.c:484
  migration/savevm.c:418
  migration/savevm.c:420
  migration/savevm.c:421
  migration/savevm.c:423
  migration/savevm.c:425
  migration/savevm.c:430
  migration/savevm.c:447
  migration/savevm.c:449
  migration/savevm.c:452
  migration/savevm.c:453
  migration/savevm.c:455
  migration/savevm.c:461
  migration/savevm.c:476
  migration/savevm.c:482
  migration/savevm.c:492
  migration/savevm.c:494
  qemu-img.c:200
  qemu-io.c:422

-Wstringop-truncation Instances:
  /usr/include/bits/string_fortified.h:106


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug target/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #21 from Jakub Jelinek  ---
I'll handle this.

[Bug debug/89006] [9 Regression] New note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location since r267638

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/89006] [9 Regression] New note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location since r267638

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 24 20:20:47 2019
New Revision: 268248

URL: https://gcc.gnu.org/viewcvs?rev=268248=gcc=rev
Log:
PR debug/89006
* config/i386/i386.c (ix86_pic_register_p): Return true for
UNSPEC_SET_GOT too.

* g++.dg/debug/pr89006.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr89006.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89050] New: GCC sometimes requires this to be captured when doing overload resolution but selecting a static member function

[m101010a at gmail dot com]

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

Bug ID: 89050
   Summary: GCC sometimes requires this to be captured when doing
overload resolution but selecting a static member
function
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template  struct A {
static void f();
void f(int);

void foo() {
[]{ f(); };
}
};

void foo(A ) {
a.foo();
}
$ g++ -fsyntax-only x.cpp
x.cpp: In lambda function:
x.cpp:6:15: error: ‘this’ was not captured for this lambda function
 []{ f(); };
   ^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)

If A is not a template or there is no competing non-static member named f, this
works fine.  This is basically bug 51494 but with templates and overload
resolution.

[Bug target/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|tree-optimization   |target
   Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #20 from rsandifo at gcc dot gnu.org  
---
Not really best placed to fix or test this.

[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[rsandifo at gcc dot gnu.org]

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

--- Comment #19 from rsandifo at gcc dot gnu.org  
---
OK.  The .optimized dumps seem to be the same for both -mavx2 and
-march=skylake-avx512.  Things only diverge during expand.

It looks like it might be a bug in:

(define_insn "avx512dq_shuf_64x2_1"
  [(set (match_operand:VI8F_256 0 "register_operand" "=v")
(vec_select:VI8F_256
  (vec_concat:
(match_operand:VI8F_256 1 "register_operand" "v")
(match_operand:VI8F_256 2 "nonimmediate_operand" "vm"))
  (parallel [(match_operand 3  "const_0_to_3_operand")
 (match_operand 4  "const_0_to_3_operand")
 (match_operand 5  "const_4_to_7_operand")
 (match_operand 6  "const_4_to_7_operand")])))]
  "TARGET_AVX512VL
   && (INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
   && INTVAL (operands[5]) == (INTVAL (operands[6]) - 1))"
{
  int mask;
  mask = INTVAL (operands[3]) / 2;
  mask |= (INTVAL (operands[5]) - 4) / 2 << 1;
  operands[3] = GEN_INT (mask);
  return "vshuf64x2\t{%3, %2, %1,
%0|%0, %1, %2, %3}";
}
  [(set_attr "type" "sselog")
   (set_attr "length_immediate" "1")
   (set_attr "prefix" "evex")
   (set_attr "mode" "XI")])

which AFAICT requires without checking that operands 3 and 5 are even (0 or 2
and 4 or 6 respectively).  In this case we're using it to match:

(insn 40 39 41 6 (set (reg:V4DI 101 [ vect__5.17 ])
(vec_select:V4DI (vec_concat:V8DI (reg:V4DI 98 [ vect__5.14 ])
(reg:V4DI 140 [ vect__5.15 ]))
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 5 [0x5])
(const_int 6 [0x6])
]))) "/tmp/foo.c":8:22 4069 {*avx512dq_shuf_i64x2_1}
 (nil))

and treat the permute mask as {2, 3, 4, 5} instead.

[Bug tree-optimization/89049] [8/9 Regression] Unexpected vectorization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target||x86_64-linux
 CC||hjl.tools at gmail dot com,
   ||rsandifo at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
   Target Milestone|--- |8.3

[Bug tree-optimization/89049] New: [8/9 Regression] Unexpected vectorization

[jakub at gcc dot gnu.org]

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

Bug ID: 89049
   Summary: [8/9 Regression] Unexpected vectorization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int bar (float *p) { float r = 0; for (int i = 0; i < 1024; ++i) r += p[i];
return r; }
with -O2 -mavx2 -ftree-vectorize starting with r256639 is vectorized as:
.L6:
vmovups (%rdi), %xmm4
vinsertf128 $0x1, 16(%rdi), %ymm4, %ymm2
addq$32, %rdi
vaddss  %xmm4, %xmm0, %xmm0
vshufps $85, %xmm4, %xmm4, %xmm3
vshufps $255, %xmm4, %xmm4, %xmm1
vaddss  %xmm3, %xmm0, %xmm0
vunpckhps   %xmm4, %xmm4, %xmm3
vaddss  %xmm3, %xmm0, %xmm0
vaddss  %xmm1, %xmm0, %xmm0
vextractf128$0x1, %ymm2, %xmm1
vshufps $85, %xmm1, %xmm1, %xmm2
vaddss  %xmm1, %xmm0, %xmm0
vaddss  %xmm2, %xmm0, %xmm0
vunpckhps   %xmm1, %xmm1, %xmm2
vshufps $255, %xmm1, %xmm1, %xmm1
vaddss  %xmm2, %xmm0, %xmm0
vaddss  %xmm1, %xmm0, %xmm0
cmpq%rdi, %rax
jne .L6
The only vector thing in the loop is the vector unaligned load, all the rest
are either extractions from the vector or scalar operations.  At least for -O2
I'd hope we don't do this, I strongly believe scalar loop would be faster, and
if we don't decide to unroll it, even much smaller.  Either the costs are
computed wrongly here, or the vectorizer uses them wrongly.

[Bug c++/89001] g++ uses wrong mangling for lifetime-extended temporaries

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/88976] [7/8 Regression] ICE in fold_convert_loc, at fold-const.c:2552

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.c:2552   |fold-const.c:2552
  Known to fail|9.0 |

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

[Bug middle-end/89015] [9 Regression] ICE in lookup_decl_in_outer_ctx, at omp-low.c:3480

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88964] [8 Regression] ICE in wide_int_to_tree_1, at tree.c:1561

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 24 19:49:09 2019
New Revision: 268247

URL: https://gcc.gnu.org/viewcvs?rev=268247=gcc=rev
Log:
PR tree-optimization/88964
* gimple-loop-interchange.cc (loop_cand::analyze_induction_var): Also
punt if HONOR_SNANS (chrec).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-loop-interchange.cc

[Bug libfortran/89020] close(status='DELETE') does not remove file

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Thu, Jan 24, 2019 at 01:32:56PM +, tkoenig at gcc dot gnu.org wrote:
> 
> However, I'd like to look at the code first and check if we
> can actually accommodate this strange behavior without pessimizing
> anything else.  If so, I would be inclined to "fix" this.
> 

I took a quick peek at the code.  I actually could not find
where we set iostat and iomsg if present.  For this simple
program 

program foo
   i = 42
   open(unit=7, file='tmp.dat')
   write(7,*) 'tmp.dat'
   close(7,iostat=i)
   print *, i
end program foo

the relevant part of -fdump-tree-original looks like

  {
struct __st_parameter_close close_parm.2;

close_parm.2.common.filename = &"t.f90"[1]{lb: 1 sz: 1};
close_parm.2.common.line = 5;
i = 0;
close_parm.2.common.iostat = 
close_parm.2.common.flags = 32;
close_parm.2.common.unit = 7;
_gfortran_st_close (_parm.2);
  }

So we pass the address of i in the close_parm, but I
don't see libgfortran/io/close.c doing anything with 
.iostat (or .iomsg).  In fact, st_close() doesn't
check the return status of remove()?

Of course, I could be missing something obvious.  Jerry?

[Bug c++/89048] constant evaluation in trailing return type rejected

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
Actually, now I'm really not sure if this is a gcc bug, but then I really don't
know what the language rule is that rejects this. Sorry for the spam, this
needs some more thought.

[Bug c/89035] Request - builtins for unspecified and arbitrary values

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to David Brown from comment #2)
> Yes, "int x = x;" does give an unspecified value without a warning.

Really, not even one from -Winit-self?

[Bug tree-optimization/89043] strcat (strcpy (d, a), b) not folded to stpcpy (strcpy (d, a), b)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
stpcpy() is POSIX? Which version? My (admittedly old) manpage says "The
stpcpy() function is an MS-DOS and GNUism.  The stpcpy() function conforms to
no standard."

[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I think this is a dup of something but I can't remember the bug number right
now; I'll search harder later...

[Bug middle-end/89015] [9 Regression] ICE in lookup_decl_in_outer_ctx, at omp-low.c:3480

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 24 19:17:13 2019
New Revision: 268246

URL: https://gcc.gnu.org/viewcvs?rev=268246=gcc=rev
Log:
PR middle-end/89015
* tree-nested.c (convert_nonlocal_reference_stmt,
convert_local_reference_stmt, convert_tramp_reference_stmt,
convert_gimple_call) : Treat
gimple_omp_teams_host teams stmts like GIMPLE_OMP_PARALLEL
or GIMPLE_OMP_TASK.

* gcc.dg/gomp/pr89015.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr89015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nested.c

[Bug target/88998] [7/8/9 Regression] bad codegen with mmx instructions for unordered_map

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #8 from Uroš Bizjak  ---
Fixed everywhere.

[Bug c++/88976] [7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2552

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 24 19:16:21 2019
New Revision: 268245

URL: https://gcc.gnu.org/viewcvs?rev=268245=gcc=rev
Log:
PR c++/88976
* c-typeck.c (c_finish_omp_cancel): Diagnose more than one if
on #pragma omp cancel with different modifiers.

* semantics.c (finish_omp_cancel): Diagnose more than one if
on #pragma omp cancel with different modifiers.  Use
maybe_convert_cond when not in template or build_x_binary_op
otherwise.

* c-c++-common/gomp/cancel-2.c: New test.
* gcc.dg/gomp/cancel-1.c: New test.
* g++.dg/gomp/cancel-1.C: New test.
* g++.dg/gomp/cancel-2.C: New test.
* g++.dg/gomp/cancel-3.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/cancel-2.c
trunk/gcc/testsuite/g++.dg/gomp/cancel-1.C
trunk/gcc/testsuite/g++.dg/gomp/cancel-2.C
trunk/gcc/testsuite/g++.dg/gomp/cancel-3.C
trunk/gcc/testsuite/gcc.dg/gomp/cancel-1.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89027] [9 Regression] ICE: verify_gimple failed (Error: non-trivial conversion at assignment)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 24 19:14:51 2019
New Revision: 268243

URL: https://gcc.gnu.org/viewcvs?rev=268243=gcc=rev
Log:
PR tree-optimization/89027
* tree-inline.c (add_clobbers_to_eh_landing_pad): Don't add clobbers
for "omp simd array" variables.

* gfortran.dg/gomp/pr89027.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr89027.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug target/88998] [7/8/9 Regression] bad codegen with mmx instructions for unordered_map

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 24 19:14:58 2019
New Revision: 268244

URL: https://gcc.gnu.org/viewcvs?rev=268244=gcc=rev
Log:
PR target/88998
* config/i386/sse.md (sse2_cvtpi2pd): Add SSE alternatives.
Disparage MMX alternative.
(sse2_cvtpd2pi): Ditto.
(sse2_cvttpd2pi): Ditto.

testsuite/ChangeLog:

PR target/88998
* g++.dg/pr88998.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/pr88998.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/sse.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/89048] New: constant evaluation in trailing return type rejected

[barry.revzin at gmail dot com]

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

Bug ID: 89048
   Summary: constant evaluation in trailing return type rejected
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This program is rejected by gcc:

template  struct X { };
template  constexpr auto f(F f) -> X { return {}; }

with:

source>:3:53: error: template argument 1 is invalid
3 | template  constexpr auto f(F f) -> X { return {}; }
  | ^
:3:53: error: template argument 1 is invalid
:3:53: error: template argument 1 is invalid
:3:53: error: template argument 1 is invalid
:3:48: error: invalid template-id
3 | template  constexpr auto f(F f) -> X { return {}; }
  |^
:3:51: error: use of parameter outside function body before '(' token
3 | template  constexpr auto f(F f) -> X { return {}; }
  |   ^
:3:38: error: deduced class type 'X' in function return type
3 | template  constexpr auto f(F f) -> X { return {}; }
  |  ^
:1:25: note: 'template struct X' declared here
1 | template  struct X { };
  | ^
Compiler returned: 1

On the other hand, this program is accepted:

template  struct X { };
template  constexpr auto g(F f) { return X{}; }

Clang accepts both. I think both programs are valid.

[Bug target/88998] [7/8/9 Regression] bad codegen with mmx instructions for unordered_map

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 24 19:12:55 2019
New Revision: 268242

URL: https://gcc.gnu.org/viewcvs?rev=268242=gcc=rev
Log:
PR target/88998
* config/i386/sse.md (sse2_cvtpi2pd): Add SSE alternatives.
Disparage MMX alternative.
(sse2_cvtpd2pi): Ditto.
(sse2_cvttpd2pi): Ditto.

testsuite/ChangeLog:

PR target/88998
* g++.dg/pr88998.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/pr88998.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/sse.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
One can reproduce that with Intel SDE simulator:
https://software.intel.com/protected-download/267266/144917

$ ./sde-external-8.16.0-2018-01-30-lin/sde -skx -- /tmp/a.out
wrong at: 3: is 15, should be 17
Aborted (core dumped)

[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
(In reply to rsand...@gcc.gnu.org from comment #16)
> Created attachment 45526 [details]
> Passing testcase
> 
> I'm still not sure where the problem is coming in.  The loop in the vector
> dump looks functionally correct now I've had change to look at it more
> (contrary to my initial comment on IRC).  It seems to be equivalent to the
> attached, which passed on an AVX2 box I found I had accesss to.

But it fails on a skylake-avx512 machine. Minimal test-case that fails:

$ cat avx.c
struct s { unsigned long a, b, c; };

void __attribute__ ((noipa))
f (struct s *restrict s1, struct s *restrict s2, int n)
{
  for (int i = 0; i < n; ++i)
{
  s1[i].b = s2[i].b;
  s1[i].c = s2[i].c;
  s2[i].c = 0;
}
}

#define N 6

int
main (void)
{
  struct s s1[N], s2[N];
  for (unsigned int j = 0; j < 6; ++j)
  {
  s2[j].a = j * 5;
  s2[j].b = j * 5 + 2;
  s2[j].c = j * 5 + 4;
  }
  f (s1, s2, 6);
  for (unsigned int j = 0; j < 6; ++j)
  if (s1[j].b != j * 5 + 2)
  {
  __builtin_printf ("wrong at: %d: is %d, should be %d\n", j,
s1[j].b, j * 5 + 2);
  __builtin_abort ();
  }

__builtin_printf ("OK\n");
  return 0;
}

$ gcc -march=skylake-avx512 avx.c -g && ./a.out  && gcc -march=skylake-avx512
avx.c -g -O3 && ./a.out 
OK
wrong at: 3: is 15, should be 17
Aborted (core dumped)

[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
This fixes also libgomp.fortran/taskloop3.f90. Thanks.

[Bug c++/88951] [9 Regression] No fpermissive offerred on 'error: jump to case label'

[sbence92 at gmail dot com]

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

--- Comment #4 from Bence Szabó  ---
Ok, I agree with all of what you wrote. Please close the PR as you wish.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

[ibuclaw at gdcproject dot org]

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

--- Comment #5 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #4)
> ported to as many platforms as possible.  Then switch over to the D branch
> and be in lock-step with upstream dmd with regards to the latest
> implementation.

I mean, as of gdc 10, so version 9 becomes the baseline for bootstrapping
latter versions.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

[ibuclaw at gdcproject dot org]

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

--- Comment #4 from Iain Buclaw  ---
(In reply to G. Steinmetz from comment #3)
> 
> Commit was from 2018-01-14, i.e. over a year ago.
> That makes me wonder, when will gdc be synchronized with dmd ?
> 

The main dmd branch has been converted over to D as of v2.069.  Whereas gdc is
a continuation of the old C++ branch, with new features and bug fixes converted
back to C++.  Its equivalence is v2.076, with a few extra regression patches.

Reason for staying with the C++ branch is so that gdc 9 release can be ported
to as many platforms as possible.  Then switch over to the D branch and be in
lock-step with upstream dmd with regards to the latest implementation.

[Bug fortran/89047] ICE in mark_scope_block_unused, at tree-ssa-live.c:391

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> With option -fopenacc, down to at least version 5 :

-fopenacc is new in GCC-5.

For trunk (9.0) on darwin with --enable-checking=yes, I get

during GIMPLE pass: omplower
pr89047.f90:2:0:

2 |!$acc update device (f)
  | 
internal compiler error: in get, at cgraph.h:2579

with/without -O2 or -g.

[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-24
 CC||msebor at gcc dot gnu.org
  Component|preprocessor|c++
 Ever confirmed|0   |1
  Known to fail||4.3.5, 4.4.7, 4.8.5, 4.9.4,
   ||5.4.0, 6.4.0, 7.3.0, 8.2.0,
   ||9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  It works correctly in C but has never worked in C++ so it's not a
regression.

[Bug c/89035] Request - builtins for unspecified and arbitrary values

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
Note that an uninitialized local variable has an indeterminate value which,
even if it's not a trap representation, can appear to change from one instance
to another, and whose use results in undefined behavior (see also
https://gcc.gnu.org/ml/gcc/2019-01/msg00199.html).

[Bug c/89045] New: [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518

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

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

Bug ID: 89045
   Summary: [9 Regression] ICE in get_parm_info, at
c/c-decl.c:7518
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed before 20180429, gcc-8 compiles it :


$ cat z1.c
void f (int x)
{
  void g (int [(int){ x }]);
}


$ gcc-8 -c z1.c
$
$ gcc-9-20190120 -c z1.c
z1.c: In function 'f':
z1.c:3:3: internal compiler error: in get_parm_info, at c/c-decl.c:7518
3 |   void g (int [(int){ x }]);
  |   ^~~~
0x5e0b57 get_parm_info(bool, tree_node*)
../../gcc/c/c-decl.c:7518
0x6226a8 c_parser_parms_list_declarator
../../gcc/c/c-parser.c:4024
0x622810 c_parser_parms_declarator
../../gcc/c/c-parser.c:3940
0x61c491 c_parser_direct_declarator_inner
../../gcc/c/c-parser.c:3868
0x630731 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1999
0x62ffba c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5068
0x6300a6 c_parser_compound_statement
../../gcc/c/c-parser.c:4980
0x63180a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2352
0x6368b3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x637379 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x637379 c_parse_file()
../../gcc/c/c-parser.c:19840
0x67d7f0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155

[Bug tree-optimization/88760] GCC unrolling is suboptimal

[ktkachov at gcc dot gnu.org]

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

--- Comment #22 from ktkachov at gcc dot gnu.org ---
Some more experiments...
Unrolling 4x in a similar way to my previous example and not splitting the
accumulator (separate issue):

unsigned int *colnums;
double *val;

struct foostruct
{
  unsigned int rows;
  unsigned int *colnums;
  unsigned int *rowstart;
};

struct foostruct *cols;

void
foo (double * __restrict__ dst, const double *__restrict__ src)
{
  const unsigned int n_rows = cols->rows;
  const double *val_ptr = [cols->rowstart[0]];
  const unsigned int *colnum_ptr = >colnums[cols->rowstart[0]];  

  double *dst_ptr = dst;
  for (unsigned int row=0; rowrowstart[row+1]];
  __PTRDIFF_TYPE__ diff = val_end_of_row - val_ptr;
  if (diff & 1)
  {
s += *val_ptr++ * src[*colnum_ptr++];
diff--;
  }
  if (diff & 2)
{
  s += val_ptr[0] * src[colnum_ptr[0]];
  s += val_ptr[1] * src[colnum_ptr[1]];
  val_ptr += 2;
  colnum_ptr += 2;
}
  while (val_ptr != val_end_of_row)
{
  s += val_ptr[0] * src[colnum_ptr[0]];
  s += val_ptr[1] * src[colnum_ptr[1]];
  s += val_ptr[2] * src[colnum_ptr[2]];
  s += val_ptr[3] * src[colnum_ptr[3]];
  val_ptr += 4;
  colnum_ptr += 4;
}
  *dst_ptr++ = s;
}
}

helps even more. On Cortex-A72 it gives a bit more than 6% (vs 3%) improvement
on parest, and about 5.3% on a more aggressive CPU.
I tried unrolling 8x in a similar manner and that was not faster than 4x on
either target.

Note that perf profiling shows that the loads are what's hot in these loops,
not the FMAs themselves:
  4.41 │1b8:   ldpw3, w4, [x0] 
   
   ▒
  5.85 │   ldpd3, d4, [x2] 
   
   ▒
   │   addx2, x2, #0x20
   
   ▒
  3.79 │   ldur   d5, [x2, #-16]   
   
   ▒
  2.82 │   ldrd0, [x1, x4, lsl #3] 
   
   ▒
  2.53 │   ldrd2, [x1, x3, lsl #3] 
   
   ▒
  2.10 │   ldpw4, w3, [x0, #8] 
   
   ▒
   │   addx0, x0, #0x10
   
   ▒
  0.00 │   cmpx5, x0   
   
   ▒
   │   fmul   d0, d0, d4   
   
   ▒
  4.73 │   ldrd4, [x1, x4, lsl #3] 
   
   ▒
   │   fmadd  d0, d3, d2, d0   
   
   ▒
  2.01 │   ldur   d3, [x2, #-8]
   
   ▒
  2.54 │   ldrd2, [x1, x3, lsl #3] 
   
   ▒
   │   fmadd  d0, d5, d4, d0   
   
   ▒
   │   fmadd  d0, d3, d2, d0   
   

[Bug gcov-profile/89046] New: GCOV generates incorrect results for C++ Lambda / Constructor

[boazstud at yahoo dot com]

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

Bug ID: 89046
   Summary: GCOV generates incorrect results for C++ Lambda /
Constructor
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boazstud at yahoo dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45527=edit
bug.ii

It seems that gcov-8 does not report executed lines inside a lambda created in
a constructor of a class.
This worked fine with gcov-5

A minimal code that triggers the bug is attached.
in this code, printf is executed but not reported by gcov.
 CUT HERE 
#include 

struct test {
void (*fn)();
test(void(*fn_)()) : fn(fn_) {}
};

test x([](){ 
printf("hello, world\n"); 
});

int main() {
  x.fn();
  return 0;
}



=
gcc bug.cc --coverage -save-temps

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.2.0-7ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-7ubuntu1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-coverage' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE bug.cc -mtune=generic -march=x86-64
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o bug.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-coverage' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -fpreprocessed bug.ii -quiet -dumpbase
bug.cc -mtune=generic -march=x86-64 -auxbase bug -version -fprofile-arcs
-ftest-coverage -fstack-protector-strong -Wformat -Wformat-security -o bug.s
GNU C++14 (Ubuntu 8.2.0-7ubuntu1) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 8.2.0-7ubuntu1) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c4394fed592bafb9d6390822500e3507
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-coverage' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.31.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.31.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-coverage' '-mtune=generic'
'-march=x86-64'
 

[Bug fortran/89047] New: ICE in mark_scope_block_unused, at tree-ssa-live.c:391

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

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

Bug ID: 89047
   Summary: ICE in mark_scope_block_unused, at tree-ssa-live.c:391
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -fopenacc, down to at least version 5 :


$ cat z1.f90
real function f()
   !$acc update device (f)
end


$ gfortran-9-20190120 -c z1.f90 -fopenacc
during RTL pass: expand
z1.f90:1:0:

1 | real function f()
  |
internal compiler error: Segmentation fault
0xb3658f crash_signal
../../gcc/toplev.c:326
0x77c937 clear_tree_used
../../gcc/cfgexpand.c:1753
0x788d9a expand_used_vars
../../gcc/cfgexpand.c:2080
0x78aca2 execute
../../gcc/cfgexpand.c:6376

---

$ gfortran-9-20190120 -c z1.f90 -fopenacc -O2 -g
$
$ gfortran-9-20190120 -c z1.f90 -fopenacc -O2
during GIMPLE pass: ssa
z1.f90:3:0:

3 | end
  |
internal compiler error: Segmentation fault
0xb3658f crash_signal
../../gcc/toplev.c:326
0xc2a3f1 mark_scope_block_unused
../../gcc/tree-ssa-live.c:391
0xc2a41a mark_scope_block_unused
../../gcc/tree-ssa-live.c:395
0xc2b751 remove_unused_locals()
../../gcc/tree-ssa-live.c:741
0xa70f44 execute_function_todo
../../gcc/passes.c:1955
0xa71e32 execute_todo
../../gcc/passes.c:2031

[Bug ipa/89009] [7/8/9 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug ipa/89009] [7/8/9 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|6.5.0   |4.9.4
  Known to fail||5.5.0, 6.4.0

--- Comment #10 from Martin Liška  ---
Ok, so it's as old as ICF. There's a minimal test-case:

$ cat test.cc
#pragma GCC visibility push(default)
void foo1() { __builtin_printf ("foo\n"); }
#pragma GCC visibility pop
void foo2() { __builtin_printf ("foo\n"); }

int main() { foo2(); }

(for older revisions than r244273 one needs:

$ cat test.cc
void foo2() { __builtin_printf ("foo\n"); }

#pragma GCC visibility push(default)
void foo1() { __builtin_printf ("foo\n"); }
#pragma GCC visibility pop
int main() { foo2(); }

[Bug fortran/89039] Logical read from stream file that is neither 0 nor 1

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> ... so I agree that the proper flag for this report is INVALID.

Then closing.

[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #7 from Sebastian Pop  ---
I think the patch is ok.

If in the future we want to handle those other loops, we will need to compute
the loop bound in add_loop_constraints() with a check for whether the stmt is
dominated by the exit or not.

Here is what we do today for all stmts in the loop:

  tree nb_iters = number_of_latch_executions (loop);
  if (TREE_CODE (nb_iters) == INTEGER_CST)
{
  /* loop_i <= cst_nb_iters */

the constraint '<=' on statements' iteration domains implies that the loop
should be under a do-while form.

[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[rsandifo at gcc dot gnu.org]

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

--- Comment #16 from rsandifo at gcc dot gnu.org  
---
Created attachment 45526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45526=edit
Passing testcase

I'm still not sure where the problem is coming in.  The loop in the vector dump
looks functionally correct now I've had change to look at it more (contrary to
my initial comment on IRC).  It seems to be equivalent to the attached, which
passed on an AVX2 box I found I had accesss to.

[Bug ipa/89009] [7/8/9 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Martin Liška  ---
Thanks for it, confirmed! Started with r244273, but the revision probably only
exposed a latent issue.

[Bug c/44715] Break in increment expression of "for" statement inconsistent with g++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Should be fixed for GCC 9+.

[Bug c++/88984] [9 Regression] ICE in genericize_switch_stmt, at cp/cp-gimplify.c:377

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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