[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)

[jbassett271 at gmail dot com]

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

Justin Bassett  changed:

   What|Removed |Added

 CC||jbassett271 at gmail dot com

--- Comment #1 from Justin Bassett  ---
I believe the following is another case of this bug:
https://godbolt.org/z/9r9QdS . MSVC and Clang compile this fine; GCC only
compiles it fine if the `= delete` is not present. It's really weird that GCC
selects the deleted `begin()` even though it does not take an argument.

namespace foo {
namespace detail {
void begin() = delete;
}

inline auto begin = [](auto&& a) {
using detail::begin;
return begin(a);
};
}

#include 

int main() {
return *foo::begin(std::array{1, 2});
}


Error message:

: In instantiation of 'foo:: [with auto:1 =
std::array]':

:15:48:   required from here

:8:21: error: use of deleted function 'void foo::detail::begin()'

 return begin(a);

~^~~

:3:14: note: declared here

 void begin() = delete;

  ^

: In function 'int main()':

:15:23: error: void value not ignored as it ought to be

 return *foo::begin(std::array{1, 2});

 ~~^~

[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)

[jamespharvey20 at gmail dot com]

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

--- Comment #5 from jamespharvey20 at gmail dot com ---
Created attachment 44872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44872=edit
[Part 5] i386.ii

[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)

[jamespharvey20 at gmail dot com]

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

--- Comment #4 from jamespharvey20 at gmail dot com ---
Created attachment 44871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44871=edit
[Part 4] i386.ii

[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)

[jamespharvey20 at gmail dot com]

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

--- Comment #3 from jamespharvey20 at gmail dot com ---
Created attachment 44870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44870=edit
[Part 3] i386.ii

[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)

[jamespharvey20 at gmail dot com]

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

--- Comment #2 from jamespharvey20 at gmail dot com ---
Created attachment 44869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44869=edit
[Part 2] i386.ii

[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)

[jamespharvey20 at gmail dot com]

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

--- Comment #1 from jamespharvey20 at gmail dot com ---
Created attachment 44868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44868=edit
[Part 1] i386.ii

[Bug bootstrap/87672] New: [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple fai

[jamespharvey20 at gmail dot com]

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

Bug ID: 87672
   Summary: [9 regression] 81512c36 causes ICE in bootstrap stage
3 using "-D_FORTIFY_SOURCE=2"   (invalid operand in
unary operation, incorrect sharing of tree nodes,
verify_gimple failed)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamespharvey20 at gmail dot com
  Target Milestone: ---

Created attachment 44867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44867=edit
[Part 0] i386.ii

On trunk commit 7961f40be4b4a5d9c8531e6f78ecf330411d5d9f (2018-09-25) this
succeeds:

(in gcc git dir)
$ sed -i "/ac_cpp=/s/\$CPPFLAGS/\$CPPFLAGS -O2/" {libiberty,gcc}/configure
(in gcc build dir)
$ export CPPFLAGS="-D_FORTIFY_SOURCE=2"
$ /configure --disable-werror
{ [make] || [make -j] }

Trunk commit 81512c36496bd5c3bc35746603dc988f0bc85f57 or anything newer,
including current trunk/master, causes the following build failure.  With my
basic knowledge of the bootstrap process, I'm very surprised it compiles in
stage 2 but then fails in stage 3, but that's what happens.  I lost track of
how many times I've confirmed this, performing a bisect, at first going down a
wrong path of what I thought was causing this, then creating reduced steps. 
It's 100% reproduceable, where before commit 81512c compiles, and at or after
it fails with this error message.  (With all of Arch's normal build flags the
first two errors are given but the internal compiler error isn't, until it's
pruned down.)

It's not a hardware issue.  Kernel compiles fine.  System is rock solid. 
Memtest passes 16+ hours.

In case someone a response is going to be given that I shouldn't be modifying
these configure files this way, or using D_FORTIFY_SOURCE, I'll respond to
that.  Arch Linux has been compiling gcc this exact way since 4.8.0-2
(2013-04-12) without problems.  (Arch of course customizes more than this, but
I've reduced it down to the combination of the sed and CPPFLAGS.)  I understand
that upstream changes can and should require distributions to modify their
build process, especially distribution-specific ones, but:

(1) Even if true, this commit is causing an internal compiler error which
should not happen.

(2) Even if true, it's worrisome (at least to me, given my limited boostrap
process knowledge) that stage 2 can complete, but stage 3 can fail.

(3) I just view this as if Arch's normal gcc build process tests/stresses gcc's
code a bit more than others might.  (No idea if other distributions perform
these steps or not.)

After make failed, I re-ran the failing command with the "-save-temps" option
to get the preprocess file.  The max attachment here is 1000 KB, and it's 5M,
so I'm attaching 6 separate files from split.  I've also verified combining
them in order is identical to my original i386.ii.

System is up-to-date Arch.  gcc 8.2.1, binutils 2.31.1, linux 4.18.14.  You can
pull up the version of any other package at archlinux.org/packages by typing
the package name into Keywords.



...
Configuring stage 3 in ./gcc
...
/home/jamespharvey20/gcc.mirror.git.build.git/build/./prev-gcc/xg++
-B/home/jamespharvey20/gcc.mirror.git.build.git/build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/jamespharvey20/gcc.mirror.git.build.git/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/jamespharvey20/gcc.mirror.git.build.git/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/jamespharvey20/gcc.mirror.git.build.git/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/jamespharvey20/gcc.mirror.git.build.git/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include

-I/home/jamespharvey20/gcc.mirror.git.build.git/gcc.mirror.git.local/libstdc++-v3/libsupc++
-L/home/jamespharvey20/gcc.mirror.git.build.git/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/jamespharvey20/gcc.mirror.git.build.git/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc.mirror.git.local/gcc
-I../../gcc.mirror.git.local/gcc/. -I../../gcc.mirror.git.local/gcc/../include
-I../../gcc.mirror.git.local/gcc/../libcpp/include 
-I../../gcc.mirror.git.local/gcc/../libdecnumber
-I../../gcc.mirror.git.local/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc.mirror.git.local/gcc/../libbacktrace  -D_FORTIFY_SOURCE=2 -o i386.o
-MT i386.o -MMD -MP -MF ./.deps/i386.TPo
../../gcc.mirror.git.local/gcc/config/i386/i386.c

[Bug c++/87671] New: Incorrect debugging information for unique_ptr passed to a constructor

[anton at swarmer dot me]

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

Bug ID: 87671
   Summary: Incorrect debugging information for unique_ptr passed
to a constructor
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at swarmer dot me
  Target Milestone: ---

Created attachment 44866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44866=edit
Source code to reproduce

How to reproduce: compile the attached example with g++. I used:
  g++-8 -Wall -Wextra -save-temps bug.cpp -O0 -g -fsanitize=address,undefined
-o ./bug
Run with either gdb or lldb and set a breakpoint on line 7 (std::cout << *ptr).
Print *ptr in the debugger. For me 16 is printed, even though it should be 42.
Continue in debugger, observe that 42 is indeed printed to console.

The issue disappears if instead of a class constructor, I pass unique_ptr to a
normal function.

When compiling with clang++, both gdb and lldb show correct output. When
compiling with g++, both of them show incorrect output - which is why I suspect
that g++ is at fault here.

The system is Linux x86-64.

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

[Bug middle-end/87670] New: [9 Regression] CPU2006 401.bzip2 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 87670
   Summary: [9 Regression] CPU2006 401.bzip2 failed to build
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: aldyh at redhat dot com
  Target Milestone: ---

On x86-64, r265241 caused:

[hjl@gnu-4 build_base_lnx32e-gcc.]$
/export/project/git/gcc-bisect/master/265241/usr/bin/gcc -S -DSPEC_CPU -DNDEBUG
  -O2 -ffast-math-DSPEC_CPU_LP64 decompress.c
during GIMPLE pass: evrp
decompress.c: In function \u2018BZ2_decompress\u2019:
decompress.c:661:1: internal compiler error: in check, at tree-vrp.c:155
  661 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-4 build_base_lnx32e-gcc.]$

[Bug rtl-optimization/87664] invariant in loop after optimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Yea, we've got a long standing regression bug for issues related to frame
pointer based invariants.  I'm sure we'll find it again when we start stage4
bugfixing again as we look at it every cycle and say "ewww, that's amazingly
painful to fix".

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
At -O1, GCC 8 as well as trunk print:

pr71157.i: In function ‘TeX_commands’:
pr71157.i:8469:44: warning: ‘TEX_clgrp’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
8469 |   while (*p != '\0' && *p != TEX_opgrp && *p != TEX_clgrp)
 |  ~~^~
pr71157.i:8469:25: warning: ‘TEX_opgrp’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
8469 |   while (*p != '\0' && *p != TEX_opgrp && *p != TEX_clgrp)
 |  ~~~^~


At -O3, they issue:

In function ‘xrealloc’,
inlined from ‘linebuffer_setlen’ at pr71157.i:1:33,
inlined from ‘find_entries’ at pr71157.i:4822:3:
pr71157.i:10017:18: warning: argument 2 range [9223372036854775808,
18446744073709551615] exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
10017 |   void *result = realloc (ptr, size);
  |  ^~~
pr71157.i: In function ‘find_entries’:
pr71157.i:853:14: note: in a call to allocation function ‘realloc’ declared
here
853 | extern void *realloc (void *__ptr, size_t __size)
|  ^~~
In function ‘xrealloc’,
inlined from ‘linebuffer_setlen’ at pr71157.i:1:33,
inlined from ‘HTML_labels’ at pr71157.i:8593:3:
pr71157.i:10017:18: warning: argument 2 range [9223372036854775808,
18446744073709551615] exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
10017 |   void *result = realloc (ptr, size);
  |  ^~~
pr71157.i: In function ‘HTML_labels’:
pr71157.i:853:14: note: in a call to allocation function ‘realloc’ declared
here
853 | extern void *realloc (void *__ptr, size_t __size)
|  ^~~
In function ‘xrealloc’,
inlined from ‘linebuffer_setlen’ at pr71157.i:1:33,
inlined from ‘HTML_labels’ at pr71157.i:8679:6:
pr71157.i:10017:18: warning: argument 2 range [9223372036854775808,
18446744073709551615] exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
10017 |   void *result = realloc (ptr, size);
  |  ^~~
pr71157.i: In function ‘HTML_labels’:
pr71157.i:853:14: note: in a call to allocation function ‘realloc’ declared
here
853 | extern void *realloc (void *__ptr, size_t __size)
|  ^~~

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
In GCC 9 the warning has disappeared with r263981.

At -O1, GCC 8

[Bug fortran/87669] New: Select type, incorrect handling of parameterized derived type

[etdescdev at gmail dot com]

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

Bug ID: 87669
   Summary: Select type, incorrect handling of parameterized
derived type
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etdescdev at gmail dot com
  Target Milestone: ---

The SELECT TYPE statement matches the class of a parameterized derived type
without checking the kind parameter of the object.
Tested on Ubuntu 18.10 (with gfortran 8.2.0-7ubuntu1 and 9.0.0 20181020
(r265341)) and macOS Mojave (with Homebrew GCC 8.2.0):

Program Devtest
  Type dvtype(k)
Integer, Kind :: k
Real(k) :: a, b, c
  End Type dvtype
  type(dvtype(8)) :: dv
  dv%a = 1; dv%b = 2; dv%c = 3
  call dvtype_print(dv)
Contains
  Subroutine dvtype_print(p)
class(*), intent(in) :: p
Select Type(p)
class is (dvtype(4))
  print *, "dvtype4", p%k, p%a, p%b, p%c
End Select
Select Type(p)
class is (dvtype(8))
  print *, "dvtype8", p%k, p%a, p%b, p%c
End Select
  End Subroutine dvtype_print
End


Output:
 dvtype4   8   0.   0.   1.8750
 dvtype8   8   1.2.   
3.

In this case, the compiler does not display any warning message with -Wall and
-Wextra.
This program compiles and runs without generating any error, yet it prints the
line dvtype4 that does not correspond to the datatype of the object.
In this statement, the kind parameter k is correctly evaluated, but the values
a, b and c are displayed as if k were equal to 4.

[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
GCC 7 fails for me like the rest, and according to history it should have
failed since day 1, over 28 years ago.  Is that "works with 7.3.1" for
aarch64 only?

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-20
 Ever confirmed|0   |1

--- Comment #6 from Segher Boessenkool  ---
Thanks for the information Eric.

Will it help if the option is split into -Wnull-dereference and
-Wmaybe-null-dereference (as suggested before)?

[Bug c++/87668] New: [OpenMP] Complains about loop bound variable not being shared, even though unused in the loop

[lebedev.ri at gmail dot com]

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

Bug ID: 87668
   Summary: [OpenMP] Complains about loop bound variable not being
shared, even though unused in the loop
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lebedev.ri at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/05Zgdd

#include 
struct b {};
void c() {
  std::vector d;
#ifdef _OPENMP
#pragma omp parallel default(none)
#pragma omp for
#endif
  for (auto f = d.begin(); f < d.end(); ++f)
;
}

#ifndef _OPENMP
Yes, there is OMP.
#endif


GCC output:

: In function 'void c()':
:9:25: error: 'd' not specified in enclosing 'parallel'
   for (auto f = d.begin(); f < d.end(); ++f)
 ^
:6:9: error: enclosing 'parallel'
 #pragma omp parallel default(none)
 ^~~
Compiler returned: 1

Clang is perfectly happy with that code.
Since the 'd' isn't actually used in the parallel loop body,
but only in the loop bound checking, shouldn't gcc not complain about this,
too?

[Bug rtl-optimization/87664] invariant in loop after optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is because the last invariant motion pass happens before register
allocation, and at that point this single expression is represented by a pseudo
register (reg/f: DI 19 frame), and that isn't considered to be something that
should be hoisted before the loop.  During register allocation the frame pseudo
gets replaced by something different, like %rsp + constant or %rbp + constant,
and at that point we might need to reconsider that.  On the other side, we
might hoist frame + constant even if in the and that ends up being say %rbp
itself or %rsp.  I think we have a dup for this somewhere.

[Bug target/72782] AVX512: No support for scalar broadcasts

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sat Oct 20 20:41:10 2018
New Revision: 265345

URL: https://gcc.gnu.org/viewcvs?rev=265345=gcc=rev
Log:
i386: Enable AVX512 memory broadcast for FP div

Many AVX512 vector operations can broadcast from a scalar memory source.
This patch enables memory broadcast for FP div operations.

gcc/

PR target/72782
* config/i386/sse.md (*_div3_bcst): New.

gcc/testsuite/

PR target/72782
* gcc.target/i386/avx512f-div-df-zmm-1.c: New test.
* gcc.target/i386/avx512f-div-sf-zmm-1.c: Likewise.
* gcc.target/i386/avx512f-div-sf-zmm-2.c: Likewise.
* gcc.target/i386/avx512f-div-sf-zmm-3.c: Likewise.
* gcc.target/i386/avx512f-div-sf-zmm-4.c: Likewise.
* gcc.target/i386/avx512f-div-sf-zmm-5.c: Likewise.
* gcc.target/i386/avx512vl-div-sf-xmm-1.c: Likewise.
* gcc.target/i386/avx512vl-div-sf-ymm-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-div-df-zmm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-div-sf-zmm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-div-sf-zmm-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-div-sf-zmm-3.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-div-sf-zmm-4.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-div-sf-zmm-5.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-div-sf-xmm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-div-sf-ymm-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Segher Boessenkool from comment #4)
> At least some of what?  I don't follow.

The bugs that this one depends upon.

> _Is_ there anything that prevents us from enabling -Wnull-dereference at
> -Wextra or -Wall or even by default?

It was previously in -Wall, but it was removed from it in r226751 because it
broke bootstrap, see bug 16351 comment 35. 

> Does it have false positives?

Bug 71157 is a false positive.

[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
rs6000.c print_operand_address does not like (const_int 0) or any other
const_int.  Power *can* actually have constant numbers as data addresses,
but only for instructions that have some D form; and GCC does not support
such constant addresses currently.

We could do output_operand_lossage, or we could do as most targets do here:
call output_addr_const and hope for the best (it will output just "0" with
this testcase).  Is that preferred?

[Bug c++/87667] New: -Wformat + typed enum class - difference with clang

[lebedev.ri at gmail dot com]

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

Bug ID: 87667
   Summary: -Wformat + typed enum class - difference with clang
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lebedev.ri at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/GX-Fqv

#include 

enum class Enum : unsigned short {
One,
};

void test(Enum e) {
printf("0x%04hx", e);
}

gcc:

: In function 'void test(Enum)':
:8:12: warning: format '%hx' expects argument of type 'int', but
argument 2 has type 'Enum' [-Wformat=]
 printf("0x%04hx", e);
^  ~
Compiler returned: 0

Clang is fine with that.

Who is wrong?

[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
-Wall please, unless there are frequent false positives.  Things shouldn't
move between warning levels unless there is a good reason for it (like, the
accuracy of the warning was improved, or it was put in the wrong level in the
first place).  We shouldn't put warnings under less used levels first; this
is not a popularity contest.

[Bug other/87666] Memory access errors when using c++ 17 filesystem library and "-mcpu=cortex-a53"

[christian_hoff at gmx dot net]

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

--- Comment #1 from Christian Hoff  ---
Output from "gcc -v":
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.2.0-4+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=arm-linux-gnueabihf- --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-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp
--with-float=hard --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.2.0 (Raspbian 8.2.0-4+rpi1)

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
At least some of what?  I don't follow.  _Is_ there anything that prevents
us from enabling -Wnull-dereference at -Wextra or -Wall or even by default?
Does it have false positives?

[Bug other/87666] New: Memory access errors when using c++ 17 filesystem library and "-mcpu=cortex-a53"

[christian_hoff at gmx dot net]

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

Bug ID: 87666
   Summary: Memory access errors when using c++ 17 filesystem
library and "-mcpu=cortex-a53"
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian_hoff at gmx dot net
  Target Milestone: ---

Created attachment 44865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44865=edit
sample code and Makefile to reproduce the issue

I have the following simple test code that uses the C++ 17 filesystem library:

#include 
#include 

namespace fs = std::filesystem;
using namespace std;

int main(int argc, char *argv[])
{
fs::path dir = "/tmp";
fs::directory_iterator dirIter(dir);
for (const fs::directory_entry  : dirIter) {
cout << "Found entry " << entry.path().filename() << endl;
}
}

When compiling this code with GCC 8.2.0 on ARM platform with "-mcpu=cortex-a53"
and Address Sanitizer instrumentation Address Sanitizer reports a memory access
error (see below) when running the compiled executable. But if I omit the
"-mcpu=cortex-a53" and compile the code also with Address Sanitizer, I do not
get this memory access error. So whether I get the memory access error or not
depends on whether "-mcpu=cortex-a53" was specified on the command line or not.

I have attached a tar archive with the example code and a Makefile to build it.

The memory access error reported by Address Sanitizer looks as follows:

=
==2625==ERROR: AddressSanitizer: heap-use-after-free on address 0x74402e04 at
pc 0x001222f8 bp 0x7ebb0b74 sp 0x7ebb0b6c
WRITE of size 4 at 0x74402e04 thread T0
#0 0x1222f7 in __exchange_and_add /usr/include/c++/8/ext/atomicity.h:49
#1 0x122523 in __exchange_and_add_dispatch
/usr/include/c++/8/ext/atomicity.h:82
#2 0x1261cf in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
/usr/include/c++/8/bits/shared_ptr_base.h:152
#3 0x124b9b in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()
/usr/include/c++/8/bits/shared_ptr_base.h:706
#4 0x1233d3 in std::__shared_ptr::~__shared_ptr()
/usr/include/c++/8/bits/shared_ptr_base.h:1145
#5 0x1233ff in
std::shared_ptr::~shared_ptr()
/usr/include/c++/8/bits/shared_ptr.h:103
#6 0x12342b in
std::filesystem::__cxx11::directory_iterator::~directory_iterator()
/usr/include/c++/8/bits/fs_dir.h:372
#7 0x121edb in main
/home/pi/projects/sip/pjsip/directory-iterator-bug/Main.cpp:10
#8 0x76b1d143 in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x17143)

0x74402e04 is located 4 bytes inside of 124-byte region [0x74402e00,0x74402e7c)
freed by thread T0 here:
#0 0xe19af in operator delete(void*)
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0xe19af)
#1 0x12ead3 in std::filesystem::__cxx11::directory_iterator::operator++()
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0x12ead3)
#2 0x76b1d143 in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x17143)

previously allocated by thread T0 here:
#0 0xe0ddb in operator new(unsigned int)
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0xe0ddb)
#1 0x12d7ff in
std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&, std::filesystem::directory_options, std::error_code*)
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0x12d7ff)
#2 0x121c0b in main
/home/pi/projects/sip/pjsip/directory-iterator-bug/Main.cpp:10
#3 0x76b1d143 in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x17143)

SUMMARY: AddressSanitizer: heap-use-after-free
/usr/include/c++/8/ext/atomicity.h:49 in __exchange_and_add
Shadow bytes around the buggy address:
  0x2e880570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x2e8805c0:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x2e8805d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init 

[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 84539 has been marked as a duplicate of this bug. ***

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
This seems fixed after revision r265283. Likely a duplicate of pr87625.

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

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egallager at gcc dot gnu.org]

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

--- Comment #13 from Eric Gallager  ---
(In reply to Ryan Schmidt from comment #12)
> How would I do that?

Add -save-temps to the compile command and then attach the lj_cconv.i file that
is produced

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[linux at obiwahn dot org]

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

--- Comment #3 from Jan Christoph Uhde  ---
» g++-head -v
Using built-in specs.
COLLECT_GCC=g++-head
COLLECT_LTO_WRAPPER=/bal/gcc_trunk_install/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_trunk/configure --prefix=/bla/gcc_trunk_install
--program-suffix=-head --disable-multilib
Thread model: posix
gcc version 9.0.0 20181020 (experimental) (GCC)

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> The behaviour changed with r255268

Which doesn't make sense as the bug seems to be target-independent.

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||wrong-code
   Last reconfirmed||2018-10-20
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|gcc HEAD (svn: 265340)  |[8/9 Regression] gcc HEAD
   |breaks elements on resize   |(svn: 265340) breaks
   ||elements on resize
  Known to fail||8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jan Christoph Uhde from comment #0)
> gcc was build with `--disable-multilib` and custom suffix and prefix on
> Debian stable and sid.

The output of 'gcc -v' includes all that and more, which is why we ask for it.

The behaviour changed with r255268

PR target/81616
* x86-tnue-costs.h (generic_cost): Revise for modern CPUs
* gcc.target/i386/l_fma_double_1.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_double_2.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_double_3.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_double_4.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_double_5.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_double_6.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_float_1.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_float_2.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_float_3.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_float_4.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_float_5.c: Update count of fma
instructions.
* gcc.target/i386/l_fma_float_6.c: Update count of fma
instructions.

[Bug c++/87665] New: gcc HEAD (svn: 265340) breaks elements on resize

[linux at obiwahn dot org]

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

Bug ID: 87665
   Summary: gcc HEAD (svn: 265340) breaks elements on resize
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at obiwahn dot org
  Target Milestone: ---

» cat test.cpp 
#include 
#include 
#include 
#include 
#include 

int main()
{
  using my_pair = std::pair, double*>;
  std::vector vec;

  for (int i = 0; i < 17; ++i) {
std::unique_ptr p(new int(i));
vec.emplace_back(std::move(p), nullptr);
std::cerr << "capacity: " << vec.capacity() << " size: " << vec.size() <<
std::endl;
for (size_t i = 0, count = vec.size(); i < count; ++i) {
  std::cerr << " " << i << "-" << (vec[i].first == nullptr ? "fail" :
"ok");
}
std::cerr << std::endl;
  }
}

» g++-head test.cpp -O3 -Wall -Wshadow -std=c++14 && ./a.out 
test.cpp: In function ‘int main()’:
test.cpp:16:17: warning: declaration of ‘i’ shadows a previous local [-Wshadow]
   16 | for (size_t i = 0, count = vec.size(); i < count; ++i) {
  | ^
test.cpp:12:12: note: shadowed declaration is here
   12 |   for (int i = 0; i < 17; ++i) {
  |^
capacity: 1 size: 1
 0-ok
capacity: 2 size: 2
 0-ok 1-ok
capacity: 4 size: 3
 0-ok 1-ok 2-ok
capacity: 4 size: 4
 0-ok 1-ok 2-ok 3-ok
capacity: 8 size: 5
 0-fail 1-fail 2-fail 3-fail 4-ok
capacity: 8 size: 6
 0-fail 1-fail 2-fail 3-fail 4-ok 5-ok
capacity: 8 size: 7
 0-fail 1-fail 2-fail 3-fail 4-ok 5-ok 6-ok
capacity: 8 size: 8
 0-fail 1-fail 2-fail 3-fail 4-ok 5-ok 6-ok 7-ok
capacity: 16 size: 9
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok
capacity: 16 size: 10
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok
capacity: 16 size: 11
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok 10-ok
capacity: 16 size: 12
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok 10-ok 11-ok
capacity: 16 size: 13
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok 10-ok 11-ok
12-ok
capacity: 16 size: 14
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok 10-ok 11-ok
12-ok 13-ok
capacity: 16 size: 15
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok 10-ok 11-ok
12-ok 13-ok 14-ok
capacity: 16 size: 16
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-ok 9-ok 10-ok 11-ok
12-ok 13-ok 14-ok 15-ok
capacity: 32 size: 17
 0-fail 1-fail 2-fail 3-fail 4-fail 5-fail 6-fail 7-fail 8-fail 9-fail 10-fail
11-fail 12-fail 13-fail 14-fail 15-fail 16-ok

The code compiles and works fine with recent clang. If the shadowed variable is
changed to something else or the double* member is replaced by something else
the code works as expected.

The behavior was originally found by Vasiliy Nabatchikov on gcc 8.2 using
`typedef std::function f_t; typedef
std::pair, f_t*> term_iterator_t1` as pair type.

gcc was build with `--disable-multilib` and custom suffix and prefix on Debian
stable and sid.

[Bug rtl-optimization/87664] New: invariant in loop after optimization

[drepper.fsp+rhbz at gmail dot com]

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

Bug ID: 87664
   Summary: invariant in loop after optimization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

Compile the following code with the current trunk or gcc 8.2.1:

#include 
#include 

int rs(int s) {
  std::array ar;
  std::iota(ar.begin(), ar.end(), s);
  return std::accumulate(ar.begin(), ar.end(), 0);
}


With -O2 this leads on x86-64 to the following code:


 :
   0:   48 81 ec 20 01 00 00sub$0x120,%rsp
   7:   48 8d 44 24 88  lea-0x78(%rsp),%rax
   c:   0f 1f 40 00 nopl   0x0(%rax)
  10:   89 38   mov%edi,(%rax)
  12:   48 8d 8c 24 18 01 00lea0x118(%rsp),%rcx
  19:   00 
  1a:   48 83 c0 04 add$0x4,%rax
  1e:   ff c7   inc%edi
  20:   48 39 c8cmp%rcx,%rax
  23:   75 eb   jne10 
  25:   48 8d 54 24 88  lea-0x78(%rsp),%rdx
  2a:   31 c0   xor%eax,%eax
  2c:   0f 1f 40 00 nopl   0x0(%rax)
  30:   03 02   add(%rdx),%eax
  32:   48 8d b4 24 18 01 00lea0x118(%rsp),%rsi
  39:   00 
  3a:   48 83 c2 04 add$0x4,%rdx
  3e:   48 39 f2cmp%rsi,%rdx
  41:   75 ed   jne30 
  43:   48 81 c4 20 01 00 00add$0x120,%rsp
  4a:   c3  retq   


The relevant parts are the loop starting at offsets 10 and 30.  The respective
lea instructions to compute the end address of the loop at offset 12 and 32 are
invariant and should be hoisted out of the loops.

[Bug c++/87663] Exorbitant compile times

[lumosimann at gmail dot com]

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

--- Comment #1 from Lukas Mosimann  ---
By the way: I could drop parameter `Z` from `C` and `D`. I forgot to remove
that when I was experimenting with extensions like `f_n = f_{n-1} + f_{n-2} +
f_{n-3}`.

[Bug c++/87663] New: Exorbitant compile times

[lumosimann at gmail dot com]

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

Bug ID: 87663
   Summary: Exorbitant compile times
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lumosimann at gmail dot com
  Target Milestone: ---

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

Let's try to calculate fiboncacchi numbers at compile time in exponential time.
This is a bad implementation of course, but I use that as a placeholder for any
other algorithm with much recursion.

Consider this code:

```
#include 
#include 

template 
struct C : std::integral_constant::value -
  C::value> {};
template 
struct D : std::integral_constant::value -
  D::value> {};

template 
struct C : std::integral_constant {};
template 
struct C : std::integral_constant {};

template 
struct D : std::integral_constant {};
template 
struct D : std::integral_constant {};

int main() {
std::cout << C_OR_D<0, N, 0>::value << std::endl;
return 0;
}
```

Let's think about compile time complexity with respect to `N` when compiling
this code (`C_OR_D` stands for either `C` or `D`).

`C`  calculates kind of a fibonacchi number with some non-important
modification to avoid overflows (`f_n = f_{n-1} - f_{n-2}`). I would expect
compile times to behave like `t_n = t_{n-1} + t_{n-2} = O(1.6^n)`.

`D` is a slightly modified version and we calculate `f_n = f_{n-1} - f_{n-1}`,
which is much more expensive of course. I would expect compile times to behave
like `t_n = t_{n-1} + t_{n-1} = O(2^n)`.


Let's first look at `D`, where I expect compile times of O(2^n):
* Compile times with Clang 7.0.0 for `D`:
> 495 ms ± 5.17 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 679 ms ± 4.92 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 1.07 s ± 10.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 1.85 s ± 39.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 3.4 s ± 20 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 6.48 s ± 79 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 12.9 s ± 227 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Note that I dropped compile times for low `n`, as long as the constant
dominates, and my stop condition is that compile-time is larger than 10 s. For
comparison, I refer to the attachment.
We see that after a while, compile times double when incrementing `n`, which is
prefect.

* Compile times with GCC 8.2.1 for `D`:
> ...
> 620 ms ± 26.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 973 ms ± 21.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 1.69 s ± 15.9 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 3.38 s ± 39.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 6.6 s ± 102 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 13.5 s ± 446 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Also here, we observe that compile times double when incrementing `n`.

In absolute numbers, gcc is slightly faster for low numbers, and worse for
large `n`. See attachment (left, "Power of Two").

Let's now look at `C` (Fibonacchi):

* Compile times with Clang 7.0.0 for `C`:
> ...
> 1.41 s ± 13.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 2.06 s ± 17.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 3.18 s ± 51.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 5.16 s ± 273 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 8.01 s ± 219 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 13.1 s ± 385 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Isn't this nice? This is a fibonacchi sequence! Let's continue with GCC.

* Compile times with GCC 8.2.1 for `C`:
> ...
> 964 ms ± 14.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 1.8 s ± 38 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 4.95 s ± 252 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
> 17.8 s ± 822 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

What is that? Compile times explode! It turns out that compile times for this
example are around O(3^n), much worse than `D` for almost any `n`.

In absolute numbers, gcc becomes soon terribly slow. See attachment (right,
"Fibonacchi").

Questions:

* Why does this behavior occur?
* Could this behavior have any impact on real-life code? I would assume yes.

[Bug middle-end/87647] [6/7/8/9 Regression] ICE on valid code in decode_addr_const, at varasm.c:2958

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 20 08:58:00 2018
New Revision: 265341

URL: https://gcc.gnu.org/viewcvs?rev=265341=gcc=rev
Log:
PR middle-end/87647
* varasm.c (decode_addr_const): Handle COMPOUND_LITERAL_EXPR.

* gcc.c-torture/compile/pr87647.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr87647.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug target/87662] New: Missing AVX512VL intrinsics

[hjl.tools at gmail dot com]

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

Bug ID: 87662
   Summary: Missing AVX512VL intrinsics
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

_mm256_or_epi32, _mm_or_epi32, _mm256_xor_epi32, _mm_xor_epi32,
_mm256_or_epi64, _mm_or_epi64, _mm256_xor_epi64 and _mm_xor_epi64
are missing.

[Bug go/87661] New: [9 Regression] libgo bootstrap failure on arm-linux-gnueabihf (redefinition of constants)

[doko at debian dot org]

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

Bug ID: 87661
   Summary: [9 Regression] libgo bootstrap failure on
arm-linux-gnueabihf (redefinition of constants)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

seen with trunk 20181019, configured with

 --with-arch=armv7-a
 --with-fpu=vfpv3-d16
 --with-float=hard
 --with-mode=thumb

runtime_sysinfo.go:1676:7: error: redefinition of '_HWCAP_IDIVA'
 1676 | const _HWCAP_IDIVA = (1 << 17)
  |   ^
../../../src/libgo/go/runtime/os_linux_arm.go:14:2: note: previous definition
of '_HWCAP_IDIVA' was her
e
   14 |  _HWCAP_IDIVA = 1 << 17
  |  ^
runtime_sysinfo.go:3157:7: error: redefinition of '_HWCAP_VFPv3'
 3157 | const _HWCAP_VFPv3 = (1 << 13)
  |   ^
../../../src/libgo/go/runtime/os_linux_arm.go:13:2: note: previous definition
of '_HWCAP_VFPv3' was her
e
   13 |  _HWCAP_VFPv3 = 1 << 13 // introduced in 2.6.30
  |  ^
runtime_sysinfo.go:5588:7: error: redefinition of '_HWCAP_VFP'
 5588 | const _HWCAP_VFP = (1 << 6)
  |   ^
../../../src/libgo/go/runtime/os_linux_arm.go:12:2: note: previous definition
of '_HWCAP_VFP' was here
   12 |  _HWCAP_VFP   = 1 << 6  // introduced in at least 2.6.11
  |  ^