[Bug c++/82336] [5/6/7/8 Regression] GCC requires but does not emit defaulted constructors in certain cases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-27
  Known to work||4.7.4
Summary|GCC requires but does not   |[5/6/7/8 Regression] GCC
   |emit defaulted constructors |requires but does not emit
   |in certain cases|defaulted constructors in
   ||certain cases
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.4.0, 6.4.0,
   ||7.2.0, 8.0

[Bug c++/82334] improve list of candidates for a member definition that doesn't match declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/82337] -O2: ICE: SSA corruption at tree-ssa-coalesce.c:1010

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |8.0

--- Comment #3 from Andrew Pinski  ---
Related to PR 82264 and PR 71020.

[Bug tree-optimization/82337] -O2: ICE: SSA corruption at tree-ssa-coalesce.c:1010

[ivo.raisr at oracle dot com]

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

--- Comment #2 from Ivo Raisr  ---
Created attachment 42241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42241=edit
reduced-3.c (slightly reformatted source to make it more readable)

[Bug tree-optimization/82337] -O2: ICE: SSA corruption at tree-ssa-coalesce.c:1010

[ivo.raisr at oracle dot com]

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

Ivo Raisr  changed:

   What|Removed |Added

 CC||ivo.raisr at oracle dot com

--- Comment #1 from Ivo Raisr  ---
Created attachment 42240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42240=edit
reduced-3.bare.c (output produced by C-reduce)

[Bug tree-optimization/82337] New: -O2: ICE: SSA corruption at tree-ssa-coalesce.c:1010

[ivo.raisr at oracle dot com]

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

Bug ID: 82337
   Summary: -O2: ICE: SSA corruption at tree-ssa-coalesce.c:1010
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivo.raisr at oracle dot com
  Target Milestone: ---

With gcc 8.0, 7.2 and 6.3.1 we hit internal compiler error:

Unable to coalesce ssa_names 7 and 15 which are marked as MUST COALESCE.
i_7(ab) and  i_15(ab)
during RTL pass: expand
reduced-3.c:12:6: internal compiler error: SSA corruption
 void g(void) {
  ^
0xe24c8c fail_abnormal_edge_coalesce
../../gcc-trunk/gcc/tree-ssa-coalesce.c:1010
0xe24c8c coalesce_partitions
../../gcc-trunk/gcc/tree-ssa-coalesce.c:1399
0xe24c8c coalesce_ssa_name()
../../gcc-trunk/gcc/tree-ssa-coalesce.c:1886
0xdca93b remove_ssa_form
../../gcc-trunk/gcc/tree-outof-ssa.c:948
0xdca93b rewrite_out_of_ssa(ssaexpand*)
../../gcc-trunk/gcc/tree-outof-ssa.c:1172
0x992d70 execute
../../gcc-trunk/gcc/cfgexpand.c:6164


Full pre-processed sources are not publicly available.

C-reduce was able to produce "reduced-3.bare.c" which I slightly reformatted to
make it more readable: "reduced-3.c". Both files attached.

Reproduce as:
$ gcc -c reduced-3.c -O2

[Bug c++/82336] New: GCC requires but does not emit defaulted constructors in certain cases

[m101010a at gmail dot com]

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

Bug ID: 82336
   Summary: GCC requires but does not emit defaulted constructors
in certain cases
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

When compiling the following source file, gcc requires a definition for
bar::bar() but does not emit one, causing a linker error:

$ cat x.cpp
struct foo { int x = 5; };
struct bar : foo { bar() = default; };
struct baz { bar x; };
void qux(baz = {}){}
int main() { qux(); }
$ g++ -v -Wall -Wextra x.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/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
Thread model: posix
gcc version 7.1.1 20170630 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-Wall' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -g -Wall -Wextra
-std=c++11 -version -o /tmp/ccwPoekN.s
GNU C++11 (GCC) version 7.1.1 20170630 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170630, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed
 /usr/include
End of search list.
GNU C++11 (GCC) version 7.1.1 20170630 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170630, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 53125f87ce78f0cf5a177bd50a2fd619
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-Wall' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccXARTmy.o /tmp/ccwPoekN.s
GNU assembler version 2.28.0 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.28.0.20170506
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-Wall' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccvOLjqj.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../..
/tmp/ccXARTmy.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/crtn.o
/tmp/ccXARTmy.o: In 

[Bug c++/59552] Warning when non-trivial type parameter is passed by value but not changed in function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> The request refers to arguments of non-trivial types but I think it's just
> as applicable to trivial types, if not more.  A test case for an
> expensive-to-copy trivial type might look something like this.  The caller
> of f0() must make a copy of x but the caller of g0() need not, and GCC just
> passes the address of x to it.  Since the definition of f0() doesn't change
> the argument, it would be more efficient if the caller didn't have to make
> the copy.  In C++, GCC could suggest to declare f0() to take its argument by
> const reference instead.  (In C, it could suggest to take it by const
> pointer.)  In addition, declaring the const reference or pointer argument
> restrict would make it clear that the callee doesn't change the argument
> when it's passed by reference (this optimization is the subject of pr81009).
> 
> typedef struct Big {
>   char a[32];
> } Big;
> 
> int __attribute__ ((noclone, noinline))
> f0 (Big x)   // suggest to declare f0 (const Big&) instead
> { return __builtin_strlen (x.a); }
> 
> int __attribute__ ((noclone, noinline))
> g0 (const Big *x) { return __builtin_strlen (x->a); }
> 
> extern Big x;
> 
> int f1 (void)
> {
>   int n = f0 (x);
>   return n + 1;
> }
> 
> int g1 (void)
> {
>   int n = g0 ();
>   return n + 1;
> }
> 
> I suspect the request for a warning for non-trivial types is based on the
> assumption that such a type is expensive to copy.  That may or may not be
> true depending on the definition of the type but regardless, I think there
> is an opportunity here for GCC to help users write more efficient code.

OK, thanks, confirmed then.

[Bug c++/59552] Warning when non-trivial type parameter is passed by value but not changed in function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The request refers to arguments of non-trivial types but I think it's just as
applicable to trivial types, if not more.  A test case for an expensive-to-copy
trivial type might look something like this.  The caller of f0() must make a
copy of x but the caller of g0() need not, and GCC just passes the address of x
to it.  Since the definition of f0() doesn't change the argument, it would be
more efficient if the caller didn't have to make the copy.  In C++, GCC could
suggest to declare f0() to take its argument by const reference instead.  (In
C, it could suggest to take it by const pointer.)  In addition, declaring the
const reference or pointer argument restrict would make it clear that the
callee doesn't change the argument when it's passed by reference (this
optimization is the subject of pr81009).

typedef struct Big {
  char a[32];
} Big;

int __attribute__ ((noclone, noinline))
f0 (Big x)   // suggest to declare f0 (const Big&) instead
{ return __builtin_strlen (x.a); }

int __attribute__ ((noclone, noinline))
g0 (const Big *x) { return __builtin_strlen (x->a); }

extern Big x;

int f1 (void)
{
  int n = f0 (x);
  return n + 1;
}

int g1 (void)
{
  int n = g0 ();
  return n + 1;
}

I suspect the request for a warning for non-trivial types is based on the
assumption that such a type is expensive to copy.  That may or may not be true
depending on the definition of the type but regardless, I think there is an
opportunity here for GCC to help users write more efficient code.

[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
A side note for folks.  One can:

use iso_fortran_env

and then inquire about what kinds are supported with:

real_kinds or integer_kinds which are set to an array of values.

On my system here:

program quick
  use iso_fortran_env
  print *, real_kinds
end program

$ gfc quick.f90 
$ ./a.out 
   4   8  10  16

On Raspberry pi (arm) is gives:

   4   8

[Bug objc/80912] enhancement: -Wundeclared-selector improvements

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/59552] Warning when non-trivial type parameter is passed by value but not changed in function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Could you give an example testcase please?

[Bug c/55791] gcc fails to detect wrong type in sizeof in malloc

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
Confirmed, I think I've probably made this mistake myself before, actually

[Bug target/60337] s390: Function arguments are not aligned

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-27
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
Since this has an assignee I'm changing the status to ASSIGNED

[Bug c/57021] Better error message for * missing an expression or rather using a non-type as a cast

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-27
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed that this diagnostic could be improved.

[Bug c++/55361] Access control in templates only happens when instantiating a method

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #4)
> unless this is recategorised as a diagnostic enhancement request this is
> clearly invalid, the compiler is not required to give an error for this code

Since this has since been recategorized as an enhancement, I'm confirming it.

[Bug c++/55767] flowing off end of function which returns a value isn't treated as an error by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
Yup, -Werror=return-type makes gcc reject the reporter's example:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Werror=return-type 55767.cc
55767.cc: In function ‘int& foo()’:
55767.cc:3:13: error: no return statement in function returning non-void
[-Werror=return-type]
 int& foo() {}
 ^
cc1plus: some warnings being treated as errors
$

(In reply to Jonathan Wakely from comment #1)
> It's not always possible to make it a hard error and refuse to compile the
> code. The function might call a function that never returns (but isn't
> marked with a noreturn attribute) or might be of the form:
> 
>   int& f(bool b) {
> if (b) {
>   static int i;
>   return i;
> }
>   }
> 
> If this is never called with a false argument there's no problem. If it's
> never called at all there's no problem.
> 
> Unless GCC's flow analysis is improved I think the most you can hope for is
> enabling -Wreturn-type by default.
> 

There's several bugs with -Wreturn-type I'd like to see fixed before enabling
it by default, for example, bug 55976, bug 68336, and bug 60440

> I use -Werror=return-type, the warning's there already, use it if you want
> it.

Since that works in this case, I'm closing this bug as INVALID.

[Bug c++/55254] Warn for implicit conversion from int to char

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
I made a fuller testcase:

$ cat 55254.cc
#include 

int foo(int eighty)
{
std::string foo = std::string(80, '=');
std::string bar = std::string('=', 80);
std::string baz = std::string(int('='), eighty);
(void)foo;
(void)bar;
(void)baz;
if (eighty == 0) {
eighty = '=';
return eighty;
}
return 80;
}
$ /usr/local/bin/g++ -c -Wall -Wextra -Wnarrowing -Wsign-conversion
-Wconversion -pedantic -Weffc++ 55254.cc
55254.cc: In function ‘int foo(int)’:
55254.cc:7:48: warning: conversion from ‘int’ to ‘char’ may change value
[-Wconversion]
  std::string baz = std::string(int('='), eighty);
^
$

So, I get a warning, but not where the reporter was requesting it (which is
probably my fault). Confirmed that there could still be a warning for bar.

[Bug c/82335] New: Incorrect _Pragma expansion with in complex macro expressions

[pskocik at gmail dot com]

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

Bug ID: 82335
   Summary: Incorrect _Pragma expansion with in complex macro
expressions
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

Created attachment 42239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42239=edit
reproducer for "Incorrect _Pragma expansion with in complex macro expressions";
compile with -Wall -Wextra

Basically, _Pragma's expansions (as shown with gcc -E) seem to get shifted out
of some slightly "more complex" macro expressions, which renders them
ineffective.

Attached is one piece of code that reproduces the problem. When compiled with
`-Wall -Wextra`, the warning which should've been silenced isn't, because the
#pragma push-pop pair gets shifted out of the expression.

It's hard to pinpoint exactly what causes this, and the problem goes away with
minor complexity reductions (such as replacing a macro (e.g., the tof macro)
with what it expands to), but it seems to stick in more complex contexts.

clang handles everything fine.

[Bug middle-end/31377] wrap_help error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-27
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|minor   |trivial

--- Comment #1 from Eric Gallager  ---
Confirmed that wrap_help in gcc/opts.c still has the code in question; please
submit a patch to the gcc-patches mailing list for review.

[Bug c++/51066] [C++0x] warning about binding an rvalue-reference to an implicit conversion result

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Confirmed that there is currently no warning.

[Bug c/44854] Improve diagnostic for missing member name or ';' in a struct

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-27
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44515
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Current gcc now says:

$ /usr/local/bin/gcc -c 44854.c
44854.c:1:18: warning: declaration does not declare anything
 struct foo { int };
  ^
44854.c:1:18: warning: no semicolon at end of struct or union
$

This is better than before, but I guess it could still be improved though. So,
confirmed. Related to bug 44515.

[Bug fortran/81509] Wrong compilation error: iand/ieor/ior + boz + -std=f2008

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P5  |P4
 CC||kargl at gcc dot gnu.org
   Severity|enhancement |normal

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

[peter at cordes dot ca]

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

--- Comment #1 from Peter Cordes  ---
There's  __m128i _mm_loadl_epi64 (__m128i const*
mem_addr)(https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=movq=5450,4247,3115=SSE2),
which gcc makes available in 32-bit mode.

This does solve the correctness problem for 32-bit, but gcc still compiles it
to a separate vmovq before a vpmovzxbd %xmm,%ymm.  (Using _mm_loadu_si128 still
optimizes away to vpmovzxbd (%eax), %ymm0.)

https://godbolt.org/g/Zuf26P

[Bug c++/82334] New: improve list of candidates for a member definition that doesn't match declaration

[msebor at gcc dot gnu.org]

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

Bug ID: 82334
   Summary: improve list of candidates for a member definition
that doesn't match declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When the prototype of a member function definition doesn't match its
declaration GCC prints an error followed by a list of candidate overloads of
the member function.  That helpful but not as much as it could be.  It would be
even more useful if the note for each candidate indicated the way in which it
differs from the prototype of the definition, e.g., by underlining a missing
qualifier.

The test case below shows how the current note is less than optimal:

$ cat a.C && gcc -O2 -S -Wall -Wextra a.C
struct S {
  typedef int descriptor_t;
  typedef double real_t;
  typedef const char *strptr_t;
  typedef void *handle_t;

  int f (int, double, const char*, void*) const;
};

int S::f (descriptor_t, real_t, strptr_t, handle_t)
{
  return 0;
}
a.C:10:5: error: no declaration matches ‘int S::f(S::descriptor_t, S::real_t,
S::strptr_t, S::handle_t)’
 int S::f (descriptor_t, real_t, strptr_t, handle_t)
 ^
a.C:7:7: note: candidate is: ‘int S::f(int, double, const char*, void*) const’
   int f (int, double, const char*, void*) const;
   ^
a.C:1:8: note: ‘struct S’ defined here
 struct S {
^


In contrast, Clang emits a more helpful note:

.C:10:8: error: out-of-line definition of 'f' does not match any declaration in
  'S'
int S::f (descriptor_t, real_t, strptr_t, handle_t)
   ^
t.C:7:7: note: member declaration does not match because it is const qualified
  int f (int, double, const char*, void*) const;
  ^   ~
1 error generated.

[Bug c++/44263] missing diagnostic on questionable array sizes with -pedantic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
I get a warning for g with -pedantic:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44263.cc
44263.cc: In function ‘void foo()’:
44263.cc:12:39: warning: size of array is not an integral constant-expression
[-Wpedantic]
  char g[(char *) &((struct S *) 0)->b - (char *) 0];
 ~~^~~~
$

But I'm assuming you're still requesting another warning for h? Confirmed in
that case.

[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
For test I have checked

1 format(i5)
print'()j'
end

I get

000f   m   t   .   f   9   0   :   2   :   1   6   :  nl  nl  sp
020p   r   i   n   t   '   (   )   j   '  nl  sp  sp  sp  sp  sp
040   sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp   1  nl   W   a   r
060n   i   n   g   :  sp   E   x   t   r   a   n   e   o   u   s
100   sp   c   h   a   r   a   c   t   e   r   s  sp   i   n  sp   f
120o   r   m   a   t  sp   a   t  sp   (   1   )  nl
135

For

print'()j'
end

I get

 print'()j'
1
Warning: Extraneous characters in format at (1)

or

000f   m   t   .   f   9   0   :   1   :   8   :  nl  nl  sp   p
020r   i   n   t   '   (   )   j   '  nl  sp  sp  sp  sp  sp  sp
040   sp  sp   1  nl   W   a   r   n   i   n   g   :  sp   E   x   t
060r   a   n   e   o   u   s  sp   c   h   a   r   a   c   t   e
100r   s  sp   i   n  sp   f   o   r   m   a   t  sp   a   t  sp

(and 9 sp would be better).

[Bug c++/49574] Give a warning for insane overloading

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=51277,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69855
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirming that in general warnings about insane overloading would be nice to
have; related to bug 51277 and bug 69855 and possibly others

[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
I think the glibc reasoning is: libm functions do not need to behave as if 
written in standard C, so in particular F.6 does not apply to them and 
they may return values with excess precision.  Thus libm functions use 
math_narrow_eval (or equivalent assembler macros) in cases where there may 
be overflow and underflow (where excess *range* may be a problem, possibly 
resulting in missing errno setting), but not where there may be excess 
precision without excess range.  (Functions with fully defined results 
such as sqrt still take care to avoid excess precision in their results.)

However, that then implies GCC ought to know which standard library 
functions (only) might return with excess precision, so that casts / 
assignments of the results of those functions can remove that excess 
precision.  Which is tricky, both because it should only apply to standard 
library functions, not to user functions where it's the user's 
responsibility to compile consistently with -fexcess-precision=standard, 
and because the IR available in the front end does not represent the ABI 
information that particular return types are capable of being returned 
with excess precision (you'd need to distinguish a function's ABI return 
type from its semantic return type and produce calls with the ABI return 
type).

Or you could systematically use math_narrow_eval on all float / double 
function returns that might have excess range / precision (or maybe in the 
wrappers where wrappers are used, to avoid affecting glibc-internal uses 
that don't need this as well as to reduce the number of places needing 
changing - but if you do it in the wrappers you don't fix things for the 
__*_finite functions), but there would be some performance cost to doing 
so.

[Bug c++/46224] Enhancement: Issue warning when matching placement delete operator is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
No they're completely unrelated. Remove throw(std::bad_alloc) from both
testcases to prevent those warnings.

Here's a C++11 version of comment 1:

using size_t = decltype(sizeof(0));

void* operator new( size_t num_bytes, const char* );

struct Foo
{
Foo() { throw int(); }
};

void f()
{
Foo* p = new(__FILE__) Foo();
}

EDG prints:

"del.cc", line 12: warning: function "operator new(size_t, const char *)" has
  no corresponding operator delete (to be called if an exception is
  thrown during initialization of an allocated object)
  Foo* p = new(__FILE__) Foo();
   ^

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

[jsm28 at gcc dot gnu.org]

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

Bug ID: 82333
   Summary: [8 Regression] powerpc64le _Float128 ICE in as_a, at
machmode.h:345
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux-gnu

The following code, compiled with -O2 for powerpc64le-linux-gnu, produces the
following ICE.  This is a regression from GCC 7 (note you need -mfloat128 to
build with older compilers), reduced from glibc test-tgmath3, and probably
postdates the change to enable _Float128 support by default for powerpc64le
(since the glibc test built before then, then glibc build for powerpc64le was
broken for a while, and by the time it was fixed this ICE appeared).  Note, you
need both the _Complex long double functions and the apparently independent
_Complex _Float128 functions for this ICE to appear.

_Complex long double vld;
_Complex _Float128 vf128;

_Complex long double
fld (_Complex long double arg0)
{
  return 0;
}

_Complex _Float128
ff128 (_Complex _Float128 arg0)
{
  return 0;
}

void
tld (void)
{
  vld = fld (vld);
}

void
tf128 (void)
{
  vf128 = ff128 (vf128);
}

during RTL pass: expand
test-tgmath3.i: In function 'tf128':
test-tgmath3.i:25:9: internal compiler error: in as_a, at machmode.h:345
   vf128 = ff128 (vf128);
   ~~^~~
0x839dec scalar_mode as_a(machine_mode)
/scratch/jmyers/glibc/many8/src/gcc/gcc/machmode.h:345
0x839dec convert_mode_scalar
/scratch/jmyers/glibc/many8/src/gcc/gcc/expr.c:281
0x839dec convert_move(rtx_def*, rtx_def*, int)
/scratch/jmyers/glibc/many8/src/gcc/gcc/expr.c:271
0x84091e store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/scratch/jmyers/glibc/many8/src/gcc/gcc/expr.c:5628
0x8424f0 expand_assignment(tree_node*, tree_node*, bool)
/scratch/jmyers/glibc/many8/src/gcc/gcc/expr.c:5319
0x71ff95 expand_gimple_stmt_1
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgexpand.c:3655
0x71ff95 expand_gimple_stmt
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgexpand.c:3751
0x722796 expand_gimple_basic_block
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgexpand.c:5750
0x7281a6 execute
/scratch/jmyers/glibc/many8/src/gcc/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 c++/47342] misleading diagnostic for member of undeclared class template partial specialization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed, with current gcc the diagnostic is:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 47342.cc
47342.cc:26:14: error: invalid use of incomplete type ‘struct X’
 X< Y >::f()// xxx
  ^
47342.cc:2:8: note: declaration of ‘struct X’
 struct X : T
^
$

...which could still be improved.

[Bug c/44515] improve message for missing ";"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 CC||dmalcolm at gcc dot gnu.org,
   ||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
Confirmed, I think David Malcolm is working on this...

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

[Melven.Roehrig-Zoellner at DLR dot de]

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

--- Comment #8 from Melven.Roehrig-Zoellner at DLR dot de ---
Could this still be fixed / filtered out in the ThreadSanitizer somehow?

Otherwise the problem persists that you get huge amounts of false positives
with gfortran.

(I'm sorry, but I don't know where this problem should get reported then...)

[Bug c++/46224] Enhancement: Issue warning when matching placement delete operator is missing

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I get the following warnings for the 1st testcase:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Weffc++ -Wplacement-new=2
46224.cc
46224.cc:12:13: warning: dynamic exception specifications are deprecated in
C++11 [-Wdeprecated]
int) throw (std::bad_alloc)
 ^
46224.cc: In function ‘int main()’:
46224.cc:32:10: warning: variable ‘f’ set but not used
[-Wunused-but-set-variable]
 Foo* f;
  ^
$

And similarly for the 2nd testcase:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Weffc++ -Wplacement-new=2
46224_a.cc
46224_a.cc:4:58: warning: dynamic exception specifications are deprecated in
C++11 [-Wdeprecated]
 void* operator new( std::size_t num_bytes, const char* ) throw
(std::bad_alloc);
  ^
46224_a.cc: In function ‘void f()’:
46224_a.cc:13:10: warning: unused variable ‘p’ [-Wunused-variable]
 Foo* p = new(__FILE__) Foo();
  ^
$

I don't think the -Wdeprecated warnings are really the same as what this bug
requests though? I dunno. Leaving UNCONFIRMED for now.

[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #6)
> > So, this is fixed.
> 
> Are you sure? I get
> 
>  print'()j'
> 1
> Warning: Extraneous characters in format at (1)
> 
> with 7.2 and a clean trunk.
> 
> IMO the marker should point to j.

Maybe we have different behavior on different systems,
depending on locale or who knows what else...

ig25@linux-d6cw:/tmp> /usr/bin/gfortran fmt.f90 2>&1 | od -a
000   f   m   t   .   f   9   0   :   1   :   8   :  nl  nl  sp   p
020   r   i   n   t  sp   '   (   )   j   '  nl  sp  sp  sp  sp  sp
040  sp  sp  sp   1  nl   W   a   r   n   i   n   g   :  sp   E   x
060   t   r   a   n   e   o   u   s  sp   c   h   a   r   a   c   t
100   e   r   s  sp   i   n  sp   f   o   r   m   a   t  sp   a   t
120  sp   (   1   )  nl

counts eight spaces before the "1" character.  What is the output on
your system?

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[kristerw at gcc dot gnu.org]

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

--- Comment #13 from Krister Walfridsson  ---
Author: kristerw
Date: Tue Sep 26 21:26:21 2017
New Revision: 253216

URL: https://gcc.gnu.org/viewcvs?rev=253216=gcc=rev
Log:
2017-09-26  Krister Walfridsson  

PR target/39570
* gcc/config/netbsd-protos.h: New file.
* gcc/config/netbsd.c: New file.
* gcc/config/netbsd.h (SUBTARGET_INIT_BUILTINS): Define.
* gcc/config/t-netbsd: New file.
* gcc/config.gcc (tm_p_file): Add netbsd-protos.h.
(tmake_file) Add t-netbsd.
(extra_objs) Add netbsd.o.

Added:
trunk/gcc/config/netbsd-protos.h
trunk/gcc/config/netbsd.c
trunk/gcc/config/t-netbsd
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/netbsd.h

[Bug fortran/82332] [8 regression] r253156 breaks test case gfortran.dg/predcom-1.f

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
Fixed.

[Bug c++/82331] ICE specializing template for function pointer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r249320, accepted before the revision.

[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> So, this is fixed.

Are you sure? I get

 print'()j'
1
Warning: Extraneous characters in format at (1)

with 7.2 and a clean trunk.

IMO the marker should point to j.

Running Enthusiasts List

[Karen Richards]

Hi,

Hope my email finds you fine.

Would you be interested in acquiring an email list of Running Enthusiasts from 
USA.

Our Databases:- 1. Tennis Enthusiasts 2. Sports Enthusiasts 3. Soccer 
Enthusiasts 4. Hiking Enthusiasts 5. Boxing Enthusiasts 6. Hockey Enthusiasts 
7. Golfers List 8. Basketball Enthusiasts 9. Baseball Enthusiasts 10. Camping 
and Outdoor Enthusiasts 11. Health and Fitness Enthusiasts 12. Skiers 
Enthusiasts many more..,

Information Fields:– Contact Name (First, Middle and Last Name), Mailing 
Address, List type and Opt-in email address.

All the contacts are opt-in verified, 100 percent permission based and can be 
used for unlimited multi-channel marketing.

Let me know if you'd be interested in hearing more information about it.

Thanks,
Karen Richards

[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Actually, the current message is:

ig25@linux-d6cw:/tmp> cat fmt.f90 
print '()j'
end
ig25@linux-d6cw:/tmp> gfortran fmt.f90 
fmt.f90:1:8:

 print '()j'
1
Warnung: Überschüssige Zeichen im Format bei (1)

So, this is fixed.

[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
This is another bug where we could just commit an
existing solution.

[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Sep 26 20:28:00 2017
New Revision: 253214

URL: https://gcc.gnu.org/viewcvs?rev=253214=gcc=rev
Log:
2017-09-26  Janus Weil  

PR fortran/82143
PR fortran/82324
* doc/sourcebuild.texi: Document fortran_real_10 and fortran_real_16.

2017-09-26  Janus Weil  

PR fortran/82143
PR fortran/82324
* lib/target-supports.exp (check_effective_target_fortran_real_10):
New.
* gfortran.dg/promotion_3.f90: Only run if real(16) is available.
* gfortran.dg/promotion_4.f90: Only run if real(10) is available.
Don't assume that DOUBLE PRECISION has kind=16.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/promotion_3.f90
trunk/gcc/testsuite/gfortran.dg/promotion_4.f90
trunk/gcc/testsuite/lib/target-supports.exp

[Bug fortran/82143] add a -fdefault-real-16 flag

[janus at gcc dot gnu.org]

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

--- Comment #25 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Sep 26 20:28:00 2017
New Revision: 253214

URL: https://gcc.gnu.org/viewcvs?rev=253214=gcc=rev
Log:
2017-09-26  Janus Weil  

PR fortran/82143
PR fortran/82324
* doc/sourcebuild.texi: Document fortran_real_10 and fortran_real_16.

2017-09-26  Janus Weil  

PR fortran/82143
PR fortran/82324
* lib/target-supports.exp (check_effective_target_fortran_real_10):
New.
* gfortran.dg/promotion_3.f90: Only run if real(16) is available.
* gfortran.dg/promotion_4.f90: Only run if real(10) is available.
Don't assume that DOUBLE PRECISION has kind=16.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/promotion_3.f90
trunk/gcc/testsuite/gfortran.dg/promotion_4.f90
trunk/gcc/testsuite/lib/target-supports.exp

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Thomas Koenig  ---
This isn't a bug, it is a false positive.

Closing.

[Bug fortran/82332] New: [8 regression] r253156 breaks test case gfortran.dg/predcom-1.f

[seurer at gcc dot gnu.org]

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

Bug ID: 82332
   Summary: [8 regression] r253156 breaks test case
gfortran.dg/predcom-1.f
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I saw this on powerpc64 both BE and LE.

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -O3 -S -o predcom-1.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f:12:53:
Warning: (1)
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f:11:72:
Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2)
output is:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f:12:53:
Warning: (1)
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f:11:72:
Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2)

FAIL: gfortran.dg/predcom-1.f   -O  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f:12:53:
Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2)
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/predcom-1.f:11:72:
Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2)

[Bug c++/82331] New: ICE specializing template for function pointer

[ambrop7 at gmail dot com]

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

Bug ID: 82331
   Summary: ICE specializing template for function pointer
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ambrop7 at gmail dot com
  Target Milestone: ---

The code below crashes the compiler (compile with -std=c++17).

gcccrash.cpp: In function ‘int test()’:
gcccrash.cpp:15:30: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:11514
 int test () { return X<>::call(1, 2); }


template 
class X;

template 
class X {
public:
static R call (A... args)
{
return (*F)(args...);
}
};

int func (int a, int b) { return a + b; }

int test () { return X<>::call(1, 2); }

[Bug lto/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
So another observation, it's not related to STB_GNU_UNIQUE.
Using --disable-gnu-unique-object:

$ readelf -s /home/marxin/bin/gcc3/lib64/libstdc++.so.6 --wide | grep storage
  1431: 0038dd6032 OBJECT  WEAK   DEFAULT   27
_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4
  4467: 0038dd8032 OBJECT  WEAK   DEFAULT   27
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4
  3633: 0038dd6032 OBJECT  WEAK   DEFAULT   27
_ZNSs4_Rep20_S_empty_rep_storageE
  4224: 0038dd8032 OBJECT  WEAK   DEFAULT   27
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE

$ grep storage pr82172-2.res 
1344 a6363178d2c55d5a PREVAILING_DEF_IRONLY _ZNSs4_Rep20_S_empty_rep_storageE

Still, similar problem, I will debug ld a bit tomorrow.

[Bug middle-end/45555] Add warnings for changes to code with option "-fipa-sra"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-26
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Could you give an example testcase that exhibits the changes you're worried
about?

[Bug other/82327] [7 Regression] ICE in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429 (i686-linux-gnu)

[costamagnagianfranco at yahoo dot it]

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

--- Comment #2 from Gianfranco  ---
I did add some info on the duplicate bug, I reduced the regression in a bunch
of commits (and a two days range).

[Bug other/82327] [7 Regression] ICE in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429 (i686-linux-gnu)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.3
   Severity|normal  |blocker

[Bug c++/82330] [7 regression] GCC ICE on i386 building llvm-toolchain-3.8 /<>/lib/Transforms/InstCombine/InstCombineAddSub.cpp:518:8: internal compiler error: in equal_mem_array_ref_p, a

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
Summary|[7 regression since some|[7 regression] GCC ICE on
   |days] GCC ICE on i386   |i386 building
   |building llvm-toolchain-3.8 |llvm-toolchain-3.8
   |/<>/lib/Transf |/<>/lib/Transf
   |orms/InstCombine/InstCombin |orms/InstCombine/InstCombin
   |eAddSub.cpp:518:8: internal |eAddSub.cpp:518:8: internal
   |compiler error: in  |compiler error: in
   |equal_mem_array_ref_p, at   |equal_mem_array_ref_p, at
   |tree-ssa-scopedtables.c:429 |tree-ssa-scopedtables.c:429

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug other/82327] [7 Regression] ICE in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429 (i686-linux-gnu)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||costamagnagianfranco@yahoo.
   ||it

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

[Bug c++/82330] New: [7 regression since some days] GCC ICE on i386 building llvm-toolchain-3.8 /<>/lib/Transforms/InstCombine/InstCombineAddSub.cpp:518:8: internal compiler error: in equ

[costamagnagianfranco at yahoo dot it]

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

Bug ID: 82330
   Summary: [7 regression since some days] GCC ICE on i386
building llvm-toolchain-3.8
/<>/lib/Transforms/InstCombine/InstCombin
eAddSub.cpp:518:8: internal compiler error: in
equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: costamagnagianfranco at yahoo dot it
  Target Milestone: ---

Hello, as said, since patches added in 20-09 and 21-09 I am getting an ICE on
i386 with valid code from llvm-toolchain-3.8
(copy-pasted from my Ubuntu report
https://bugs.launchpad.net/ubuntu/+source/gcc-7/+bug/1719710 )

the previous 7.2.0-6ubuntu1 seems to build it just fine
https://launchpadlibrarian.net/338774228/buildlog_ubuntu-artful-i386.llvm-toolchain-3.8_1%3A3.8.1-24ubuntu7ppa2_BUILDING.txt.gz

while 7.2.0-7ubuntu1 ICE now
/<>/lib/Transforms/InstCombine/InstCombineAddSub.cpp: In function
‘llvm::Value* {anonymous}::FAddCombine::simplify(llvm::Instruction*)’:
/<>/lib/Transforms/InstCombine/InstCombineAddSub.cpp:518:8:
internal compiler error: in equal_mem_array_ref_p, at
tree-ssa-scopedtables.c:429
 Value *FAddCombine::simplify(Instruction *I) {
^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

see:
https://launchpadlibrarian.net/338562399/buildlog_ubuntu-artful-i386.llvm-toolchain-3.8_1%3A3.8.1-24ubuntu7_BUILDING.txt.gz

Debian Changelog:
+ * Update to SVN 20170923 (r253114) from the gcc-7-branch.
+ - Fix PR libstdc++/79162, PR libstdc++/79162, PR libstdc++/82262,
+ PR libstdc++/82254, PR target/81996 (PPC), PR target/71951 (AArch64),
+ PR sanitizer/81929.
+ * Fix PR go/82284, taken from the trunk. Closes: #876353.

full upstream Changelog:
++2017-09-21 Jonathan Wakely 
++
++ * testsuite/25_algorithms/clamp/1.cc: Fix order of arguments and
++ expected results when using predicate defining reverse order.
++ * testsuite/25_algorithms/clamp/constexpr.cc: Likewise.
++
++2017-09-20 Jonathan Wakely 
++
++ Backport from mainline
++ 2017-06-14 Jonathan Wakely 
++
++ * doc/xml/manual/test.xml: Correct instructions on running tests.
++ * testsuite/27_io/basic_ios/copyfmt/char/1.cc: Adjust to pass when
++ -D_GLIBCXX_USE_CXX11_ABI=0 added to RUNTESTFLAGS.
++ * testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise.
++ * testsuite/27_io/basic_istream/extractors_arithmetic/char/
++ exceptions_failbit.cc: Likewise.
++ * testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/
++ exceptions_failbit.cc: Likewise.
++ * testsuite/27_io/basic_istream/extractors_other/char/
++ exceptions_null.cc: Likewise.
++ * testsuite/27_io/basic_istream/extractors_other/wchar_t/
++ exceptions_null.cc: Likewise.
++ * testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise.
++ * testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise.
++ * testsuite/27_io/basic_ostream/inserters_other/char/
++ exceptions_null.cc: Likewise.
++ * testsuite/27_io/basic_ostream/inserters_other/wchar_t/
++ exceptions_null.cc: Likewise.
++ * testsuite/27_io/ios_base/storage/2.cc: Likewise.
++
++ PR libstdc++/79162
++ * include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI]
++ (basic_string::_If_sv): Remove from the overload set when the
++ argument is derived from basic_string.
++
++ PR libstdc++/79162
++ * include/bits/basic_string.h (basic_string::_If_sv): Remove from the
++ overload set when the argument is derived from basic_string.
++ * testsuite/21_strings/basic_string/cons/char/moveable2_c++17.cc: New
++ test.
++ * testsuite/21_strings/basic_string/cons/wchar_t/moveable2_c++17.cc:
++ New test.
++
++ * testsuite/24_iterators/range_access_cpp17.cc: Fix order of dg-do
++ and dg-options directives. Fix invalid test.
++
++ Backport from mainline
++ 2017-09-20 Jonathan Wakely 
++
++ PR libstdc++/82262
++ * include/std/optional (__optional_hash_call_base): Add template
++ parameter for remove_const_t<_Tp> and use it consistently.
++ * testsuite/20_util/optional/hash.cc: Test optional.
++
++ Backport from mainline
++ 2017-09-19 Jonathan Wakely 
++
++ PR libstdc++/82254
++ * include/std/type_traits (__is_invocable): Add partial specialization
++ for INVOKE case and remove is_void check from partial
++ specialization for INVOKE case.
++ (__is_nt_invocable_impl): New helper for is_nothrow_invocable_r.
++ (is_nothrow_invocable_r): Use __is_nt_invocable_impl.
++ * testsuite/20_util/is_nothrow_invocable/value.cc: Add tests for
++ conversions that can throw or fail to convert. Use static assert
++ strings to explain negative results.
++ * testsuite/20_util/is_nothrow_invocable/value_ext.cc: Use
++ 

[Bug middle-end/82329] New: #pragma GCC target/optimize incurs high compilation time cost

[amonakov at gcc dot gnu.org]

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

Bug ID: 82329
   Summary: #pragma GCC target/optimize incurs high compilation
time cost
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

Translation units that include "umbrella" x86 intrinsic files, i.e. x86intrin.h
or immintrin.h are noticeably slow to compile:

$ time echo '#include ' | gcc -xc - -S -o /dev/null -Os

real0m0.162s
user0m0.150s
sys 0m0.010s

This is because directives like '#pragma GCC target("sse3")' in included files
cause ~8600 intrinsic declarations to parse very slowly. The pragma causes a
'target' attribute to be added to each declaration in the beginning of
attribs.c:decl_attributes, and then the loop over attributes goes into
lookup_scoped_attribute_spec and later on into handle_target_attribute and
ix86_valid_target_attribute_p, all of which seem fairly inefficient.

It probably would have been better to appropriately memoize and reuse tree
nodes instead of looking up the same two items in the hash over and over again.

On a testcase below isolating just this issue, perf shows

10.52%  cc1  cc1  [.] cl_option_hasher::hash
 9.52%  cc1  cc1  [.] cl_optimization_save
 5.17%  cc1  libc-2.24.so [.] __strcmp_sse2_unaligned
 3.80%  cc1  cc1  [.] iterative_hash_host_wide_int
 3.43%  cc1  libc-2.24.so [.] _int_malloc
 2.47%  cc1  libc-2.24.so [.] _int_free
 2.31%  cc1  libc-2.24.so [.] malloc
 2.28%  cc1  libc-2.24.so [.] malloc_consolidate
 2.09%  cc1  cc1  [.] ggc_internal_alloc
 1.91%  cc1  cc1  [.]
ix86_valid_target_attribute_tree


#define x10(x, a) \
x(a##0) x(a##1) x(a##2) x(a##3) x(a##4) x(a##5) x(a##6) x(a##7) x(a##8) x(a##9)
#define x100(x, a) \
x10(x, a##0) x10(x, a##1) x10(x, a##2) x10(x, a##3) x10(x, a##4) \
x10(x, a##5) x10(x, a##6) x10(x, a##7) x10(x, a##8) x10(x, a##9)
#define x1000(x, a) \
x100(x, a##0) x100(x, a##1) x100(x, a##2) x100(x, a##3) x100(x, a##4) \
x100(x, a##5) x100(x, a##6) x100(x, a##7) x100(x, a##8) x100(x, a##9)
#define x1(x, a) \
x1000(x, a##0) x1000(x, a##1) x1000(x, a##2) x1000(x, a##3) x1000(x, a##4) \
x1000(x, a##5) x1000(x, a##6) x1000(x, a##7) x1000(x, a##8) x1000(x, a##9)

#define x(a) void a(void);

#pragma GCC target("sse3")
x1(x, a)

[Bug target/82267] x32: unnecessary address-size prefixes. Why isn't -maddress-mode=long the default?

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Peter Cordes from comment #6)
> (In reply to H.J. Lu from comment #2)
> > > Are there still cases where -maddress-mode=long makes worse code?
> > 
> > 
> > Yes, there are more places where -maddress-mode=long needs to zero-extend
> > address to 64 bits where 0x67 prefix does for you.
> 
> So ideally, gcc should use 0x67 opportunistically where it saves a
> zero-extension instruction.

This is already implemented via:

;; Return true for RTX codes that force SImode address.
(define_predicate "SImode_address_operand"
  (match_code "subreg,zero_extend,and"))

and:

  /* Print SImode register names to force addr32 prefix.  */
  if (SImode_address_operand (addr, VOIDmode))
{
  [...]
  gcc_assert (!code);
  code = 'k';
}

in ix86_print_operand_address.

> Using 64-bit address size opportunistically wherever we're sure it's safe
> seems like a good idea, but I assume that's not easy to implement.
> 
> Can we teach  -maddress-mode=long  that a 0x67 prefix is a nearly-free way
> to zero-extend as part of an addressing-mode, so it will use that instead of
> extra instructions?

Please see above. It all boils down to combine being smart enough to combine
zero-extensions with the address. LEA also handles these kind of
zero-extensions.

> Note that %rsp can't be an index register, so you only have to check if it's
> the base register.

That is true, and this fact slipped out of my mind. I'm testing the following
patch:

Index: i386.c
===
--- i386.c  (revision 253208)
+++ i386.c  (working copy)
@@ -19953,12 +19953,11 @@
  code = 'k';
}

-  /* Since the upper 32 bits of RSP are always zero for x32, we can
-encode %esp as %rsp to avoid 0x67 prefix if there is no index or
-base register.  */
+  /* Since the upper 32 bits of RSP are always zero for x32,
+we can encode %esp as %rsp to avoid 0x67 prefix if
+there is no index register.  */
   if (TARGET_X32 && Pmode == SImode
- && ((!index && base && REG_P (base) && REGNO (base) == SP_REG)
- || (!base && index && REGNO (index) == SP_REG)))
+ && !index && base && REG_P (base) && REGNO (base) == SP_REG)
code = 'q';

   if (ASSEMBLER_DIALECT == ASM_ATT)

> 
> The SIB encodings that would mean index=RSP actually mean "no index".  The
> ModRM encoding that would mean base=RSP instead means "there's a SIB byte". 
> https://stackoverflow.com/a/46263495/224132
> 
> This means that `(%rsp)` is encodeable, instead of (%rsp, %rsp, scale).  Any
> other register can be used as a base with no SIB byte (unfortunately for
> code-size with -fomit-frame-pointer).
> 
> Can this check be applied to  %rbp  in functions that use a frame pointer?
> 
> That might be possible even if we can't as easily decide whether other
> registers need to be zero or sign extended if we're not sure whether they're
> "the pointer" or a signed integer pointer-difference.
> 
> However, simple dereference addressing modes (one register, no displacement)
> can always use 64-bit address size when the register is known to be
> zero-extended.

[Bug target/82267] x32: unnecessary address-size prefixes. Why isn't -maddress-mode=long the default?

[peter at cordes dot ca]

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

--- Comment #6 from Peter Cordes  ---
(In reply to H.J. Lu from comment #2)
> > Are there still cases where -maddress-mode=long makes worse code?
> 
> 
> Yes, there are more places where -maddress-mode=long needs to zero-extend
> address to 64 bits where 0x67 prefix does for you.

So ideally, gcc should use 0x67 opportunistically where it saves a
zero-extension instruction.

Using 64-bit address size opportunistically wherever we're sure it's safe seems
like a good idea, but I assume that's not easy to implement.

Can we teach  -maddress-mode=long  that a 0x67 prefix is a nearly-free way to
zero-extend as part of an addressing-mode, so it will use that instead of extra
instructions?


> > SSSE3 and later instructions need 66 0F 3A/38 before the opcode, so an
> > address-size or REX prefix will cause a decode stall on Silvermont.  With
> 
> That is true.

> > Similarly, Bulldozer-family has a 3-prefix limit, but doesn't
> > count escape bytes, and VEX only counts as 0 or 1 (for 2/3 byte VEX).
> 
> But 0x67 prefix is still better.

For tune=silvermont or knl, ideally we'd count prefixes and use an extra
instruction when it avoids a decode bottleneck.

For tune=generic we should probably always use 0x67 when it saves an
instruction.  IDK about tune=bdver2.  Probably not worth worrying about too
much.


> Since the upper 32 bits of stack register are always zero for x32, we
> can encode %esp as %rsp to avoid 0x67 prefix in address if there is no
> index or base register.

Note that %rsp can't be an index register, so you only have to check if it's
the base register.

The SIB encodings that would mean index=RSP actually mean "no index".  The
ModRM encoding that would mean base=RSP instead means "there's a SIB byte". 
https://stackoverflow.com/a/46263495/224132

This means that `(%rsp)` is encodeable, instead of (%rsp, %rsp, scale).  Any
other register can be used as a base with no SIB byte (unfortunately for
code-size with -fomit-frame-pointer).

Can this check be applied to  %rbp  in functions that use a frame pointer?

That might be possible even if we can't as easily decide whether other
registers need to be zero or sign extended if we're not sure whether they're
"the pointer" or a signed integer pointer-difference.

However, simple dereference addressing modes (one register, no displacement)
can always use 64-bit address size when the register is known to be
zero-extended.

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

[hermantenbrugge at home dot nl]

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

--- Comment #4 from Herman ten Brugge  ---
Created attachment 42238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42238=edit
modified test case

I modified the testcase a little bit and did some debugging.

The code outputs a failure if compiled with:
gcc -O3 -Wall -c tst.c -DERROR -fdump-tree-cunrolli-details
tst.c: In function 'mtrx_decompose_matrix':
tst.c:34:17: warning: array subscript is above array bounds [-Warray-bounds]
  sum += tmp.data[row][sub];

The code is ok of compiled with:
gcc -O3 -Wall -c tst.c -DERROR -fdump-tree-cunrolli-details
-fno-aggressive-loop-optimizations
or:
gcc -O3 -Wall -c tst.c -fdump-tree-cunrolli-details

The dumpfile that are created are in case of error containing or if
-fno-aggressive-loop-optimizations is given:
...
Analyzing # of iterations of loop 3
  exit condition [0, + , 1](no_overflow) < row_8
  bounds on difference of bases: 0 ... 4294967294
  result:
# of iterations row_8, bounded by 4294967294
...

The dumpfile looks correct in the case the sqrtf function is not used:
...
Analyzing # of iterations of loop 3
  exit condition [0, + , 1](no_overflow) < row_5
  bounds on difference of bases: 0 ... 5
  result:
# of iterations row_5, bounded by 5
...

Something must go wrong when aggressive-loop-optimizations is enabled.

[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
I tried that on powerpc64 and it now longer fails:


=== gfortran Summary ===

# of unsupported tests  6

[Bug c/82323] circular ifunc attribute on a function definition silently accepted

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Martin, if you have free cycles please go ahead.

I think other attributes might suffer from the same problem (alias and
weakref).  It doesn't look to me like it can be reliably detected in the
attribute handler (because it doesn't necessarily know whether it's dealing
with a definition or a declaration) so it might need to be done either in or
analogously to diagnose_mismatched_attributes in c-family/c-warn.c.

[Bug c/81854] weak alias of an incompatible symbol accepted

[tnfchris at gcc dot gnu.org]

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

--- Comment #16 from Tamar Christina  ---
Thanks Martin!, I'll follow the other ticket.

[Bug target/82158] _Noreturn functions that do return clobber caller's registers on ARM32 (but not other arches)

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #11 from Peter Cordes  ---
Flagging this WONTFIX instead of INVALID, since I'm still convinced gcc could
do better.  What I'm proposing wouldn't be any worse than breaking the ABI on
UB.  I guess unsafe code-gen for something that gcc warns about by default is
not too bad, though.

I guess I should file a separate missed-optimization bug about not eliminating
the code from a basic block that returns in a noreturn function.

See also
https://stackoverflow.com/questions/45981545/why-does-noreturn-function-return/46407858#46407858
(description of the possible optimizations).

[Bug target/82328] New: x86 rdrand: flags not used directly when branching on success/failure

[peter at cordes dot ca]

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

Bug ID: 82328
   Summary: x86 rdrand: flags not used directly when branching on
success/failure
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include 
unsigned long long use_intrinsic(void) {
unsigned long long rand;
while(!_rdrand64_step());  // FIXME: limited retry in case RNG is
broken
return rand;
}
// https://godbolt.org/g/x7mUvj
gcc 8.0.0 20170926 -O3 -mrdrnd

movl$1, %edx
.L4:
rdrand  %rax
movq%rax, -8(%rsp) # spill to memory, really?
cmovc   %edx, %eax
testl   %eax, %eax
je  .L4
movq-8(%rsp), %rax
ret

Note that RDRAND (http://felixcloutier.com/x86/RDRAND.html) indicates failure
by clearing CF *and* putting 0 in the destination register.  So this code is
correct (returning a valid RDRAND result even if it was zero), just much worse
than clang's:

.LBB1_1:
rdrandq %rax
jae .LBB1_1
retq

[Bug c/81854] weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor  ---
Yes, the recent changes to the C++ tests are wrong.  The failures are being
tracked under bug 82301.  I have a patch out for review to fix both the tests
and the implementation of the warning to resolve the problem
(https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01603.html).

[Bug c++/82159] [6/7/8 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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug other/82327] New: [7 Regression] ICE in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429 (i686-linux-gnu)

[doko at gcc dot gnu.org]

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

Bug ID: 82327
   Summary: [7 Regression] ICE in equal_mem_array_ref_p, at
tree-ssa-scopedtables.c:429 (i686-linux-gnu)
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen on the gcc-7-branch, introduced within the last two weeks, on
i686-linux-gnu, compiler configured to default to PIE.

$ g++ -std=c++11 -c -g -O2 -fPIC -fno-exceptions  InstCombineAddSub.ii 
/home/packages/llvm/llvm-toolchain-3.8-3.8.1/lib/Transforms/InstCombine/InstCombineAddSub.cpp:
In function 'llvm::Value*
{anonymous}::FAddCombine::simplify(llvm::Instruction*)':
/home/packages/llvm/llvm-toolchain-3.8-3.8.1/lib/Transforms/InstCombine/InstCombineAddSub.cpp:518:8:
internal compiler error: in equal_mem_array_ref_p, at
tree-ssa-scopedtables.c:429
 Value *FAddCombine::simplify(Instruction *I) {
^~~
Please submit a full bug report,
with preprocessed source if appropriate.

creduce doesn't make any progress to reduce the test case.

[Bug target/82267] x32: unnecessary address-size prefixes. Why isn't -maddress-mode=long the default?

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 26 13:59:18 2017
New Revision: 253202

URL: https://gcc.gnu.org/viewcvs?rev=253202=gcc=rev
Log:
PR target/82267
* config/i386/i386.c (ix86_print_operand_address_as): Only test
REGNO (base) == SP_REG if base is a REG.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug middle-end/35691] Missed (a == 0) && (b == 0) into (a|(typeof(a)(b)) == 0 when the types don't match

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 26 13:58:11 2017
New Revision: 253201

URL: https://gcc.gnu.org/viewcvs?rev=253201=gcc=rev
Log:
PR middle-end/35691
* tree-ssa-reassoc.c (update_range_test): Dump r->exp each time
if it is different SSA_NAME.
(optimize_range_tests_cmp_bitwise): New function.
(optimize_range_tests): Call it.

* gcc.dg/pr35691-5.c: New test.
* gcc.dg/pr35691-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr35691-5.c
trunk/gcc/testsuite/gcc.dg/pr35691-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug c++/82326] static_cast for vector extension not working?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Gcc extension for vectors is just  reinterpret_cast as I thought was documented
too. C cast gets turned into reinterpret_cast.  Any other cast does not make
sense really because the bits are being reinterpreted.

[Bug c++/82326] New: static_cast for vector extension not working?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 82326
   Summary: static_cast for vector extension not working?
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

My problem is the following:

```
// main.cpp
#include 
#include 

using int32x4_t = int32_t __attribute__ ((__vector_size__(16)));
using uint32x4_t = uint32_t __attribute__ ((__vector_size__(16)));

int main()
{
int32x4_t a{-1, 0, 1, 2};

// invalid static_cast from type ‘int32x4_t {aka __vector(4) int}’
// to type ‘uint32x4_t {aka __vector(4) unsigned int}
uint32x4_t b = static_cast(a); // fails with above message

uint32x4_t c = reinterpret_cast(a); // works

// invalid static_cast from type ‘int32x4_t {aka __vector(4) int}’
// to type ‘__m128i {aka __vector(2) long long int}
__m128i d = static_cast<__m128i>(a); // fails with above message

__m128i e = reinterpret_cast<__m128i>(a); // works
return 0;
}
```

> g++ -msse4 main.cpp -o main


Why is a static_cast not working?

This is a hassle, because different compilers support different syntaxes. 

* gcc allows only reinterpret_cast and C-style casts
* clang allows both static_cast and reinterpret_cast and C-style casts
* icc (Intel Compiler) allows only static_cast and C-style casts

Thank you!

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

[qing.zhao at oracle dot com]

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

--- Comment #5 from Qing Zhao  ---
Okay, will let you know when the patch is put into upstream.

Qing
> On Sep 26, 2017, at 5:56 AM, wilco at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266
> 
> --- Comment #4 from Wilco  ---
> (In reply to Qing Zhao from comment #3)
>> This is a very similar bug as PR80295.
>> I have had a fix for 80295 already. hopefully that fix should fix this bug
>> too.
>> 
>> since I cannot build gnat on the available machines, I cannot confirm this
>> on my side.
> 
> When you have the patch ready we'll try it. Based on how many issues I found
> there are multiple places in the mid-end that need to be fixed...
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/81481] [7/8 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
A bit further reduced, needs -m32 -mssse3 -fpic -O2:

#include 

extern const signed char c[31] __attribute__((visibility("hidden")));

__m128i f(__m128i *x, void *v)
{
  int i;
  asm("# %0" : "=r"(i));
  __m128i t = _mm_loadu_si128((void*)[i]);
  __m128i xx = *x;
  xx =  _mm_shuffle_epi8(xx, t);
  asm("# %0 %1 %2" : "+x"(xx) : "r"(c), "r"(i));
  return xx;
}

[Bug tree-optimization/82321] [8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 26 11:05:42 2017
New Revision: 253199

URL: https://gcc.gnu.org/viewcvs?rev=253199=gcc=rev
Log:
2017-09-26  Richard Biener  

PR tree-optimization/82321
* graphite.c (canonicalize_loop_closed_ssa): Properly check
for the def being inside the loop.

* gcc.dg/graphite/pr82321.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr82321.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82143] add a -fdefault-real-16 flag

[janus at gcc dot gnu.org]

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

--- Comment #24 from janus at gcc dot gnu.org ---
All the failures will hopefully be fixed by the patch at ...

https://gcc.gnu.org/ml/fortran/2017-09/msg00111.html

... which I plan to commit soon (feedback welcome).

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

[wilco at gcc dot gnu.org]

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

--- Comment #4 from Wilco  ---
(In reply to Qing Zhao from comment #3)
> This is a very similar bug as PR80295.
> I have had a fix for 80295 already. hopefully that fix should fix this bug
> too.
> 
> since I cannot build gnat on the available machines, I cannot confirm this
> on my side.

When you have the patch ready we'll try it. Based on how many issues I found
there are multiple places in the mid-end that need to be fixed...

[Bug fortran/82143] add a -fdefault-real-16 flag

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #23 from Tamar Christina  ---
For the record, this is also failing on aarch64-none-linux-gnu and 
arm-none-linux-gnueabihf

f951: Fatal Error: REAL(KIND=16) is not available for '-fdefault-real-16'
option

[Bug middle-end/82145] [8 regression] i386/pr38988.c, i386/pr46254.c, i386/pr55154.c, i386/pr81766.c fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/81854] weak alias of an incompatible symbol accepted

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #14 from Tamar Christina  ---
Hi Martin,

the changed tests seem to be failing on arm-none-linux-gnueabihf:

FAIL: g++.dg/ext/attr-ifunc-1.C  -std=gnu++11 execution test
FAIL: g++.dg/ext/attr-ifunc-1.C  -std=gnu++14 execution test
FAIL: g++.dg/ext/attr-ifunc-1.C  -std=gnu++98 execution test
FAIL: g++.dg/ext/attr-ifunc-2.C  -std=gnu++11 execution test
FAIL: g++.dg/ext/attr-ifunc-2.C  -std=gnu++14 execution test
FAIL: g++.dg/ext/attr-ifunc-2.C  -std=gnu++98 execution test
FAIL: g++.dg/ext/attr-ifunc-3.C  -std=gnu++11 execution test
FAIL: g++.dg/ext/attr-ifunc-3.C  -std=gnu++14 execution test
FAIL: g++.dg/ext/attr-ifunc-3.C  -std=gnu++98 execution test
FAIL: g++.dg/ext/attr-ifunc-4.C  -std=gnu++11 execution test
FAIL: g++.dg/ext/attr-ifunc-4.C  -std=gnu++14 execution test
FAIL: g++.dg/ext/attr-ifunc-4.C  -std=gnu++98 execution test

running in gdb I get 

Starting program: /home/tnfchris/gcc-fsf/attr-ifunc-1.exe 

Program received signal SIGSEGV, Segmentation fault.
0x00010540 in Klass::resolver () at gcc/testsuite/g++.dg/ext/attr-ifunc-1.C:26
26return ::implementation;
(gdb) bt
#0  0x00010540 in Klass::resolver () at
gcc/testsuite/g++.dg/ext/attr-ifunc-1.C:26
#1  0xf77cfc86 in elf_machine_rel (skip_ifunc=,
reloc_addr_arg=0x2101c, version=, sym=0x101fc, reloc=0x103e0,
map=0xf77f0968) at ../sysdeps/arm/dl-machine.h:523
#2  elf_dynamic_do_Rel (skip_ifunc=, lazy=,
nrelative=, relsize=, reladdr=,
map=0xf77f0968) at do-rel.h:137
#3  _dl_relocate_object (scope=, reloc_mode=,
consider_profiling=, consider_profiling@entry=0) at
dl-reloc.c:258
#4  0xf77ca1f6 in dl_main (phdr=, phnum=,
user_entry=, auxv=) at rtld.c:2185
#5  0xf77d76c8 in _dl_sysdep_start (start_argptr=start_argptr@entry=0xfffef671,
dl_main=0xf77c86e1 ) at ../elf/dl-sysdep.c:253
#6  0xf77c8222 in _dl_start_final (arg=0xfffef671) at rtld.c:414
#7  _dl_start (arg=0xfffef671) at rtld.c:520
#8  0xf77c7b50 in _start () from /lib/ld-linux-armhf.so.3


It seems to be segfaulting on the return address

=> 0x10538 : movwr3, #1317   ; 0x525
   0x1053c :   movtr3, #1
   0x10540 :   str r3, [r0, #0]

it goes wrong at the store, since r0 doesn't seem to contain a valid address

(gdb) x $r0
0x37b0d6:   Cannot access memory at address 0x37b0d6

Any ideas what's going on here?

[Bug rtl-optimization/82192] [5/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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[5/6/7/8 Regression] gcc|[5/6/7 Regression] gcc
   |produces incorrect code |produces incorrect code
   |with -O2 and bit-field  |with -O2 and bit-field

--- Comment #18 from Jakub Jelinek  ---
Fixed for 8+ so far.

[Bug libfortran/82292] [8 Regression] bootstrap fails in libgfortran on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Jakub Jelinek  ---
Yeah, I think this is user error.

[Bug tree-optimization/82244] [7 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/82291] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/82285] [6/7 Regression] Optimizing error when using enumeration

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 26 10:16:40 2017
New Revision: 253190

URL: https://gcc.gnu.org/viewcvs?rev=253190=gcc=rev
Log:
2017-09-26  Richard Biener  

Backport from mainline
2017-09-19  Richard Biener  

PR tree-optimization/82244
* tree-vrp.c (remove_range_assertions): Do not propagate
a constant to abnormals but replace the assert with a copy.

* gcc.dg/torture/pr82244.c: New testcase.

2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

* gcc.dg/torture/pr82276.c: New testcase.

2017-09-20  Richard Biener  

PR tree-optimization/82264
* tree-ssa-sccvn.c (vn_phi_eq): Use safe_dyn_cast to check
for GIMPLE_CONDs.
(vn_phi_lookup): Likewise.
(vn_phi_insert): Likewise.
* is-a.h (safe_dyn_cast): New.

* gcc.dg/torture/pr82264.c: New testcase.

2017-09-25  Richard Biener  

PR tree-optimization/82285
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
enumeral types.

* gcc.dg/torture/pr82285.c: New testcase.

2017-09-22  Richard Biener  

PR tree-optimization/82291
* tree-if-conv.c (predicate_mem_writes): Make sure to
remove writes in blocks predicated with false.

* gcc.dg/torture/pr82291.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82244.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82264.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82276.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82285.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82291.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/is-a.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-if-conv.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c
branches/gcc-7-branch/gcc/tree-vect-patterns.c
branches/gcc-7-branch/gcc/tree-vrp.c

[Bug tree-optimization/82264] [6/7 Regression] ICE in vn_phi_lookup at gcc/tree-ssa-sccvn.c:3125

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 26 10:16:40 2017
New Revision: 253190

URL: https://gcc.gnu.org/viewcvs?rev=253190=gcc=rev
Log:
2017-09-26  Richard Biener  

Backport from mainline
2017-09-19  Richard Biener  

PR tree-optimization/82244
* tree-vrp.c (remove_range_assertions): Do not propagate
a constant to abnormals but replace the assert with a copy.

* gcc.dg/torture/pr82244.c: New testcase.

2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

* gcc.dg/torture/pr82276.c: New testcase.

2017-09-20  Richard Biener  

PR tree-optimization/82264
* tree-ssa-sccvn.c (vn_phi_eq): Use safe_dyn_cast to check
for GIMPLE_CONDs.
(vn_phi_lookup): Likewise.
(vn_phi_insert): Likewise.
* is-a.h (safe_dyn_cast): New.

* gcc.dg/torture/pr82264.c: New testcase.

2017-09-25  Richard Biener  

PR tree-optimization/82285
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
enumeral types.

* gcc.dg/torture/pr82285.c: New testcase.

2017-09-22  Richard Biener  

PR tree-optimization/82291
* tree-if-conv.c (predicate_mem_writes): Make sure to
remove writes in blocks predicated with false.

* gcc.dg/torture/pr82291.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82244.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82264.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82276.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82285.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82291.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/is-a.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-if-conv.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c
branches/gcc-7-branch/gcc/tree-vect-patterns.c
branches/gcc-7-branch/gcc/tree-vrp.c

[Bug tree-optimization/82291] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 26 10:16:40 2017
New Revision: 253190

URL: https://gcc.gnu.org/viewcvs?rev=253190=gcc=rev
Log:
2017-09-26  Richard Biener  

Backport from mainline
2017-09-19  Richard Biener  

PR tree-optimization/82244
* tree-vrp.c (remove_range_assertions): Do not propagate
a constant to abnormals but replace the assert with a copy.

* gcc.dg/torture/pr82244.c: New testcase.

2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

* gcc.dg/torture/pr82276.c: New testcase.

2017-09-20  Richard Biener  

PR tree-optimization/82264
* tree-ssa-sccvn.c (vn_phi_eq): Use safe_dyn_cast to check
for GIMPLE_CONDs.
(vn_phi_lookup): Likewise.
(vn_phi_insert): Likewise.
* is-a.h (safe_dyn_cast): New.

* gcc.dg/torture/pr82264.c: New testcase.

2017-09-25  Richard Biener  

PR tree-optimization/82285
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
enumeral types.

* gcc.dg/torture/pr82285.c: New testcase.

2017-09-22  Richard Biener  

PR tree-optimization/82291
* tree-if-conv.c (predicate_mem_writes): Make sure to
remove writes in blocks predicated with false.

* gcc.dg/torture/pr82291.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82244.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82264.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82276.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82285.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82291.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/is-a.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-if-conv.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c
branches/gcc-7-branch/gcc/tree-vect-patterns.c
branches/gcc-7-branch/gcc/tree-vrp.c

[Bug tree-optimization/82276] [8 Regression] -O2: ICE: SSA corruption during RTL pass: expand; at tree-ssa-coalesce.c:1010

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 26 10:16:40 2017
New Revision: 253190

URL: https://gcc.gnu.org/viewcvs?rev=253190=gcc=rev
Log:
2017-09-26  Richard Biener  

Backport from mainline
2017-09-19  Richard Biener  

PR tree-optimization/82244
* tree-vrp.c (remove_range_assertions): Do not propagate
a constant to abnormals but replace the assert with a copy.

* gcc.dg/torture/pr82244.c: New testcase.

2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

* gcc.dg/torture/pr82276.c: New testcase.

2017-09-20  Richard Biener  

PR tree-optimization/82264
* tree-ssa-sccvn.c (vn_phi_eq): Use safe_dyn_cast to check
for GIMPLE_CONDs.
(vn_phi_lookup): Likewise.
(vn_phi_insert): Likewise.
* is-a.h (safe_dyn_cast): New.

* gcc.dg/torture/pr82264.c: New testcase.

2017-09-25  Richard Biener  

PR tree-optimization/82285
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
enumeral types.

* gcc.dg/torture/pr82285.c: New testcase.

2017-09-22  Richard Biener  

PR tree-optimization/82291
* tree-if-conv.c (predicate_mem_writes): Make sure to
remove writes in blocks predicated with false.

* gcc.dg/torture/pr82291.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82244.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82264.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82276.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82285.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82291.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/is-a.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-if-conv.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c
branches/gcc-7-branch/gcc/tree-vect-patterns.c
branches/gcc-7-branch/gcc/tree-vrp.c

[Bug tree-optimization/82244] [7 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 26 10:16:40 2017
New Revision: 253190

URL: https://gcc.gnu.org/viewcvs?rev=253190=gcc=rev
Log:
2017-09-26  Richard Biener  

Backport from mainline
2017-09-19  Richard Biener  

PR tree-optimization/82244
* tree-vrp.c (remove_range_assertions): Do not propagate
a constant to abnormals but replace the assert with a copy.

* gcc.dg/torture/pr82244.c: New testcase.

2017-09-21  Richard Biener  

PR tree-optimization/82276
PR tree-optimization/82244
* tree-vrp.c (build_assert_expr_for): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the variable we assert on
has it set.
(remove_range_assertions): Revert earlier change.

* gcc.dg/torture/pr82276.c: New testcase.

2017-09-20  Richard Biener  

PR tree-optimization/82264
* tree-ssa-sccvn.c (vn_phi_eq): Use safe_dyn_cast to check
for GIMPLE_CONDs.
(vn_phi_lookup): Likewise.
(vn_phi_insert): Likewise.
* is-a.h (safe_dyn_cast): New.

* gcc.dg/torture/pr82264.c: New testcase.

2017-09-25  Richard Biener  

PR tree-optimization/82285
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
enumeral types.

* gcc.dg/torture/pr82285.c: New testcase.

2017-09-22  Richard Biener  

PR tree-optimization/82291
* tree-if-conv.c (predicate_mem_writes): Make sure to
remove writes in blocks predicated with false.

* gcc.dg/torture/pr82291.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82244.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82264.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82276.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82285.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr82291.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/is-a.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-if-conv.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c
branches/gcc-7-branch/gcc/tree-vect-patterns.c
branches/gcc-7-branch/gcc/tree-vrp.c

[Bug lto/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #16 from Jonathan Wakely  ---
(In reply to Martin Liška from comment #15)
> Shouldn't one have different versions of libstdc++.so in order to either
> have a single global symbol or definitions in user's object files?

No, it's normal to have multiple definitions of C++ template instantiations,
the linker should resolve them and only keep one.

[Bug c++/82316] unexpected warning for using 'register' storage class in extern "C" declarations

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jordi Vilar from comment #4)
> I don't claim that a extern "C" declarations have to be interpreted as C in
> a C++ translation unit. What I say is that most C libraries (libtiff, zlib,
> lcms, etc.) provide a header that assumes that the C api can be reused for
> C++ just by wrapping it with extern "C" {}. If a C library uses register in
> its api declarations, then that legitimate C declarations no longer can be
> used in C++ code not even wrapped by extern "C". This is a breaking movement.

Yes.

> Supressing the warning in extern "C" declarations doesn't imply parsing it
> as C, because it is actually a C++ translation, but would enable continuing
> using the traditional C libraries.

But the warning is valid: it tells you that the C library is not compatible
with C++17.

> For an example of C library that uses register in its api, you can take a
> look on the little cms (lcms) that is included in most linux distributions.
> It just has the classic #ifdef __cplusplus extern "C" { #endif and tons of
> register function arguments.

That library is silly: the register keyword is almost useless and the compiler
almost always does a better job of deciding what to put in registers. It's not
1970.

> Should C++17 applications REJECT all of those ligitimate C libraries?

It's not valid C++17 code, so yes. It's only a warning though, so you can
ignore it, or suppress it with -Wno-register.

If the libraries want to be valid for use in C++ then they should not use
'register' when parsed as C++, because it's not valid e.g.

#ifdef __cplusplus
extern "C" {
#define register
#endif
...
#ifdef __cplusplus
}
#undef register
#endif

The warning is valid and helps find code that needs to be fixed for C++
compatibility.

[Bug c++/82307] unscoped enum-base incorrect cast

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The bug status was changed to NEW, that means it's been confirmed as a GCC bug
that should be fixed.

Richard was noting for other people's benefit that Clang accepts the code.

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Iain Sandoe from comment #6)
> > > (In reply to Iain Sandoe from comment #5)
> > > > (In reply to Iain Sandoe from comment #4)
> > > > > (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > > > > > > --- Comment #1 from Iain Sandoe  ---

> > > some of the verify fails seem to be caused by the ancient dwarfdump not
> > > being smart enough; ld64 and BINUTILS objdump seem to be happy that the 
> > > FDEs
> > > are well-formed (more checking to be done)

With "more modern" cctools and ld64 this sub-set still fails dwarfdump --eh
--verify (for x86-64).  These do seem to be spurious and caused by dwarfdump
not dealing with the relocations for the start symbols in the eh_frame.  For
these cases, ld64, BINUTILS objdump and LLVM objdump are all happy that the
FDEs are correctly formed - so (a) they don't seem to be a problem and (b) the
m64 unwinder should never be used on any Darwin >= 10 anyway.

[Bug target/82175] [8 Regression] -march=native fails on armv7 big/little system armv7l-unknown-linux-gnueabihf with gcc 8.0.0

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
Fixed

[Bug target/82175] [8 Regression] -march=native fails on armv7 big/little system armv7l-unknown-linux-gnueabihf with gcc 8.0.0

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Sep 26 09:33:49 2017
New Revision: 253189

URL: https://gcc.gnu.org/viewcvs?rev=253189=gcc=rev
Log:
[ARM] PR82175 - fix -mcpu=native not working correctly.

The new option processing machinery relies on %< rules in the specs to
suppress options that are rewritten.  Suppression appears to be a two
phase process where the option is partially suppressed when %< is
processed and then fully suppressed at the end of the string.  Strings
are separated by commas and there can be multiple strings used to form
DRIVER_SELF_SPECS.

The fix in this case is to separate the driver self specs for ARM into
separate rules as described; this forces the -m{cpu,tune,arch}=native
options to be properly removed before proceeding to the next rule set.

PR target/82175
* config/arm/arm.h (DRIVER_SELF_SPECS): Separate sub-rules with commas.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin11.4.2   |x86_64-apple-darwin11.4.2,
   ||x86_64-apple-darwin10.8
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-26
 CC||dominiq at lps dot ens.fr
 Ever confirmed|0   |1

--- Comment #9 from Iain Sandoe  ---
This might be a DUP of 82092 - or, at least, the remaining errors on D10 are

I don't believe it's in any way related to 57438 - even tho that also
manifested as a 0-length FDE.

===

AFAICS, this is caused by the system tools (at least at that generation / D10
generation) getting confused about where local labels belong in relation to
atom boundaries.

so something like

   ... switch to cold section
COLDB0:

   ... switch to hot section


   ... switch to cold section
__some_label:


...
...

COLDE0:

xxx
   associates the COLDB0 with the atom *before* the one starting with
"__some_label:"
   but the FDE computation is expecting to see it as the same address as
"__some_label:"

if one manually changes it to

   ... switch to cold section
__some_label:
COLDB0:

 then it all works.

I suppose newer tools are catering for this better (and also dealing [better?]
with coincident addresses since the modern linker supports aliases).

.. needs some more investigation as to why it's not failing with newer
toolchains (make sure that's not just something being hidden by the switch to
allow aliasing).

=

I have/had some patches to improve the output of labels for hot/cold switching
(reduced the number of section switches and output the start labels lazily) ..
but they don't rebase to trunk, so need some work.

[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #2)
> Not on sparc-sun-solaris2.11 which is equally affected: the tests are still
> compiled and fail as before.


I just posted an improved patch at:

https://gcc.gnu.org/ml/fortran/2017-09/msg00111.html

Could you try that one, please?

Thanks,
Janus

[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  ---
(In reply to kargl from comment #1)
> Does this fix the problem?
> 
> Index: promotion_3.f90
> ===
> --- promotion_3.f90 (revision 253178)
> +++ promotion_3.f90 (working copy)
> @@ -1,5 +1,6 @@
>  ! { dg-do run }
>  ! { dg-options "-fdefault-real-16" }
> +! { dg-require-effective-target fortran_large_real }
>  !
>  ! PR 82143: add a -fdefault-real-16 flag
>  !
> Index: promotion_4.f90
> ===
> --- promotion_4.f90 (revision 253178)
> +++ promotion_4.f90 (working copy)
> @@ -1,5 +1,6 @@
>  ! { dg-do run }
>  ! { dg-options "-fdefault-real-10" }
> +! { dg-require-effective-target fortran_large_real }
>  !
>  ! PR 82143: add a -fdefault-real-16 flag
>  !

Not on sparc-sun-solaris2.11 which is equally affected: the tests are still
compiled and fail as before.

  Rainer

[Bug c++/82325] worse code generated compared to clang when using a constexpr array

[dvd at gnx dot it]

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

--- Comment #2 from David  ---
(In reply to Jakub Jelinek from comment #1)
> To unroll the loop completely with gcc, one needs to use --param
> max-completely-peel-times=32 because the loop has more than 16 iterations,
> which is the default limit for the complete unrolling.

Thanks! change the param to 32 did the trick (even if the resulting code is
larger than the one produced by clang)

> That said, neither of the compilers figures out that after unrolling the
> intervals are really adjacent, but disjoint, it would be much better to
> build a binary decision tree rather than a loop from smallest to largest.
> But you can handle that at the source level by doing a binary search in the
> array (and you could as well ignore bits there too, just look at the base
> values).

The rewrite as a binary search result a more compact code, I'll profile it to
understand if it will be also faster.

Do you prefer to keep this bug open or can I mark it as resolved?

[Bug target/82240] i386.md & -Wlogical-op in build

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to Andrew Pinski from comment #7)
> but atom.md could be improved to just say:
> That is get rid of the check for memory attr on the second case.

I tried out your change and it appears to remove the first warning.

Here are the relevant lines from the build:

$ grep "warning:.*Wlogical-op" mk.out 
../../trunk/gcc/config/i386/i386.md:21228:36: warning: logical ‘or’ of
collectively exhaustive tests is always true [-Wlogical-op]
$ 

More detail:

../../trunk/gcc/config/i386/i386.md: In function ‘int
insn_default_latency_slm(rtx_insn*)’:
../../trunk/gcc/config/i386/i386.md:21228:36: warning: logical ‘or’ of
collectively exhaustive tests is always true [-Wlogical-op]

This seems to be somewhere near source code in file insn-latencytab.c

case 5028:  /* loaddi_via_sse */
case 5029:  /* storedi_via_sse */
  extract_insn_cached (insn);
  if (((cached_type = get_attr_type (insn)) == TYPE_OTHER) && (!
((cached_atom_unit = get_attr_atom_unit (insn)) == ATOM_UNIT_JEU)))
{

[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-26
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82143
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
 Ever confirmed|0   |1