[Bug rtl-optimization/82576] New: sbitmap_vector_alloc() not ready for 64 bits

[babokin at gmail dot com]

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

Bug ID: 82576
   Summary: sbitmap_vector_alloc() not ready for 64 bits
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 42382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42382=edit
Reproducer

gcc trunk, rev253744, x86_64.

Trying compile attached test case with UBSAN I get segfault:
during RTL pass: cprop
f.cpp: In function ‘void tf_1_foo()’:
f.cpp:335:3: internal compiler error: Segmentation fault
   }
   ^
0xf4b65f crash_signal
../../gcc/gcc/toplev.c:326
0x1684418 sbitmap_vector_alloc(unsigned int, unsigned int)
../../gcc/gcc/sbitmap.c:171
0x1562dc3 alloc_cprop_mem
../../gcc/gcc/cprop.c:558
0x1562dc3 one_cprop_pass
../../gcc/gcc/cprop.c:1818
0x1562dc3 execute_rtl_cprop
../../gcc/gcc/cprop.c:1932
0x1562dc3 execute
../../gcc/gcc/cprop.c:1970

This is due to sbitmap_vector_alloc() implementation using "unsigned int",
instead of size_t. Fixing this make test case compile (even though consuming a
lot of memory, about 80Gb).

>g++ -std=c++11 -fsanitize=undefined -fno-sanitize-recover=undefined -w 
>-Werror=uninitialized -O2 -c f.cpp

[Bug other/78808] target_clones not applying to openmp functions

[steven at uplinklabs dot net]

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

--- Comment #9 from Steven Noonan  ---
Actually, I lied. It's not quite working. It's obviously close though.

The following examples of the issue are using my n-body implementation:

https://github.com/tycho/nbody

Each of the variants of n-body have a bunch of link issues:

$ make CFOPTIMIZE="-O3 -march=core2"
[...]
nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.default.8':
nbody_CPU_SOA.c:(.text+0x1e): undefined reference to
`_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc'
nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_skylake.4':
nbody_CPU_SOA.c:(.text+0x59b): undefined reference to
`_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc'
nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_haswell.5':
nbody_CPU_SOA.c:(.text+0x63b): undefined reference to
`_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc'
nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_sandybridge.6':
nbody_CPU_SOA.c:(.text+0x6db): undefined reference to
`_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc'
[...]

Symbols in nbody_CPU_SOA.o:

$ nm src/nbody_CPU_SOA.o 
00a0 t bodyBodyInteraction
0c00 T ComputeGravitation_SOA
0610 t _ComputeGravitation_SOA.arch_haswell.5
06b0 t _ComputeGravitation_SOA.arch_sandybridge.6
0570 t _ComputeGravitation_SOA.arch_skylake.4
 t _ComputeGravitation_SOA.default.8
0bb0 i
_ComputeGravitation_SOA._GLOBAL___ComputeGravitation_SOA.ifunc
0290 t _ComputeGravitation_SOA._omp_fn.0.arch_haswell.2
0400 t _ComputeGravitation_SOA._omp_fn.0.arch_sandybridge.3
0120 t _ComputeGravitation_SOA._omp_fn.0.arch_skylake.1
0750 t _ComputeGravitation_SOA._omp_fn.0.default.7
 U
_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc
0b60 t _ComputeGravitation_SOA._omp_fn.0.resolver
0bb0 t _ComputeGravitation_SOA.resolver
 U __cpu_indicator_init
 U __cpu_model
 U GOMP_loop_end_nowait
 U GOMP_loop_ull_guided_next
 U GOMP_loop_ull_guided_start
 U GOMP_parallel
 r .LC0
0004 r .LC1
0008 r .LC2
 r .LC4
0010 r .LC5
 U libtime_cpu_to_wall


There's a second issue as well. If I tell it to build with -march=native, I get
compile errors:

$ make CFOPTIMIZE="-O3 -march=native" V=1
make -C libc11 libc11.a
make -C libtime libtime.a
make -C src nbody
gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE
-DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11
-I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement
-Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes
-Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings
-Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread
-fopenmp -MMD -c -o nbody_CPU_AOS.o nbody_CPU_AOS.c
gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE
-DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11
-I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement
-Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes
-Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings
-Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread
-fopenmp -MMD -c -o nbody_CPU_AOS_tiled.o nbody_CPU_AOS_tiled.c
gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE
-DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11
-I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement
-Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes
-Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings
-Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread
-fopenmp -MMD -c -o nbody_CPU_SOA.o nbody_CPU_SOA.c
gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE
-DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11
-I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement
-Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes
-Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings
-Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread
-fopenmp -MMD -c -o nbody_CPU_SOA_tiled.o nbody_CPU_SOA_tiled.c
In file included from nbody_CPU_AOS.c:42:0:
nbody_CPU_AOS.c: In function ‘_ComputeGravitation_AOS.arch_skylake.4’:
nbody_util.h:114:21: error: SSE register return with SSE disabled
  static DECLARE_AOS(_ ## Name)
 ^
nbody_util.h:96:2: note: in definition of macro ‘DECLARE_AOS’
  Name( \
  ^~~~
nbody_CPU_AOS.c:47:1: 

[Bug rtl-optimization/78911] [6 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[vityokster at gmail dot com]

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

Viktor Yu. Kovalskii  changed:

   What|Removed |Added

 CC||vityokster at gmail dot com

--- Comment #17 from Viktor Yu. Kovalskii  ---
We try investigate source of this error in two different bugzilla's:

https://bugs.gentoo.org/613128

https://bugs.winehq.org/show_bug.cgi?id=42406

I hope information from this bug reports will be very helpful.

Right now this bug reproduced with gcc-6.4.0 and wine-2.17.

[Bug ada/82573] GNAT.Registry doesn't read/write with HKEY_LOCAL_MACHINE.

[gnu_andrew at member dot fsf.org]

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

Andrew John Hughes  changed:

   What|Removed |Added

 CC||gnu_andrew at member dot 
fsf.org

--- Comment #1 from Andrew John Hughes  ---
This doesn't seem to be related to GNU Classpath.

[Bug c++/82572] throw on line by itself in constexpr function aborts compile even if never reached

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||80061

--- Comment #1 from Andrew Pinski  ---
I think this is almost a dup of bug 80061.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061
[Bug 80061] error on constexpr function with an unevaluated throw

[Bug tree-optimization/82574] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 82574
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171016 (experimental) [trunk revision 253793] (GCC) 
$ 
$ gcctk -O2 small.c; ./a.out; echo $?
0
$ gcc-7.2.0 -O3 small.c; ./a.out; echo $?
0
$ 
$ gcctk -O3 small.c; ./a.out; echo $?
1
$ 


---


char a, b, c, d[2][3];

int main ()
{
  for (; a < 2; a++)
for (b = 0; b < 3; b++)
  if (c)
d[a][b] = 1;
  return d[0][0]; 
}

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

--- Comment #10 from asmwarrior  ---
Is it related to pointer casting? I see this post:
https://stackoverflow.com/questions/36816363/gcc-4-9-3-more-aggressive-null-pointer-check-removal

Some one reported that the Null check was removed in the following code

void someFunc(struct MyStruct *s)
{
if (s != NULL)
{
   cout << s->someField << endl;
   delete s;
}
}

I see comments in that question, and some one suggest using
`-fno-strict-aliasing` option.

@Vadim, dose wx use some cast? I see some macros in wx3.1's source like:

// this cast does some more checks at compile time as it uses static_cast
// internally
//
// note that it still has different semantics from dynamic_cast<> and so can't
// be replaced by it as long as there are any compilers not supporting it
#define wxDynamicCast(obj, className) \
((className *) wxCheckDynamicCast( \
const_cast(static_cast(\
  const_cast(static_cast(obj, \
::ms_classInfo))

[Bug c++/82572] New: throw on line by itself in constexpr function aborts compile even if never reached

[ekchew at lgl dot kos.net]

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

Bug ID: 82572
   Summary: throw on line by itself in constexpr function aborts
compile even if never reached
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ekchew at lgl dot kos.net
  Target Milestone: ---

This code will not compile in C++14:

constexpr void foo() {
if(true)
return;
throw "What am I doing here?";
}

Error:

gccbug.cc: In function 'constexpr void foo()':
gccbug.cc:4:8: error: expression '' is not a constant
expression
  throw "What am I doing here?";
^~~

Build:

COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/7.2.0/libexec/gcc/x86_64-apple-darwin16.7.0/7.2.0/lto-wrapper
Target: x86_64-apple-darwin16.7.0
Configured with: ../configure --build=x86_64-apple-darwin16.7.0
--prefix=/usr/local/Cellar/gcc/7.2.0
--libdir=/usr/local/Cellar/gcc/7.2.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-7
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
7.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls --with-native-system-header-dir=/usr/include
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
Thread model: posix
gcc version 7.2.0 (Homebrew GCC 7.2.0)

[Bug debug/58150] debug info about definition of enum class not emitted if the declaration was already used in a class

[npl at chello dot at]

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

npl at chello dot at changed:

   What|Removed |Added

 CC||npl at chello dot at

--- Comment #2 from npl at chello dot at ---
Created attachment 42381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42381=edit
another testcase

I was generating a testcase before discovering this bug.
Problem is the same:

A class/struct using a prototyped, not yet defined "enum class" will prevent
that debug information for this "enum class" to be emitted.
Only if no class/struct uses a "enum class" before its defined, the debug info
will be available.

Affected: GCC 5.3.0, GCC 6.4.0, GCC 7.2.0

Please fix this, it really makes debugging a pain

[Bug other/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
This is one of those SPEC tests so I can't post the whole .i.  I will see if I
can extract part of it that still shows the same bad STW/LD behavior.  I
probably will not get to it until tomorrow, though.

[Bug sanitizer/82353] [8 Regression] runtime ubsan crash

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Oct 16 20:34:53 2017
New Revision: 253796

URL: https://gcc.gnu.org/viewcvs?rev=253796=gcc=rev
Log:
2017-10-16  Vladimir Makarov  

PR sanitizer/82353
* lra.c (collect_non_operand_hard_regs): Don't ignore operator
locations.
* lra-lives.c (bb_killed_pseudos, bb_gen_pseudos): Move up.
(make_hard_regno_born, make_hard_regno_dead): Update
bb_killed_pseudos and bb_gen_pseudos for fixed regs.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c
trunk/gcc/lra.c

[Bug c++/69078] [C++14] function local static not initialized when only used in a generic/variadic lambda

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
Hi,
I couldn't find the email where this patch was posted, so I reply here.

I've noticed that the new testcase:
>   PR c++/69078
>   * g++.dg/cpp1y/lambda-generic-69078-1.C: New.

fails on arm-none-eabi
--with-mode default
--with-cpu default
--with-fpu default

(that is, when the default arm target is an old, less-capable cpu).

The test fails to link for lack of __sync_synchronize.

In other occasions, a fix for this kind of problem was to add
// { dg-require-thread-fence "" }
but this doesn't work here, as this dg proc is only defined in the libstdc++
testsuite.

How to skip it here?

[Bug middle-end/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
  Component|fortran |middle-end
   Target Milestone|--- |7.3

--- Comment #3 from Thomas Koenig  ---
Some time reports:

$ gfortran -ffrontend-optimize -ftime-report pr82567.f90

Execution times (seconds)
 phase parsing   :   0.18 ( 5%) usr   0.01 ( 8%) sys   0.19 ( 5%) wall 
  5542 kB (11%) ggc
 phase opt and generate  :   3.55 (95%) usr   0.10 (83%) sys   3.66 (95%) wall 
 43204 kB (88%) ggc


$ gfortran -O -ftime-report pr82567.f90

Execution times (seconds)
 phase parsing   :   0.20 ( 1%) usr   0.01 (11%) sys   0.21 ( 1%) wall 
  5543 kB (15%) ggc
 phase opt and generate  :  26.96 (99%) usr   0.08 (89%) sys  27.07 (99%) wall 
 30881 kB (84%) ggc

The problem seems to be that we generate a load of statements like

  (*(real(kind=4)[1] * restrict) atmp.1.data)[0] = NON_LVALUE_EXPR
<__var_1_constr>;
  (*(real(kind=4)[1] * restrict) atmp.1.data)[1] = __var_1_constr *
2.0e+0;
  (*(real(kind=4)[1] * restrict) atmp.1.data)[2] = __var_1_constr *
3.0e+0;
  (*(real(kind=4)[1] * restrict) atmp.1.data)[3] = __var_1_constr *
4.0e+0;

for the test case as written below.

For the other versions, we actually do not convert the array descriptor.

[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug other/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
> So, if I compare the parameter values at this point in the working (r253529)
> and failing (r253530) code r6 holds the bad parm value:
> 
> failing:
> (gdb) info registers
> ...
> r6 0xfff007a  17587891077242
> 
> Works:
> (gdb) info registers
> ...
> r6 0x7a   122
> 
> 
> Why does this happen?  When it fails the value that is computed earlier in
> the code for the parameter
> 
>   iy = ((fy) >> 11);
> 
> is stored via an "stw" and then loaded via a "ld".  If there is any leftover
> garbage in the memory it will fail.  It doesn't always fail as sometimes the
> memory has 0 in the bytes not stored to via the stw and loaded via the ld.
> 
> So, looking at the assembly output:
> 
> works:
>0x10094f9c <.general_textured_triangle+2092>:  srawi   r8,r4,11
>0x10094fa0 <.general_textured_triangle+2096>:  std r8,29256(r1)
> ...
>0x100952c0 <.general_textured_triangle+2896>:  ld  r10,29256(r1)
>(this is then stored again and loaded into r6 for the function call via
> std/ld)
> 
> fails:
>0x10094d84 <.general_textured_triangle+2052>:  srawi   r9,r3,11
>0x10094d88 <.general_textured_triangle+2056>:  stw r9,29268(r1)
> ...
>0x10095094 <.general_textured_triangle+2836>:  ld  r10,29264(r1)
>(this is then stored again and loaded into r6 for the function call via
> std/ld)
> 
> Something in this revision causes the (working) std to be replaced by a stw.

Thanks for the preliminary analysis.  The change is supposed (1) to have an
effect only when there is an uninitialized variable in the code and (2) to
disable an unwarranted optimization.  That being said, it might also be
far-reaching enough to either expose another bug or trigger a conflict with
another part of the RTL back-end.  Can you attach a preprocessed testcase and a
command line?  FWIW I have access to gcc110 in the Compile Farm.

[Bug tree-optimization/82571] New: missing strlen optimization for memchr

[msebor at gcc dot gnu.org]

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

Bug ID: 82571
   Summary: missing strlen optimization for memchr
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The result of a call to memchr(a, '\0', sizeof a) where a is a nul-terminated
string is the same as (a + strlen (a)).  GCC could use this equivalence to
optimize code like that in functions f0() and f1() the same way it optimizes
functions g0() and g1().

$ gcc -O2 -S -fdump-tree-optimized=/dev/stdout a.c

;; Function f0 (f0, funcdef_no=0, decl_uid=1815, cgraph_uid=0, symbol_order=0)

f0 ()
{
  char * p;
  char a[9];

   [100.00%] [count: INV]:
  __builtin_memcpy (, "012345", 7);
  p_3 = __builtin_memchr (, 0, 9);
  if (p_3 == 0B)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  return;

}



;; Function f1 (f1, funcdef_no=1, decl_uid=1820, cgraph_uid=1, symbol_order=1)

f1 ()
{
  char * p;
  char a[9];
  long int p.0_1;
  long int a.1_2;
  long int _3;

   [100.00%] [count: INV]:
  __builtin_memcpy (, "012345", 7);
  p_8 = __builtin_memchr (, 0, 9);
  p.0_1 = (long int) p_8;
  a.1_2 = (long int) 
  _3 = p.0_1 - a.1_2;
  if (_3 != 6)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  return;

}



;; Function g0 (g0, funcdef_no=2, decl_uid=1825, cgraph_uid=2, symbol_order=2)

g0 ()
{
   [100.00%] [count: INV]:
  return;

}



;; Function g1 (g1, funcdef_no=3, decl_uid=1830, cgraph_uid=3, symbol_order=3)

g1 ()
{
   [100.00%] [count: INV]:
  return;

}

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
And with r241439, the test fails.

Andre, any ideas?

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
With r241438, the test passes.

[Bug c++/82570] New: Lambda fails to compile because it doesn't meet constexpr requirements

[andysem at mail dot ru]

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

Bug ID: 82570
   Summary: Lambda fails to compile because it doesn't meet
constexpr requirements
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Created attachment 42380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42380=edit
A testcase that shows the problem.

The attached program fails to compile with the following command line:

g++-7 -std=gnu++1z -o test_constexpr_lambda test_constexpr_lambda.cpp

test_constexpr_lambda.cpp: In instantiation of ‘foo(Pred):: [with
Pred = main()::]’:
test_constexpr_lambda.cpp:12:7:   required from ‘struct foo(Pred) [with Pred =
main()::]::’
test_constexpr_lambda.cpp:10:9:   required from ‘void foo(Pred) [with Pred =
main()::]’
test_constexpr_lambda.cpp:25:33:   required from here
test_constexpr_lambda.cpp:14:18: error: uninitialized variable ‘buf’ in
‘constexpr’ function
unsigned char buf[4];
  ^~~
test_constexpr_lambda.cpp:2:13: error: ‘void iterate(Body) [with Body =
foo(Pred) [with Pred = main()::]::]’, declared using
local type ‘foo(Pred) [with Pred = main()::]::’, is
used but never defined [-fpermissive]
 inline void iterate(Body body)
 ^~~
test_constexpr_lambda.cpp:2:13: warning: ‘void iterate(Body) [with Body =
foo(Pred) [with Pred = main()::]::]’ used but never
defined

The program compiles with -std=gnu++14. It also compiles successfully with gcc
6.3.0 and -std=gnu++1z (i.e. this is a regression since gcc 6).

I believe, this is a compiler bug because (a) neither the lambda nor the
calling code are marked constexpr and (b) according to
[expr.prim.lambda.closure]/4 the lambda should only be considered constexpr if
it meets constexpr requirements (otherwise it should be compiled as a regular
runtime function).

g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-1mind1'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1mind1)

[Bug fortran/78152] [6/7/8 Regression] coarray and associate

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #16 from Paul Thomas  ---
Fixed on trunk and 7-branch. I am sorry, I don't have the time to go back to
6-branch and fix it there.

Thanks for the report.

Paul

[Bug fortran/67543] ICE on associate with improper association

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Paul Thomas  ---
Fixed on trunk and 7-branch.

Thanks for the report.

Paul

[Bug fortran/82121] [7/8 Regression] Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Fixed on trunk and 7-branch.

Thanks for the report.

Paul

[Bug fortran/81903] [OOP] problem with ASSOCIATE and class pointer (Invalid character in name at)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk and 7-branch.

Thanks for the report.

Paul

[Bug fortran/80120] [7/8 Regression] Incorrect error with associate construct and character array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Fixed on trunk and 7-branch.

Thanks for the report.

Paul

[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Paul Thomas  ---
Fixed on trunk and 7-branch.

Thanks for the report.

Paul

[Bug fortran/67543] ICE on associate with improper association

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug tree-optimization/78512] [7 Regression] r242674 miscompiles Linux kernel

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug fortran/81903] [OOP] problem with ASSOCIATE and class pointer (Invalid character in name at)

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug fortran/78152] [6/7/8 Regression] coarray and associate

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug fortran/80120] [7/8 Regression] Incorrect error with associate construct and character array

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug fortran/82121] [7/8 Regression] Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 19:44:04 2017
New Revision: 253794

URL: https://gcc.gnu.org/viewcvs?rev=253794=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/52832
* match.c (gfc_match_associate): Before failing the association
try again, allowing a proc pointer selector.

PR fortran/80120
PR fortran/81903
PR fortran/82121
* primary.c (gfc_match_varspec): Introduce 'tgt_expr', which
points to the associate selector, if any. Go through selector
references, after resolution for variables, to catch any full
or section array references. If a class associate name does
not have the same declared type as the selector, resolve the
selector and copy the declared type to the associate name.
Before throwing a no implicit type error, resolve all allowed
selector expressions, and copy the resulting typespec.

PR fortran/67543
* resolve.c (resolve_assoc_var): Selector must cannot be the
NULL expression and it must have a type.

PR fortran/78152
* resolve.c (resolve_symbol): Allow associate names to be
coarrays.

2017-10-16  Paul Thomas  

PR fortran/78512
* gfortran.dg/associate_9.f03 : Remove XFAIL.
* gfortran.dg/associate_26.f90 : New test.

PR fortran/80120
* gfortran.dg/associate_27.f90 : New test.

PR fortran/81903
* gfortran.dg/associate_28.f90 : New test.

PR fortran/82121
* gfortran.dg/associate_29.f90 : New test.

PR fortran/67543
* gfortran.dg/associate_30.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03

[Bug sanitizer/82545] [7/8 Regression] -O2: ICE in gimple_split_edge, at tree-cfg.c:2838, during GIMPLE pass sanopt

[ivo.raisr at oracle dot com]

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

--- Comment #7 from Ivo Raisr  ---
If no viable solution to splitting an abnormal edge is found, I wonder if we
could actually prevent getting into this situation?

[Bug other/82569] New: [8 regression] failure in 177.mesa cpu2000 test case after r253530

[seurer at gcc dot gnu.org]

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

Bug ID: 82569
   Summary: [8 regression] failure in 177.mesa cpu2000 test case
after r253530
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This failure was notice on a powerpc64 be system.  Specifically, a power6
system.

The test case 177.mesa in the spec2000 test cases began failing with revision
253530 with a segmentation fault.  The failure occurs in "write_color_span" but
I traced it to a bad value in a parameter being passed to an earlier function. 
I noticed this when targeting power6x but the same bad code is generated for
power6.  power7/power8 generate different code.  I only saw the segmentation
fauit when the code was compiled with -O3.

(running in gdb...)
run -frames 1000 -meshfile mesa.in -ppmfile mesa.ppm

Program received signal SIGSEGV, Segmentation fault.
0x1006087c in .write_color_span ()
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.ppc64
(gdb) up
#1  0x100792f4 in .gl_write_texture_span ()
(gdb) up
#2  0x100952f4 in .general_textured_triangle ()
(gdb) x/10i $pc-24
   0x100952dc <.general_textured_triangle+3420>:std r16,120(r1)
   0x100952e0 <.general_textured_triangle+3424>:ld  r5,29104(r1)
   0x100952e4 <.general_textured_triangle+3428>:ld  r6,29088(r1)
   0x100952e8 <.general_textured_triangle+3432>:ld  r3,29200(r1)
   0x100952ec <.general_textured_triangle+3436>:std r12,29112(r1)
   0x100952f0 <.general_textured_triangle+3440>:bl  0x10079080
<.gl_write_texture_span>
=> 0x100952f4 <.general_textured_triangle+3444>:nop
   0x100952f8 <.general_textured_triangle+3448>:ld  r12,29112(r1)
   0x100952fc <.general_textured_triangle+3452>:lwz r9,29148(r1)
   0x10095300 <.general_textured_triangle+3456>:lwz r10,29124(r1)

So, if I compare the parameter values at this point in the working (r253529)
and failing (r253530) code r6 holds the bad parm value:

failing:
(gdb) info registers
...
r6 0xfff007a17587891077242

Works:
(gdb) info registers
...
r6 0x7a 122


Why does this happen?  When it fails the value that is computed earlier in the
code for the parameter

  iy = ((fy) >> 11);

is stored via an "stw" and then loaded via a "ld".  If there is any leftover
garbage in the memory it will fail.  It doesn't always fail as sometimes the
memory has 0 in the bytes not stored to via the stw and loaded via the ld.

So, looking at the assembly output:

works:
   0x10094f9c <.general_textured_triangle+2092>:srawi   r8,r4,11
   0x10094fa0 <.general_textured_triangle+2096>:std r8,29256(r1)
...
   0x100952c0 <.general_textured_triangle+2896>:ld  r10,29256(r1)
   (this is then stored again and loaded into r6 for the function call via
std/ld)

fails:
   0x10094d84 <.general_textured_triangle+2052>:srawi   r9,r3,11
   0x10094d88 <.general_textured_triangle+2056>:stw r9,29268(r1)
...
   0x10095094 <.general_textured_triangle+2836>:ld  r10,29264(r1)
   (this is then stored again and loaded into r6 for the function call via
std/ld)

Something in this revision causes the (working) std to be replaced by a stw.


The source is really ugly and is a bunch of macros defined in functions that
then #include code that uses the macros.  (Good grief, who wrote this?)  I
haven't been able to whittle down the code much from the original source. 
Trying to duplicate the problem from scratch also hasn't worked; with both
253529 and 253530 the store after the >> is an stw and the parameter load for
the function call is an lwa.

If I generate a .i from the code this is the "bad" part:

# 483 "tritemp.h"
{
int subTriangle;
GLfixed fx, fxLeftEdge, fxRightEdge, fdxLeftEdge, fdxRightEdge;
GLfixed fdxOuter;
int idxOuter;
float dxOuter;
GLfixed fError, fdError;
float adjx, adjy;
GLfixed fy;
int iy;
GLdepth *zRow;
int dZRowOuter, dZRowInner;
GLfixed fz, fdzOuter, fdzInner;
GLfixed fr, fdrOuter, fdrInner;
GLfixed fg, fdgOuter, fdgInner;
GLfixed fb, fdbOuter, fdbInner;
GLfixed fa, fdaOuter, fdaInner;
# 518 "tritemp.h"
GLfloat sLeft, dsOuter, dsInner;
GLfloat tLeft, dtOuter, dtInner;
GLfloat wLeft, dwOuter, dwInner;
GLfloat uLeft, duOuter, duInner;
GLfloat vLeft, dvOuter, dvInner;
for (subTriangle=0;
 

[Bug fortran/81048] [6/7/8 Regression] incorrect derived type initialization

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Mon Oct 16 18:48:56 2017
New Revision: 253793

URL: https://gcc.gnu.org/viewcvs?rev=253793=gcc=rev
Log:
2017-10-16  Paul Thomas  

PR fortran/81048
* resolve.c (resolve_symbol): Ensure that derived type array
results get default initialization.

2017-10-16  Paul Thomas  

PR fortran/81048
* gfortran.dg/derived_init_4.f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/derived_init_4.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 CC||foreese at gcc dot gnu.org
 Resolution|WONTFIX |FIXED
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #5 from Fritz Reese  ---
For the record: support for DEC STRUCTURE/RECORD was introduced in r235999 in
gcc-7 and was also backported to gcc-6. Marking this as FIXED.

[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> The change occurred between revisions r197010 (2013-03-23, fast) and r197238
> (2013-03-29, slow), likely r197217.

More likely r197216.

[Bug fortran/82568] [6/7/8] ICE with do-loop inside BLOCK inside omp

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.5.4 up to trunk (8.0). I don't know if the code is valid.

[Bug middle-end/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The test compiles in a fraction of a second with
-fno-frontend-optimize.

The change occurred between revisions r197010 (2013-03-23, fast) and r197238
(2013-03-29, slow), likely r197217.

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[liakhdi at ornl dot gov]

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

--- Comment #10 from DIL  ---
(In reply to Thomas Koenig from comment #9)
> I just checked on powerpc64 with a rather current trunk with
> 
>  gfc::bank testing status:0 (PASSED): Performance:   
> 2888199.6889235629 
>  gfc::vector testing status:0 (PASSED): Performance:   
> 2108461.4164096378 
>  gfc::list testing status:0 (PASSED): Performance:   
> 2108461.4164096378 
>  gfc::tree testing status:0 (PASSED): Performance:   
> 327471.70199407206 
>  gfc::dictionary testing status:0 (PASSED): Performance:   
> 281461.77688575117 
>16383
>  gfc::graph testing status:5 (FAILED)
>  Multi-index sort testing status:0 (PASSED): Performance:   
> 120529.43369575262 
>  Dynamic type inferrence slowdown:   0.2418 67110738.2064877   0.5810   
> 67110738.20648772.4023336875488646 
> 
> Is this an indication of success or of failure?

It is a failure, seems to occur along the same code path, but without a
SegFault.

[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

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

--- Comment #8 from Fritz Reese  ---
(In reply to Steve Kargl from comment #4)
...
> 
>   program bug
>   structure /bckt/
>  union
> map
>character*16 c16
> end map
>  end union
>   end structure
>   record /bckt/ bucket
>   character(len=16) :: rec1 = 'ABCDEFGHIJKLMNOP'
>   100 format(A16)
>   read(rec1, 100) bckt
>   end program bug
> 
> where one is trying read into the definition of the structure.
> Is the above suppose to compile?  Because it does.  [...]

Steve- on second glance, the above program is correct, even though it is
misleading. It compiles because there is no IMPLICIT NONE, so the variable BCKT
is an implicit variable created at the point of use. The program above behaves
equivalently if STRUCTURE /bckt/ is never declared, and issues an appropriate
error with IMPLICIT NONE:

program bug
implicit none
structure /bckt/
[...]
read(rec1, 100) bckt
end program bug

$ gfortran -fdec-structure bug.for
bug.for:12:26:

   read(rec1, 100) bckt
  1
Error: Symbol ‘bckt’ at (1) has no IMPLICIT type

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
I just checked on powerpc64 with a rather current trunk with

 gfc::bank testing status:0 (PASSED): Performance:   
2888199.6889235629 
 gfc::vector testing status:0 (PASSED): Performance:   
2108461.4164096378 
 gfc::list testing status:0 (PASSED): Performance:   
2108461.4164096378 
 gfc::tree testing status:0 (PASSED): Performance:   
327471.70199407206 
 gfc::dictionary testing status:0 (PASSED): Performance:   
281461.77688575117 
   16383
 gfc::graph testing status:5 (FAILED)
 Multi-index sort testing status:0 (PASSED): Performance:   
120529.43369575262 
 Dynamic type inferrence slowdown:   0.2418 67110738.2064877   0.5810
67110738.20648772.4023336875488646 

Is this an indication of success or of failure?

[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure

[foreese at gcc dot gnu.org]

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

--- Comment #7 from Fritz Reese  ---
Author: foreese
Date: Mon Oct 16 17:40:53 2017
New Revision: 253791

URL: https://gcc.gnu.org/viewcvs?rev=253791=gcc=rev
Log:
2017-10-16  Fritz Reese 

PR fortran/82511
Treat UNION components as DT comp. in I/O lists.

gcc/fortran/ChangeLog:

PR fortran/82511
* trans-io.c (transfer_expr): Treat BT_UNION as BT_DERIVED.

gcc/testsuite/ChangeLog:

PR fortran/82511
* gfortran.dg/dec_structure_22.f90: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/dec_structure_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog

[Bug other/82547] wide_int is not setting overflow properly for large unsigned add/subtract calculations.

[amacleod at redhat dot com]

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

--- Comment #1 from Andrew Macleod  ---
On a further note, this appears to be because wide_int tries not to use all the
words is it can sign extend?

the sequence with the issue is:
 Mn = wi::min_value (128, UNSIGNED);
 Mx = wi::max_value (128, UNSIGNED);
 Mxminus2  = wi::sub (Mx, 2, UNSIGNED, );
 x = wi::sub (Mn, Mxminus2 , UNSIGNED, );
 fprintf (stderr, "ov %d  ov2 %d\n", ov, ov2);

if I look at Mn, I see:

(gdb) p Mn.dump()
[...,0], precision = 128

(gdb) p Mn
$14 = { = {val = {0, 140737488344128, 34794152}, len = 1,
precision = 128}, static is_sign_extended = }

So the precision is 128, but len is set to 1 on a 64 bit host.
Same thing happens for Mx.

Then when wi::sub_large is called, it does the calculation and checks:
 if (len * HOST_BITS_PER_WIDE_INT < prec)
{
  val[len] = mask0 - mask1 - borrow;
  len++;
  if (overflow)
*overflow = false;
}

Since both values have a len of 1, and precision is 128, it decides there
cannot be an overflow.  It seems to be ignoring that fgact that sign-extension
may exist.


Interestingly, if I remove that entire hunk of code, and and let it do the
general check for overflow which follows, It works as I would expect.

Of course, I have no idea what the side effects of that are... 
I leave it in the hands of a wide_int expert.

[Bug c++/82566] Internal compiler error in type deduction (with C++11)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
gcc 4.9 isn't supported anymore. See the gcc homepage for the list 
of currently supported releases.

[Bug fortran/82568] New: ICE with do-loop inside BLOCK inside omp

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 82568
   Summary: ICE with do-loop inside BLOCK inside omp
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

gfortran gives an internal compiler error with this code :

PROGRAM OMP_BLOCK
  IMPLICIT NONE

  INTEGER :: I !,J

  !$OMP PARALLEL DO !PRIVATE(J)
  ! Declaring j outside of OMP and put it in private solves the problem
  DO I=1,2
BLOCK
  INTEGER :: J

  DO J=1,2
PRINT*,I,J
  END DO

END BLOCK
  END DO

END PROGRAM OMP_BLOCK

tested with gfortran 6/7/8 Linux-64 and gfortran-7 MinGW-64

[Bug fortran/82567] New: [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 82567
   Summary: [6/7/8] gfortran takes a long time to compile a simple
implied-do with -Optimization.
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

gfortran takes about 11s to compile this simple subroutine with -O1 :

  SUBROUTINE sub()
  IMPLICIT NONE

  INTEGER, PARAMETER :: n = 1
  REAL, ALLOCATABLE :: x(:)
  REAL :: xc, h
  INTEGER :: i

  ALLOCATE( x(n) )
  xc = 100.
  h = xc/n
  x = h*[(i,i=1,n)]
  ! Replacing the previous line with one of these lines gives faster
compilation
  ! x = [(i*h,i=1,n)]
  ! x = (100./n) *[(i,i=1,n)] 

END SUBROUTINE sub

time gfortran -O1 -c test.f90:
real0m11.167s

the time increases with n (-O1) :
n| 1 | 2 | 3 | 4
-
time | 11s   | 25s   | 43s   | 1m7s

and decrease with the level of optimization (n=2) :
-Ox  | -O1 | -O2 | -O3 | -Ofast
---
time | 20s | 15s | 15s | 8s

tested with gfortran 6/7/8 Linux-64 and gfortran-7 MinGW-64

[Bug c++/82566] Internal compiler error in type deduction (with C++11)

[peter.gottschling at simunova dot com]

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

--- Comment #1 from Peter Gottschling  
---
Created attachment 42379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42379=edit
Preprocessed source compressed with bzip2.

[Bug c++/82566] New: Internal compiler error in type deduction (with C++11)

[peter.gottschling at simunova dot com]

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

Bug ID: 82566
   Summary: Internal compiler error in type deduction (with C++11)
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.gottschling at simunova dot com
  Target Milestone: ---

Compiler error occurs only with g++-4.9. Other g++ versions (e.g. 4.7, 5, 7)
work smoothly. Preprocessed source attached.

[Bug middle-end/82564] ICE at -O1 and above: in assign_stack_temp_for_type, at function.c:783

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 8081.

[Bug middle-end/82564] ICE at -O1 and above: in assign_stack_temp_for_type, at function.c:783

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There might be a dup of this bug already filed too.

[Bug c++/82565] New: Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[haaawk at gmail dot com]

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

Bug ID: 82565
   Summary: Concept and lambda return type deduction cause
compilation to crash with "mmap: Cannot allocate
memory"
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haaawk at gmail dot com
  Target Milestone: ---

Created attachment 42378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42378=edit
file that crashes compilation "g++ -fconcepts crash.cpp"

The file I attached crashes the following compilation:

g++ -fconcepts crash.cpp

both on GCC 7.1.1 and GCC 7.2.

GCC 7.1.1 gives the following result:

crash.cpp: In instantiation of ‘run_test():: [with auto:1 =
const std::__cxx11::basic_string]’:
crash.cpp:9:12:   required from here
crash.cpp:49:58: internal compiler error: Segmentation fault
 return object.visit([] (auto& x) { return x.empty(); });

GCC 7.2 gives the following result:

crash.cpp: In instantiation of 'run_test():: [with auto:1 =
const std::__cxx11::basic_string]':
crash.cpp:9:12:   required from here
crash.cpp:49:58: internal compiler error: Segmentation fault
 return object.visit([] (auto& x) { return x.empty(); });
  ^
mmap: Cannot allocate memory

The file compiles correctly after commenting out line 31 which applies Concept
to visit method:

requires Concept()))>()

or after explicit declaration of the return type to "-> bool" on lambda in line
49:

return object.visit([] (auto& x) -> bool { return x.empty(); });

Below I'm pasting the content of the crash.cpp file:

#include
#include
#include
#include

template
concept bool Concept() {
return requires(T t, const std::string& s, const std::vector& v) {
{ t(s) } -> ReturnType;
{ t(v) } -> ReturnType;
};
}

struct test {
enum class kind {
string, vector
};
struct data {
data() { }
~data() { }

union {
std::string _str;
std::vector _v;
};
};
kind _kind;
std::unique_ptr _data;

template
requires Concept()))>()
decltype(auto) visit(Visitor&& visitor) const {
switch (_kind) {
case kind::string:
return visitor(_data->_str);
case kind::vector:
return visitor(_data->_v);
}
abort();
}

};

bool run_test() {
test object;
object._kind = test::kind::string;
object._data = std::make_unique();
new (_data->_str) std::string("hello test");
return object.visit([] (auto& x) { return x.empty(); });
}

int main() {
std::cout << run_test() << std::endl;
return 0;
}

[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=39170
 Blocks||44209
Summary|enum class bitfield |enum class bitfield
   |size-checking failure   |size-checking needs a
   ||separate warning flag
   ||controlling it

--- Comment #14 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #7)
> At the very least there should be a -Wxxx switch controlling this option so
> it can be disabled.

Agreed, that falls under bug 44209; retitling this one accordingly.

(In reply to Sam van Kampen from comment #13)
> I've sent a patch that adds the warning flag -Wbitfield-enum-conversion to
> gcc-patches, and the gcc mailing list now also has a thread on the bug, and
> I thought I might share them on the bug tracker:
> 
> The patch:
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00989.html
> 
> The thread on the bug:
> https://gcc.gnu.org/ml/gcc/2017-10/msg00121.html

The name chosen for the flag makes it sound kinda related to bug 39170 but I
guess the "enum" in the middle is enough of a differentiator.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
[Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options

[Bug c/82564] New: ICE at -O1 and above: in assign_stack_temp_for_type, at function.c:783

[su at cs dot ucdavis.edu]

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

Bug ID: 82564
   Summary: ICE at -O1 and above: in assign_stack_temp_for_type,
at function.c:783
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to affect at least as early as 4.8.x. 


$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171016 (experimental) [trunk revision 253785] (GCC) 
$ 
$ gcctk -O0 small.c
$  
$ gcctk -O1 small.c
during RTL pass: expand
small.c: In function ‘main’:
small.c:17:5: internal compiler error: in assign_stack_temp_for_type, at
function.c:783
   a = f ();
   ~~^~
0x973b2b assign_stack_temp_for_type(machine_mode, long, tree_node*)
../../gcc-source-trunk/gcc/function.c:783
0x973be3 assign_temp(tree_node*, int, int)
../../gcc-source-trunk/gcc/function.c:999
0x7d4914 expand_call(tree_node*, rtx_def*, int)
../../gcc-source-trunk/gcc/calls.c:3135
0x907710 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:10869
0x91a63d expand_normal
../../gcc-source-trunk/gcc/expr.h:282
0x91a63d store_field
../../gcc-source-trunk/gcc/expr.c:6843
0x916631 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-source-trunk/gcc/expr.c:5170
0x7e95aa expand_call_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:2664
0x7e95aa expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3585
0x7e95aa expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3751
0x7eb442 expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5754
0x7f0e46 execute
../../gcc-source-trunk/gcc/cfgexpand.c:6361
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ 


--


int main ()
{
  int t = 8;

  typedef struct
  {
char v[t];
  } B; 

  B a, b;

  B __attribute__ ((noinline)) f ()
  {
return b; 
  }

  a = f ();

  return 0;
}

[Bug c++/64931] ICE on function with deduced return type and input is instantiated template class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/64931] ICE on function with deduced return type and input is instantiated template class

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct 16 14:21:17 2017
New Revision: 253788

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

PR c++/64931
* g++.dg/cpp1y/auto-fn43.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn43.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/82498] Missed optimization for x86 rotate instruction

[lloyd at randombit dot net]

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

--- Comment #17 from Jack Lloyd  ---
Thank you!

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

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Seen also with:

void test ()
{
  FILE *f;
}

for which g++ prints the nonsensical:

t.cc: In function ‘void test()’:
t.cc:3:3: error: ‘FILE’ was not declared in this scope
   FILE *f;
   ^~~~
t.cc:3:9: error: ‘f’ was not declared in this scope
   FILE *f;
 ^
t.cc:3:9: note: suggested alternative: ‘if’
   FILE *f;
 ^
 if

[Bug tree-optimization/82563] New: [8 Regression] [graphite] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709

[asolokha at gmx dot com]

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

Bug ID: 82563
   Summary: [8 Regression] [graphite] ICE in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171015 (r253772) ICEs when compiling the following snippet w/
-O3 (or -Ofast) -floop-nest-optimize (or -floop-parallelize-all):

int tj, cw, xf;

void
zp (int *ei)
{
  for (;;)
{
  int hd = 0;

  if (cw != 0 && xf != 0)
{
  for (hd = 0; hd < 3; ++hd)
cw = (tj != 0) ? 0 : *ei;
  for (;;)
{
}
}

  while (tj != 0)
tj = 
}
}

% gcc-8.0.0-alpha20171015 -O3 -floop-nest-optimize -w -c dyx0j2oa.c
during GIMPLE pass: graphite
dyx0j2oa.c: In function 'zp':
dyx0j2oa.c:4:1: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
 zp (int *ei)
 ^~

check_loop_closed_ssa_def() has been introduced in r253161.

[Bug target/82442] vect/pr31699.c fails on arm

[wilco at gcc dot gnu.org]

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

--- Comment #1 from Wilco  ---
Author: wilco
Date: Mon Oct 16 13:26:20 2017
New Revision: 253786

URL: https://gcc.gnu.org/viewcvs?rev=253786=gcc=rev
Log:
Fix PR82442

Recently the gcc.dg/vect/pr31699.c was modified to check for
vect_float effective target instead for vect_double.  As a 
result it now fails on armhf.  Fix by avoiding double.
Tested on armhf, aarch64 and x64.

gcc/testsuite/
PR target/82442
* gcc.dg/vect/pr31699.c: Fix testcase.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr31699.c

[Bug gcov-profile/82527] Branch probabilities does not match on optimized switch cases

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
Thanks for the issue. Note that order of branches which go from switch
statement to corresponding case labels is not ordered.
With new GCC 8.1, we'll come up with '-w' option. Then you'll see the
connections (edges):

$ rm *.gcda && gcc  pr82527.c --coverage && ./a.out && gcov -abw pr82527.c &&
cat pr82527.c.gcov
0dddFile
'pr82527.c'
Lines executed:83.33% of 12
Branches executed:100.00% of 5
Taken at least once:80.00% of 5
No calls
Creating 'pr82527.c.gcov'

-:0:Source:pr82527.c
-:0:Graph:pr82527.gcno
-:0:Data:pr82527.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:int
function main called 1 returned 100% blocks executed 91%
1:3:main ()
-:4:{
  101:5:  for (int i = 0; i < 100; i++)
1:5-block  0 (BB 2)
  100:5-block  1 (BB 9)
  101:5-block  2 (BB 10)
branch  0 taken 99% (BB 3)
branch  1 taken 1% (fallthrough) (BB 11)
-:6:{
  100:7:  switch (i)
  100:7-block  0 (BB 3)
branch  0 taken 1% (BB 4)
branch  1 taken 0% (BB 6)
branch  2 taken 99% (BB 7)
-:8:{
1:9:case 0:
1:   10:  printf ("0");
1:   10-block  0 (BB 4)
call0 returned 100%
1:   11:  break;
#:   12:case :
#:   13:  break;
$:   13-block  0 (BB 6)
   99:   14:default:
   99:   15:  printf ("d");
   99:   15-block  0 (BB 7)
call0 returned 100%
   99:   16:  break;
-:   17:}
-:   18:}
1:   19:  return 0;
1:   19-block  0 (BB 11)
-:   20:}

$ rm *.gcda && gcc -O3 pr82527.c --coverage && ./a.out && gcov -abw pr82527.c
&& cat pr82527.c.gcov
0dddFile
'pr82527.c'
Lines executed:100.00% of 9
Branches executed:100.00% of 4
Taken at least once:75.00% of 4
No calls
Creating 'pr82527.c.gcov'

-:0:Source:pr82527.c
-:0:Graph:pr82527.gcno
-:0:Data:pr82527.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:int
function main called 1 returned 100% blocks executed 100%
1:3:main ()
-:4:{
  101:5:  for (int i = 0; i < 100; i++)
1:5-block  0 (BB 2)
  100:5-block  1 (BB 8)
  101:5-block  2 (BB 9)
branch  0 taken 99% (BB 3)
branch  1 taken 1% (fallthrough) (BB 10)
-:6:{
  100:7:  switch (i)
  100:7-block  0 (BB 3)
branch  0 taken 1% (BB 4)
branch  1 taken 99% (BB 6)
branch  2 taken 0% (BB 8)
-:8:{
1:9:case 0:
1:   10:  printf ("0");
1:   10-block  0 (BB 4)
call0 returned 100%
1:   11:  break;
-:   12:case :
-:   13:  break;
   99:   14:default:
   99:   15:  printf ("d");
   99:   15-block  0 (BB 6)
call0 returned 100%
   99:   16:  break;
-:   17:}
-:   18:}
-:   19:  return 0;
-:   20:}

And you're right w/ -O3 it goes to a different BB and order is changed.
Hope it will help you? I'm closing it as invalid.

[Bug c++/61414] enum class bitfield size-checking failure

[sam at segfault dot party]

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

Sam van Kampen  changed:

   What|Removed |Added

 CC||sam at segfault dot party

--- Comment #13 from Sam van Kampen  ---
I've sent a patch that adds the warning flag -Wbitfield-enum-conversion to
gcc-patches, and the gcc mailing list now also has a thread on the bug, and I
thought I might share them on the bug tracker:

The patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00989.html

The thread on the bug:
https://gcc.gnu.org/ml/gcc/2017-10/msg00121.html

[Bug tree-optimization/82545] [7/8 Regression] -O2: ICE in gimple_split_edge, at tree-cfg.c:2838, during GIMPLE pass sanopt

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
What we do:

a ()
{
  int b;
  int b.0_1;

   [100.00%] [count: INV]:
  __builtin_setjmp_setup (0B, &);
  goto ; [99.96%] [count: INV]

   [0.12%] [count: INV]:
:
  __builtin_setjmp_receiver (&);
  goto ; [100.00%] [count: INV]

   [0.12%] [count: INV]:
  # b_12(ab) = PHI 
  __builtin___asan_handle_no_return ();
  ABNORMAL_DISPATCHER (0);

   [99.96%] [count: INV]:

   [99.96%] [count: INV]:
  # b_13(ab) = PHI 
  b.0_1 = b_13(ab);
  c (b.0_1);

   [99.92%] [count: INV]:
  b_15(ab) = ASAN_POISON ();
  d ();

   [99.88%] [count: INV]:
  return;

}

We expand ASAN_POISON and we propagate ASAN report function on all edges. In
this case  ->  is an abnormal edge, that we can't split.
Thoughts?

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL||https://github.com/google/s
   ||anitizers/issues/869

--- Comment #2 from Martin Liška  ---
I've just done upstream bug for this.

[Bug c++/82562] Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Markus Trippelsdorf  ---
https://github.com/ricardoquesada/Spidermonkey/blob/4a75ea2543408bd1b2c515aa95901523eeef7858/js/src/gc/Barrier.h#L940

Class HeapSlot is not trivially-copyable.

[Bug c++/82562] Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Andi from comment #0)
> In file included from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:24:0:
> /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h: In member function
> 'void js::NativeObject::initDenseElements(const JS::Value*, uint32_t)':
> /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h:184:52: error: 'void*
> memcpy(void*, const void*, size_t)' writing to an object of non-trivially
> copyable type 'class js::HeapSlot'; use copy-assignment or
> copy-initialization instead [-Werror=class-memaccess]
>  memcpy(elements_, src, count * sizeof(HeapSlot));
> 
> I don't think that the warning is valid since what we try to do is copy in
> eleements_ the number of 'count' elements of type HeadSlop from src.

Why would that mean it's not valid? Is the class trivially-copyable or not? If
it isn't, then using memcpy is undefined.

Please read https://gcc.gnu.org/bugs/ and provide the preprocessed code.

[Bug libstdc++/57925] discrete_distribution can be improved to O(1) per sampling

[t.e.knigge at gmail dot com]

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

--- Comment #10 from Timon Knigge  ---
(In reply to Jonathan Wakely from comment #9)
> Yes it's still open, so a fix would be welcome. Please see
> http://gcc.gnu.org/contribute.html if you want to contribute a fix for it.

W.r.t. to the 'legal' paragraph: I work at Google which would assert ownership
over the code by default. Is the CLA the FSF already has with them sufficient?

[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
Seems to have started with r244882

[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Further reduced:

extern "C" int printf(const char*, ...);

struct Foo {
  Foo(const char *) {
printf("%p\tFoo(const char*)\n", this);
  }
  ~Foo() {
printf("%p\t~Foo()\n", this);
  }
};

struct Bar {
  Bar(Foo foo = "") { }
  ~Bar() { }
};

int main()
{
  delete new Bar();
}

[Bug c++/82562] New: Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects.

[andi at mozilla dot com]

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

Bug ID: 82562
   Summary: Incorrect warning: use copy-assignment or
copy-initialization instead when copying build
objects.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi at mozilla dot com
  Target Milestone: ---

Trying to build firefox with gcc8 I get this error, when building with treat
-Werror:

/usr/bin/g++-8 -std=gnu++11 -o RegExp.o -c
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include
/root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1 -DENABLE_BINARYDATA
-DENABLE_SIMD -DENABLE_WASM_THREAD_OPS -DWASM_HUGE_MEMORY -DJS_CACHEIR_SPEW
-DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES
'-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DFFI_BUILDING -DMOZ_HAS_MOZGLUE
-I/root/firefox-gcc-last/js/src
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/ctypes/libffi/include
-I/root/firefox-gcc-last/js/src/ctypes/libffi/src/x86
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/nspr  -fPIC 
-DMOZILLA_CLIENT -include
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF
.deps/RegExp.o.pp  -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits
-Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat
-Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat
-Wformat-overflow=2 -Wno-noexcept-type -fno-rtti -fno-exceptions
-fno-math-errno -pthread -pipe  -g -freorder-blocks -O3 -fno-omit-frame-pointer
 -Werror -Wno-shadow -Werror=format -fno-strict-aliasing  
/root/firefox-gcc-last/js/src/builtin/RegExp.cpp
In file included from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:24:0:
/root/firefox-gcc-last/js/src/vm/NativeObject-inl.h: In member function 'void
js::NativeObject::copyDenseElements(uint32_t, const JS::Value*, uint32_t)':
/root/firefox-gcc-last/js/src/vm/NativeObject-inl.h:155:67: error: 'void*
memcpy(void*, const void*, size_t)' writing to an object of non-trivially
copyable type 'class js::HeapSlot'; use copy-assignment or copy-initialization
instead [-Werror=class-memaccess]
 memcpy(_[dstStart], src, count * sizeof(HeapSlot));
   ^
In file included from /root/firefox-gcc-last/js/src/jsatom.h:15:0,
 from /root/firefox-gcc-last/js/src/vm/Runtime.h:22,
 from /root/firefox-gcc-last/js/src/jscntxt.h:21,
 from /root/firefox-gcc-last/js/src/vm/RegExpObject.h:15,
 from /root/firefox-gcc-last/js/src/builtin/RegExp.h:10,
 from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:7:
/root/firefox-gcc-last/js/src/gc/Barrier.h:655:7: note: 'class js::HeapSlot'
declared here
 class HeapSlot : public WriteBarrieredBase
   ^~~~
In file included from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:24:0:
/root/firefox-gcc-last/js/src/vm/NativeObject-inl.h: In member function 'void
js::NativeObject::initDenseElements(const JS::Value*, uint32_t)':
/root/firefox-gcc-last/js/src/vm/NativeObject-inl.h:184:52: error: 'void*
memcpy(void*, const void*, size_t)' writing to an object of non-trivially
copyable type 'class js::HeapSlot'; use copy-assignment or copy-initialization
instead [-Werror=class-memaccess]
 memcpy(elements_, src, count * sizeof(HeapSlot));

I don't think that the warning is valid since what we try to do is copy in
eleements_ the number of 'count' elements of type HeadSlop from src.

[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||wrong-code
   Last reconfirmed||2017-10-16
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=49372
 Ever confirmed|0   |1
Summary|Temporary object created as |[7/8 Regression] Temporary
   |a default argument not  |object created as a default
   |destructed  |argument not destructed
   Target Milestone|--- |7.3
  Known to fail||7.2.0, 8.0

--- Comment #1 from Jonathan Wakely  ---
Confirmed:

extern "C" int printf(const char*, ...);

struct Foo {
  Foo(const char *) {
printf("%p\tFoo(const char*)\n", this);
  }
  Foo(const Foo&) {
printf("%p\tFoo(const Foo&)\n", this);
  }
  ~Foo() {
printf("%p\t~Foo()\n", this);
  }
};

struct Bar {
  Bar(Foo foo = "implicitly casted to Foo") : foo_(foo) {
printf("%p\tBar(Foo)\n", this);
  }
  ~Bar() {
printf("%p\t~Bar()\n", this);
  }

  Foo foo_;
};

template
struct unique_ptr
{
  unique_ptr(T* p) : p(p) { }
  ~unique_ptr() { delete p; }
  T* p;
};

int main()
{
  {
printf("OK:\n");
unique_ptr p1(new Bar);
  }
  {
printf("Wrong:\n");
unique_ptr p2(new Bar());
  }
}

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[sylvestre at debian dot org]

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

Sylvestre Ledru  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #7 from Sylvestre Ledru  ---
I asked Doko to upload a new version of gcc 8 into Debian so that I can test
again (at least about a month old). If still occurring, I will try to get a
test case.

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #6 from Markus Trippelsdorf  ---
Thanks. Unfortunately I cannot reproduce the issue.

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[sylvestre at debian dot org]

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

--- Comment #5 from Sylvestre Ledru  ---
Created attachment 42377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42377=edit
the .ii

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[sylvestre at debian dot org]

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

--- Comment #4 from Sylvestre Ledru  ---
Created attachment 42376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42376=edit
the .s

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
OK, thanks. Can you please also attach the --save-temps -fdirectives-only file?

[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclarations should be forbidden

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||filip.roseen at gmail dot com

--- Comment #19 from Paolo Carlini  ---
*** Bug 61471 has been marked as a duplicate of this bug. ***

[Bug c++/61471] redeclaration of default-argument in function template declaration not caught

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Paolo Carlini  ---
Dup.

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

[Bug c++/61472] added default-argument in later declaration of function template not caught

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jonathan Wakely  ---
Like PR 61471, this is fixed in 5.1.0, probably by the same patch, so I'm
marking it as a dup.

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

[Bug c++/61471] redeclaration of default-argument in function template declaration not caught

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
*** Bug 61472 has been marked as a duplicate of this bug. ***

[Bug c++/61471] redeclaration of default-argument in function template declaration not caught

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Fixed in GCC 5.1.0:

d.cc:2:31: error: redeclaration of ‘template void f(int)’ may not have
default arguments [-fpermissive]
 template void f(int=3); // ill-formed
   ^

If we don't have one, we should add a testcase for this and close it.

[Bug c++/59002] [meta-bug] Access checking in templates

[redi at gcc dot gnu.org]

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

Bug 58896 Summary: Incorrect handling of a private nested type of a template 
specialization in the main template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58896

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/58896] Incorrect handling of a private nested type of a template specialization in the main template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
I don't think it's relevant that one of the types is a specialization of the
other, the same thing happens with unrelated classes, which is PR 47346.

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

[Bug c++/47346] access control for nested type is ignored in class template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #16 from Jonathan Wakely  ---
*** Bug 58896 has been marked as a duplicate of this bug. ***

[Bug c/71996] -fdump-translation-unit fails to dump string literals of type char16_t/char32_t/wchar_t

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
The raw dump is not an interchange format.

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[sylvestre at debian dot org]

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

--- Comment #2 from Sylvestre Ledru  ---
Created attachment 42375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42375=edit
preprocessed file

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
(In reply to Sylvestre Ledru from comment #0)
> Building the preproccessed file doesn't trigger the bug.
> I haven't been able to generate a test case yet.

Could you please attach it nonetheless?

[Bug c++/82561] New: [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[sylvestre at debian dot org]

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

Bug ID: 82561
   Summary: [8 regression] crash on internal compiler error: in
cp_tree_equal, at cp/tree.c:3778
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sylvestre at debian dot org
  Target Milestone: ---

Trying to build Firefox using g++8 (from Debian exp), version 8-20170923-1

 /usr/bin/g++-8 -std=gnu++11 -c
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include
/root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1 -std=gnu++11 -o jsatom.o
-c -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers
-include /root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1
-DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_WASM_THREAD_OPS -DWASM_HUGE_MEMORY
-DJS_CACHEIR_SPEW -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES
'-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DFFI_BUILDING -DMOZ_HAS_MOZGLUE
-I/root/firefox-gcc-last/js/src
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/ctypes/libffi/include
-I/root/firefox-gcc-last/js/src/ctypes/libffi/src/x86
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/nspr  -fPIC 
-DMOZILLA_CLIENT -include
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF
  -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual
-Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wduplicated-cond
-Wimplicit-fallthrough -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -Wno-noexcept-type
-fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe  -g -freorder-blocks
-O3 -fno-omit-frame-pointer  -Werror -Wno-shadow -Werror=format  
$OLDPWD/jsatom.cpp 
In file included from
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/HashFunctions.h:50:0,
 from /root/firefox-gcc-last/js/src/jsatom.h:10,
 from /root/firefox-gcc-last/js/src/jsatominlines.h:10,
 from /root/firefox-gcc-last/jsatom.cpp:2:
/root/firefox-gcc-last/js/src/jit/RegisterSets.h: In member function 'void
js::jit::SpecializedRegSet::add(js::jit::FloatRegister)':
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:417:71:
internal compiler error: in cp_tree_equal, at cp/tree.c:3778
 
static_assert(mozilla::detail::AssertionConditionType::isValid, \
   ^
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:432:5:
note: in expansion of macro 'MOZ_VALIDATE_ASSERT_CONDITION_TYPE'
 MOZ_VALIDATE_ASSERT_CONDITION_TYPE(expr); \
 ^~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:450:39:
note: in expansion of macro 'MOZ_ASSERT_HELPER1'
 #define MOZ_RELEASE_ASSERT_GLUE(a, b) a b
   ^
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:452:3:
note: in expansion of macro 'MOZ_RELEASE_ASSERT_GLUE'
   MOZ_RELEASE_ASSERT_GLUE( \
   ^~~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/MacroArgs.h:16:26:
note: in expansion of macro 'MOZ_CONCAT2'
 #define MOZ_CONCAT(x, y) MOZ_CONCAT2(x, y)
  ^~~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/MacroArgs.h:73:51:
note: in expansion of macro 'MOZ_CONCAT'
 #define MOZ_PASTE_PREFIX_AND_ARG_COUNT_GLUE(a, b) a b
   ^
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/MacroArgs.h:75:3:
note: in expansion of macro 'MOZ_PASTE_PREFIX_AND_ARG_COUNT_GLUE'
   MOZ_PASTE_PREFIX_AND_ARG_COUNT_GLUE( \
   ^~~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:453:5:
note: in expansion of macro 'MOZ_PASTE_PREFIX_AND_ARG_COUNT'
 MOZ_PASTE_PREFIX_AND_ARG_COUNT(MOZ_ASSERT_HELPER, __VA_ARGS__), \
 ^~
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:457:27:
note: in expansion of macro 'MOZ_RELEASE_ASSERT'
 #  define MOZ_ASSERT(...) MOZ_RELEASE_ASSERT(__VA_ARGS__)
   ^~
/root/firefox-gcc-last/js/src/jit/RegisterSets.h:930:9: note: in expansion of
macro 'MOZ_ASSERT'
 MOZ_ASSERT(!has(reg));
 ^~
Please submit a full bug report,
with preprocessed source if 

[Bug target/82498] Missed optimization for x86 rotate instruction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
With the recent changes on the trunk, I'm getting optimal generated code at
least on x86_64/i686 for all reasonable and less reasonable patterns I've
tried.  Of course, one can write arbitrarily weirdo patterns and not everything
will be recognized.

[Bug c++/53574] ICE with -fstack-usage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/67466] Project segfaulting, working with other compilers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Closing then.

[Bug c++/67100] ICE(in type_dependent_expression_p) on macro function + user defined literal

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Fixed in 5.1.0.

[Bug tree-optimization/82472] [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Arseny Solokha from comment #4)
> Can this PR be closed now?

Yes, I think it's fixed.  Thanks.

[Bug c++/61351] ICE on valid when deducing template arguments with nested expansions of the same pack

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Paolo Carlini  ---
Dup.

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

[Bug c++/61341] ICE for variadic templates: tsubst at cp/pt.c:11313, tree check: expected class ‘expression’, have ‘type’ (integer_type)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #6 from Paolo Carlini  ---
*** Bug 61351 has been marked as a duplicate of this bug. ***

[Bug c++/53574] ICE with -fstack-usage

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 16 08:36:06 2017
New Revision: 253778

URL: https://gcc.gnu.org/viewcvs?rev=253778=gcc=rev
Log:
PR c++/53574
* g++.dg/other/pr53574.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr53574.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/61323] 'static' and 'const' attributes cause non-type template argument matching failure

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed for 7.2.0.

[Bug middle-end/82556] [8 Regression] internal compiler error in curr_insn_transform, at lra-constraints.c:4307

[myon at debian dot org]

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

Christoph Berg  changed:

   What|Removed |Added

 CC||myon at debian dot org

--- Comment #2 from Christoph Berg  ---
gcc-7 in Debian unstable is also affected:

16923: // gcc version 7.2.1 20171014 (Debian 7.2.0-10) 
16923: // 
16923: // /<>/build/../src/backend/access/transam/xloginsert.c: In
function 'XLogInsert':
16923: //
/<>/build/../src/backend/access/transam/xloginsert.c:468:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:4320

[Bug c++/61323] 'static' and 'const' attributes cause non-type template argument matching failure

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct 16 08:25:31 2017
New Revision: 253777

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

PR c++/61323
* g++.dg/cpp0x/constexpr-61323.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-61323.C
Modified:
trunk/gcc/testsuite/ChangeLog