[Bug c++/82304] New: GCC compiles constexpr function with double reinterpret_cast in a constant context

[vladimir.krivopalov at gmail dot com]

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

Bug ID: 82304
   Summary: GCC compiles constexpr function with double
reinterpret_cast in a constant context
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.krivopalov at gmail dot com
  Target Milestone: ---

The following code compiles fine with GCC (-std=c++14) although normally it
should be rejected:

#include 
inline constexpr const char* testfunc(const char* p)
{
return reinterpret_cast (
   reinterpret_cast(p));
}

int main(int argc, char** argv) {
static constexpr const char* second = testfunc("Hello");
}

The C+14 standard prohibits use of reinterpret_cast in constexpr functions:
[expr.const]/2.11 and [expr.const]/2.13

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
A static PIE option can be used for both kernel
as well as user space.

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

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
In the GCC build, if you want to disable libquadmath completely, you need to
use both --disable-libquadmath and --disable-libquadmath-support.  The
--disable-libquadmath option disables building the quadmath libraries, but it
doesn't disable the checks in libgfortran.

In GCC 7, __float128 was not the default.  You didn't need an explicit
--disable-libquad math, because the quadmath library would notice that the
compiler didn't support the __float128 keyword.

As of September 9th, the trunk compiler now enables __float128 by default, and
libquad math normally builds.  So, if you want to disable libquadmath and the
fortran support, you need both switches.

BTW, if you use --disable-libquamath without --disable-libquadmath-support on
the x86, it will not build the C++ libraries.  Using both switches, will
disable both the libstdc++ and libgfortran support.

I have some patches that allow using --disable-libquadmath to automaically set
--disable-libquadmath-support which will allow the PowerPC to build, but the
x86 will still die in libstdc++, so I'm not sure how useful these patches are.

I would recommend dropping the --disable-quadmath configure option, and build
the quadmath libraries now.

[Bug target/82303] New: Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[thgarnie at google dot com]

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

Bug ID: 82303
   Summary: Better PIE/PIC code generation for kernel code (x86_64
& arm64)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thgarnie at google dot com
  Target Milestone: ---

The current PIE/PIC code generation is not optimal for kernel code.

It makes inferences about the execution environment which do not hold for
freestanding executables such as the Linux kernel, regarding the need to avoid
text relocations, to minimize the footprint of CoWed pages, and to always refer
to exported symbols via the GOT so they can be preempted. None of these
concerns apply to freestanding binaries.

Having a separate flag (like mcmodel=kernel-pie or -fkernel-pie) would allow
better code optimization for PIE/PIC kernel code, notably:

- Select the right segment register for TLS on kernel code (For example x86_64
use gs instead of fs [1]).
- No need for GOT or PLT.
- Re-enable code optimizations disabled for COW pages support, trying to reduce
relocations to code sections. For example, switch are not folded for PIE/PIC
code to avoid relocations [2].

Note that arm64 PIE uses the small or tiny mcmodel based on UEFI so it should
be taken in considerations for this architecture.

For reference the discussion on Linux kernel x86_64 PIE RFC:
http://www.openwall.com/lists/kernel-hardening/2017/09/21/16

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
[2]
https://github.com/gcc-mirror/gcc/blob/7977b0509f07e42fbe0f06efcdead2b7e4a5135f/gcc/tree-switch-conversion.c#L828

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #2 from H.J. Lu  ---
(In reply to Peter Cordes from comment #0)
> x32 defaults to using 32-bit address-size everywhere, it seems.  (Apparently
> introduced by rev 185396 for bug 50797, which introduced
> -maddress-mode=short and made it the default.)
> 
> This takes an extra 1-byte prefix on every instruction with a memory
> operand.  It's not just code-size; this is potentially a big throughput
> problem on Intel Silvermont where more than 3 prefixes (including mandatory
> prefixes and 0F escape bytes for SSE and other instructions) cause a stall. 
> These are exactly the systems where a memory-saving ABI might be most
> useful.  (I'm not building one, I just think x32 is a good idea if
> implemented optimally.)
> 
> long long doublederef(long long **p){
> return **p;
> }
> //  https://godbolt.org/g/NHbURq
> gcc8 -mx32 -O3
> movl(%edi), %eax  # 0x67 prefix
> movq(%eax), %rax  # 0x67 prefix
> ret
> 
> The second instruction is 1 byte longer for no reason: it needs a 0x67
> address-size prefix to encode.
> But we know for certain that the address is already zero-extended into %rax,
> because we just put it there.  Also, the ABI requires p to be zero-extended
> to 64 bits, so it would be safe to use `movl (%rdi), %eax` as the first
> instruction.
> 
> Even (%rsp) is avoided for some reason, even though -mx32 still uses
> push/pop/call/ret which use the full %rsp, so it has to be valid.
> 
> int stackuse(void) {
> volatile int foo = 2;
> return foo * 3;
> }
> movl$2, -4(%esp)# 0x67 prefix
> movl-4(%esp), %eax  # 0x67 prefix

We can encode (%esp) as (%rsp) since the upper bits of RSP are zero.

> leal(%rax,%rax,2), %eax # no prefixes
> ret
> 
> 
> Compiling with -maddress-mode=long appears to generate optimal code for all
> the simple test cases I looked at, e.g.
> 
> movl$2, -4(%rsp)# no prefixes
> movl-4(%rsp), %eax  # no prefixes
> leal(%rax,%rax,2), %eax # no prefixes
> ret
> 
> -maddress-mode=long still uses an address-size prefix instead of an LEA to
> make sure addresses wrap at 4G, and to ignore high garbage in registers:
> 
> long long fooi(long long *arr, int offset){
> return arr[offset];
> }
> movq(%edi,%esi,8), %rax# same for mode=short or long.
> ret
> 
> Are there still cases where -maddress-mode=long makes worse code?


Yes, there are more places where -maddress-mode=long needs to zero-extend
address to 64 bits where 0x67 prefix does for you.

> 
> 
> Is it really necessary for an unsigned offset to be wrap at 4G?  Does ISO C
> or GNU C guarantee that large unsigned values work like negative signed
> integers when used for pointer arithmetic?
> 
> // 64-bit offset so it won't have high garbage
> long long fooull(long long *arr, unsigned long long offset){
> return arr[offset];
> }
> 
> movq(%edi,%esi,8), %rax# but couldn't this be (%rdi,%rsi,8)
> ret
> 
> Allowing 64-bit addressing modes with unsigned indexes could potentially
> save significant code-size, couldn't it?
> 
> address-mode=long already allows constant offsets to go outside 4G, for
> example:
> 
> foo_constant: #return arr[123456];
> movq987648(%rdi), %rax
> ret
> 
> But it does treat the offset as signed, so 0xULL will  movq
> -8(%rdi), %rax.
> 
> The ABI doc (https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI) doesn't
> specify anything about C pointer-wrapping semantics, and I don't know where
> else to look to find out what behaviour is required/guaranteed and what is
> just how the current implementation happens to work.
> 
> Anyway, this is a side-track from the issue of not using address-size
> prefixes in single-pointer cases where it's already zero extended.
> 
> -
> 
> SSSE3 and later instructions need 66 0F 3A/38 before the opcode, so an
> address-size or REX prefix will cause a decode stall on Silvermont.  With

That is true.

> the default x32 behaviour, even SSE2 instructions (66 0F opcode) will cause
> decode stalls with a REX and address-size prefix.  e.g. paddb (%r8d), %xmm8 
> or even movdqa (but not movaps or other SSE1 instructions).  Fortunately KNL
> isn't really affected: VEX/EVEX is fine unless there's a segment prefix
> before it, but Agner Fog seems to be saying that other prefixes are fine.
> 
> In integer code, REX + operand-size + address-size + a 0F escape byte would
> be a problem for Silvermont/KNL, e.g. imul (%edi), %r10w needs all 4.  
> movbe %ax, (%edi) has 4 prefixes, including 

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
No, the infrastructure is in tree-ssa-reassoc.c, and I plan to look at it next
week.

[Bug sanitizer/81929] [7/8 Regression] exponential slowdown in undefined behavior sanitizer for streaming

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #58 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #57 from Iain Sandoe  ---
[...]
>> Now running an i386-apple-darwin11.4.2 bootstrap, which will take
>> another day.

> Dominique reported OK on Darwin16 and Darwin10 on irc, so I think if the i386
> bootstrap is successful - this should be good to go (for now)

It just did complete successfully, so the patch is good to go, I believe.

Thanks.
Rainer

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

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to prathamesh3492 from comment #2)
> Fixed on targets when LOGICAL_OP_NON_SHORT_CIRCUIT is true.
> When LOGICAL_OP_NON_SHORT_CIRCUIT is false, the conversion of
> truth_andif_expr to bit_and_expr doesn't happen and the pattern added in
> r241915 doesn't get matched.

Hmm, I thought ifcombine should do the "right thing" here ...

[Bug lto/82302] New: LTO producing bad code

[krzysio.kurek at wp dot pl]

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

Bug ID: 82302
   Summary: LTO producing bad code
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysio.kurek at wp dot pl
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I've found a repository with code which upon compilation with -flto under GCC7
creates a softlock. Works fine on GCC6.
Here's a fork of the repo:
https://github.com/kiroma/MineCraft-One-Week-Challenge
It's made so that cmake defaults to a build configuration with -flto enabled.
On GCC6 the program will output to the console:

Attempting to load chunk
Finished loading chunk, all clear!
Spawn found! Attempts: x Time Taken: y seconds

On GCC7 it will print:

Attempting to load chunk

but will not proceed.

[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

--- Comment #35 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Sep 22 20:20:40 2017
New Revision: 253110

URL: https://gcc.gnu.org/viewcvs?rev=253110=gcc=rev
Log:
PR bootstrap/81926
* cp-objcp-common.c (cp_get_debug_type): Do only one lookup.

Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/cp-objcp-common.c

[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

--- Comment #34 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Sep 22 20:20:25 2017
New Revision: 253109

URL: https://gcc.gnu.org/viewcvs?rev=253109=gcc=rev
Log:
PR bootstrap/81926
* cp-objcp-common.c (cp_get_debug_type): Do only one lookup.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.c

[Bug bootstrap/82300] Bootstrapping gcc-8 does not work on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
If this PR appears at or before r 252896, The problem I see is different.

[Bug bootstrap/82300] Bootstrapping gcc-8 does not work on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
If we are talking of the same problem, it is due to r253089.

[Bug other/82301] [8 regression] Updated test case g++.dg/ext/attr-ifunc-1.C (and others) in r253041 segfault on powerpc64

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-22
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The changes in r253041 are incorrect and cause failures on some other targets
as well (e.g., i386).  I'm working on a fix.

[Bug other/82301] New: [8 regression] Updated test case g++.dg/ext/attr-ifunc-1.C (and others) in r253041 segfault on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 82301
   Summary: [8 regression] Updated test case
g++.dg/ext/attr-ifunc-1.C (and others) in r253041
segfault on powerpc64
   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: ---

A bunch of test cases were updated at or just before r253041 and they fail on
powerpc64.  Just BE, LE works fine.

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

They seem to be segfaulting:

(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test2/./attr-ifunc-1.exe 

Program received signal SIGSEGV, Segmentation fault.
0x1680 in Klass::resolver () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ext/attr-ifunc-1.C:26
26return ::implementation;
(gdb) where
#0  0x1680 in Klass::resolver () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ext/attr-ifunc-1.C:26
#1  0x3fffb7fc2fb0 in resolve_ifunc (sym_map=0x3fffb7ff1ed0,
map=0x3fffb7ff1ed0, value=) at
../sysdeps/powerpc/powerpc64/dl-machine.h:630
#2  elf_machine_rela (skip_ifunc=, reloc_addr_arg=0x10010e88,
version=, sym=, reloc=0x13c0,
map=0x3fffb7ff1ed0)
at ../sysdeps/powerpc/powerpc64/dl-machine.h:691
#3  elf_dynamic_do_Rela (skip_ifunc=, lazy=,
nrelative=, relsize=, reladdr=, 
map=0x3fffb7ff1ed0) at do-rel.h:137
#4  _dl_relocate_object (scope=0x3fffb7ff2248, reloc_mode=,
consider_profiling=) at dl-reloc.c:259
#5  0x3fffb7fb73b8 in dl_main (phdr=, phnum=,
user_entry=0x3fffea70, auxv=) at rtld.c:2313
#6  0x3fffb7fd2634 in _dl_sysdep_start (start_argptr=,
dl_main=@0x3fffb7ff0140: 0x3fffb7fb5400 ) at ../elf/dl-sysdep.c:244
#7  0x3fffb7fb3f48 in _dl_start_final (arg=arg@entry=0x3150,
info=info@entry=0x3fffebd0) at rtld.c:412
#8  0x3fffb7fb4c28 in _dl_start (arg=0x3150) at rtld.c:640
#9  0x3fffb7fb3c10 in ._start () from /lib64/ld64.so.1


Some of these at least used to be marked as unsupported.

[Bug c/82272] RFE: request a warning for ( == ) etc.

[hpa at zytor dot com]

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

--- Comment #2 from H. Peter Anvin  ---
Since it doesn't seem to be clear from the text, perhaps an interpretation
request to the committee is in order.  If this indeed is the requirement, I
would suggest implementing it as a gnu99/gnu11 extension and push for a
relaxation of the requirement in future versions of the C standard.

Either that or push for actual _True and _False in a future version of the C
standard, equivalent to ((_Bool)1) and ((_Bool)0) except usable in the C
preprocessor.  That would also let people rely on, for example, sizeof(true) ==
sizeof(bool).

[Bug sanitizer/81929] [7/8 Regression] exponential slowdown in undefined behavior sanitizer for streaming

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 22 19:00:03 2017
New Revision: 253108

URL: https://gcc.gnu.org/viewcvs?rev=253108=gcc=rev
Log:
PR sanitizer/81929
* tree.c (struct replace_placeholders_t): Add pset field.
(replace_placeholders_r): Call cp_walk_tree with d->pset as
last argument instead of NULL.  Formatting fix.
(replace_placeholders): Add pset variable, add its address
into data.  Pass  instead of NULL to cp_walk_tree.

* g++.dg/ubsan/pr81929.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ubsan/pr81929.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/tree.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 22 18:56:23 2017
New Revision: 253107

URL: https://gcc.gnu.org/viewcvs?rev=253107=gcc=rev
Log:
PR middle-end/35691
* match.pd: Simplify x == -1 & y == -1 into (x & y) == -1
and x != -1 | y != -1 into (x & y) != -1.

* gcc.dg/pr35691-1.c: Use -fdump-tree-forwprop1-details
instead of -fdump-tree-forwprop-details in dg-options.
* gcc.dg/pr35691-2.c: Likewise.
* gcc.dg/pr35691-3.c: New test.
* gcc.dg/pr35691-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr35691-3.c
trunk/gcc/testsuite/gcc.dg/pr35691-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr35691-1.c
trunk/gcc/testsuite/gcc.dg/pr35691-2.c

[Bug sanitizer/81929] [7/8 Regression] exponential slowdown in undefined behavior sanitizer for streaming

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 22 18:55:21 2017
New Revision: 253106

URL: https://gcc.gnu.org/viewcvs?rev=253106=gcc=rev
Log:
PR sanitizer/81929
* tree.c (struct replace_placeholders_t): Add pset field.
(replace_placeholders_r): Call cp_walk_tree with d->pset as
last argument instead of NULL.  Formatting fix.
(replace_placeholders): Add pset variable, add its address
into data.  Pass  instead of NULL to cp_walk_tree.

* g++.dg/ubsan/pr81929.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr81929.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/82300] Bootstrapping gcc-8 does not work on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
I see a similar problem on darwin16, Xcode 9, bootstrapped with an older
version of gcc-8:

In file included from ./tm.h:16:0,
 from ../../work/gcc/genpreds.c:26:
 ./options.h:5803:2: error: #error too many target masks
  #error too many target masks

at stage 1, r253008 is OK.

[Bug bootstrap/82300] New: Bootstrapping gcc-8 does not work on darwin

[physiker at toast2 dot net]

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

Bug ID: 82300
   Summary: Bootstrapping gcc-8 does not work on darwin
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Bootstrapping gcc-8 [trunk revision 252896] on x86_64-apple-darwin15.6.0 does
not work. I utilize clang, the system compiler, for building stage 1.

echo timestamp > s-match
g++ -std=gnu++98 -c   -g  -DIN_GCC-fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include 
-I../../gcc/gcc/../libcpp/include -I/sw/include \
-o build/genattrtab.o ../../gcc/gcc/genattrtab.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
In file included from ../../gcc/gcc/genattrtab.c:107:
../../gcc/gcc/coretypes.h:73:1: warning: class 'rtx_def' was previously
declared as a struct [-Wmismatched-tags]
class rtx_def;
^
../../gcc/gcc/coretypes.h:55:8: note: previous use is here
struct rtx_def;
   ^
In file included from ../../gcc/gcc/genattrtab.c:107:
In file included from ../../gcc/gcc/coretypes.h:400:
../../gcc/gcc/machmode.h:313:1: warning: 'pod_mode' defined as a struct
template here but previously declared as a class template [-Wmismatched-tags]
struct pod_mode
^
../../gcc/gcc/coretypes.h:66:20: note: did you mean struct here?
template class pod_mode;
   ^
   struct
In file included from ../../gcc/gcc/genattrtab.c:108:
In file included from ./tm.h:16:
./options.h:5803:2: error: too many target masks
#error too many target masks
 ^
In file included from ../../gcc/gcc/genattrtab.c:109:
In file included from ../../gcc/gcc/rtl.h:31:
In file included from ../../gcc/gcc/hash-table.h:235:
../../gcc/gcc/ggc.h:272:8: warning: struct 'rtx_def' was previously declared as
a class [-Wmismatched-tags]
inline struct rtx_def *
   ^
../../gcc/gcc/coretypes.h:73:7: note: previous use is here
class rtx_def;
  ^
In file included from ../../gcc/gcc/genattrtab.c:109:
In file included from ../../gcc/gcc/rtl.h:31:
In file included from ../../gcc/gcc/hash-table.h:235:
../../gcc/gcc/ggc.h:275:11: warning: struct 'rtx_def' was previously declared
as a class [-Wmismatched-tags]
  return (struct rtx_def *) ggc_internal_alloc (s PASS_MEM_STAT);
  ^
../../gcc/gcc/coretypes.h:73:7: note: previous use is here
class rtx_def;
  ^
In file included from ../../gcc/gcc/genattrtab.c:109:
In file included from ../../gcc/gcc/rtl.h:31:
In file included from ../../gcc/gcc/hash-table.h:561:
../../gcc/gcc/mem-stats.h:126:1: warning: 'mem_usage' defined as a struct here
but previously declared as a class [-Wmismatched-tags]
struct mem_usage
^
../../gcc/gcc/hash-table.h:341:1: note: did you mean struct here?
class mem_usage;
^
struct
In file included from ../../gcc/gcc/genattrtab.c:109:
../../gcc/gcc/rtl.h:298:1: warning: 'rtx_def' defined as a struct here but
previously declared as a class [-Wmismatched-tags]
struct GTY((desc("0"), tag("0"),
^
../../gcc/gcc/coretypes.h:73:1: note: did you mean struct here?
class rtx_def;
^
struct
6 warnings and 1 error generated.
make[3]: *** [Makefile:2646: build/genattrtab.o] Fehler 1
make[3]: *** Es wird auf noch nicht beendete Prozesse gewartet
rm gcov.pod gpl.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod gcov-dump.pod
gcov-tool.pod
make[3]: Verzeichnis „/Users/Peter/Devel/buildgcc/gcc“ wird verlassen
make[2]: *** [Makefile:4662: all-stage1-gcc] Fehler 2
make[2]: Verzeichnis „/Users/Peter/Devel/buildgcc“ wird verlassen
make[1]: *** [Makefile:22008: stage1-bubble] Fehler 2
make[1]: Verzeichnis „/Users/Peter/Devel/buildgcc“ wird verlassen
make: *** [Makefile:974: all] Fehler 2

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

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
I have no idea what PREVAILING_DEF_IRONLY means, but a web search found
https://sourceware.org/bugzilla/show_bug.cgi?id=12370 -- I can't tell if that's
relevant.

[Bug c++/82299] New: -Wuseless-cast errors on typed enums used in member data initializers in c++1z

[matt at godbolt dot org]

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

Bug ID: 82299
   Summary: -Wuseless-cast errors on typed enums used in member
data initializers in c++1z
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

The follow code:

```
// compile with -Wuseless-cast -std=c++1z
enum Enum : char { A = 0, B = 1 };

struct S {
  Enum e { Enum::A };
};
```

Compiled with `-Wuseless-cast -std=c++1z` yields the following erroneous
warning:

```
5 : :5:20: warning: useless cast to type 'enum class Enum'
[-Wuseless-cast]
   Enum e { Enum::A };
^
```

This only happens if the `enum` is typed (e.g. the `char` above), and it's
compiled with std=c++1z.

Seems to have been introduced in GCC 7, still present in trunk.

(see https://godbolt.org/g/ehKEau )

[Bug tree-optimization/82289] [8 Regression] ICE at -O3 on x86_64-linux-gnu: in vect_get_num_copies, at tree-vectorizer.h:1093

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug tree-optimization/82289] [8 Regression] ICE at -O3 on x86_64-linux-gnu: in vect_get_num_copies, at tree-vectorizer.h:1093

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Sep 22 17:04:51 2017
New Revision: 253103

URL: https://gcc.gnu.org/viewcvs?rev=253103=gcc=rev
Log:
PR82289: Computing peeling costs for irrelevant drs

This PR shows that we weren't filtering out irrelevant stmts in
vect_get_peeling_costs_all_drs (unlike related loops in which
we iterate over all datarefs).

2017-09-22  Richard Sandiford  

gcc/
PR tree-optimization/82289
* tree-vect-data-refs.c (vect_get_peeling_costs_all_drs): Check
STMT_VINFO_RELEVANT_P.

gcc/testsuite/
PR tree-optimization/82289
* gcc.dg/vect/pr82289.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr82289.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

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

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
Author: msebor
Date: Fri Sep 22 16:30:35 2017
New Revision: 253100

URL: https://gcc.gnu.org/viewcvs?rev=253100=gcc=rev
Log:
Fix testsuite fallout from r252976.

gcc/testsuite/ChangeLog:

PR c/81854
* gcc.target/i386/pr80732.c: Correct a type error.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr80732.c

[Bug target/82298] New: x86 BMI: no peephole for BZHI

[peter at cordes dot ca]

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

Bug ID: 82298
   Summary: x86 BMI: no peephole for BZHI
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

gcc never seems to emit BZHI on its own.

// exact BZHI behaviour for all inputs (with no C UB)
unsigned bzhi_exact(unsigned x, unsigned c) {
c &= 0xff;
if (c <= 31) {
  x &= ((1U << c) - 1);
  // 1ULL defeats clang's peephole, but is a convenient way to avoid UB for
count=32.
}
return x;
}
// https://godbolt.org/g/tZKnV3

unsigned long bzhi_l(unsigned long x, unsigned c) {
return x & ((1UL << c) - 1);
}

Out-of-range shift UB allows peepholing to BZHI for the simpler case, so these
(respectively) should compile to

bzhil   %esi, %edi, %edi
bzhiq   %rsi, %rdi, %rax

But we actually get (gcc8 -O3 -march=haswell (-mbmi2))

movq$-1, %rax
shlx%rsi, %rax, %rdx
andn%rdi, %rdx, %rax
ret

Or that with a test for bzhi_exact.  Clang succeeds at peepholing BZHI
here, but it still does the &0xff and the test to skip BZHI when it
would do nothing.  It's easy to imagine cases where the source would use a
conditional to avoid UB when it wants to leave x unmodified for c==32, and the
range is 1 to 32:

unsigned bzhi_1_to_32(unsigned x, unsigned c) {
if (c != 32)
x &= ((1U << c) - 1);
return x;
}


BZHI is defined to saturate the index to OperandSize, so it copies src1
unmodified when the low 8 bits of src2 are >= 32 or >= 64.  (See the Operation
section of http://felixcloutier.com/x86/BZHI.html.  The text description is
wrong, claiming it saturates to OperandSize-1, which would zero the high bit.)

Other ways to express it (which clang fails to peephole to BZHI, like gcc):

unsigned bzhi2(unsigned x, unsigned c) {
//  c &= 0xff;
//  if(c < 32) {
  x &= (0xUL >> (32-c));
//  }
return x;
}

unsigned bzhi3(unsigned long x, unsigned c) {
// c &= 0xff;
return x & ~(-1U << c);
}



Related: pr65871 suggested this, but was really about taking advantage of flags
set by __builtin_ia32_bzhi_si so it is correctly closed.  pr66872 suggested
transforming x & ((1 << t) - 1); to x & ~(-1 << t); to enable ANDN.  Compiling
both to BZHI when BMI2 is available was mentioned, but the the main subject of
that bug either.

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #5 from Paolo Carlini  ---
Thanks Martin.

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
(In reply to Paolo Carlini from comment #3)

I'm not currently working on it.  Please feel free to assign the bug to
yourself and submit your patch instead.

[Bug ipa/82278] [8 regression] gcc.dg/lto/chkp-ctor-merge fail

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
Let me take a look.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #13 from Martin Liška  ---
Looking at resolution file of the compilation unit:

$ cat -- -lm.res
1
ice.o 39
...
1022 a2617b1cb04da8c1 PREVAILING_DEF_IRONLY _ZNSs4_Rep20_S_empty_rep_storageE
...


I'm not fully familiar with symbol resolution, but this looks fishy.
$ readelf -s /usr/lib64/gcc/x86_64-suse-linux/7/libstdc++.so --wide | grep
_ZNSs4_Rep20_S_empty_rep_storageE
  4310: 00388d4032 OBJECT  UNIQUE DEFAULT   28
_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4

Any ideas Jonathan?

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

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
N.B. this bug has been latent for years. The reason people are only seeing it
now is that usually the "extern template class std::basic_string"
explicit instantiation declarations prevent this symbol being emitted in user's
object files, so the definition in the library is used.

When compiling with -std=c++17 that extern template is not declared, so the
compiler emits a definition of that symbol in every object that uses the old
std::string.

[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Ingo from comment #3)
> And just because there is this paragraph in the C language specification,
> the compiler is then allowed to produce "random" code ?

Yes. The compiler assumes that undefined behavior is never invoked
and optimizes accordingly. This is nothing new.
If you need hand-holding use the sanitizers.

[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption

[lundril at gmx dot de]

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

--- Comment #3 from Ingo  ---
Just to be sure:

On a real machine this code is certainly not "undefined behavior", because
gMyUnion.numbers[ARRAYSIZE] aliases gMyUnion.dummy[ARRAYSIZE] and
gMyUnion.dummy[ARRAYSIZE] is a valid memory location.

So I guess there somewhere is a paragraph in the C language specification,
which says "this is undefined behavior", even if declaring this "undefined"
probably contradicts the semantics of unions and pointer arithmetic (specified
in the same said C language specification).

And just because there is this paragraph in the C language specification, the
compiler is then allowed to produce "random" code ?

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #11 from Martin Liška  ---
Confirmed, LTO really does a local object from the storage:

$ g++ -flto ice.cc && readelf -s a.out --wide | grep rep_storage
77: 006021a032 OBJECT  LOCAL  DEFAULT   26
_ZNSs4_Rep20_S_empty_rep_storageE
$ g++ ice.cc && readelf -s a.out --wide | grep rep_storage
25: 0060218032 OBJECT  UNIQUE DEFAULT   26
_ZNSs4_Rep20_S_empty_rep_storageE
   116: 0060218032 OBJECT  UNIQUE DEFAULT   26
_ZNSs4_Rep20_S_empty_rep_storageE

I'll take a look.

[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
We have a warning that handles the easiest counted loops, for anything else the
warning is too hard (could produce too many false positives).
Just use -fsanitize=undefined or other runtime instrumentation to find such
bugs.

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[ian at airs dot com]

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

--- Comment #17 from Ian Lance Taylor  ---
Tamar: Thanks for letting me know.  I just committed a patch that should fix
that problem.

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[ian at gcc dot gnu.org]

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

--- Comment #16 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Sep 22 13:38:10 2017
New Revision: 253095

URL: https://gcc.gnu.org/viewcvs?rev=253095=gcc=rev
Log:
PR sanitizer/77631
* configure.ac: Check for lstat and readlink.
* elf.c (lstat, readlink): Provide dummy versions if real versions
are not available.
* configure, config.h.in: Rebuild.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/config.h.in
trunk/libbacktrace/configure
trunk/libbacktrace/configure.ac
trunk/libbacktrace/elf.c

[Bug c++/82297] Link error when templated inherited constructor has default arguments

[joel.falcou at lri dot fr]

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

--- Comment #4 from joel falcou  ---
Created attachment 42227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42227=edit
repro

[Bug c++/81860] [7/8 Regression] Call to undefined inline function involving inheriting constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|wrong-code  |link-failure

--- Comment #4 from Jonathan Wakely  ---
Testcase from PR 82297, which produces an undefined reference for a function
used in a default argument of an inherited constructor:

template
struct bug_t {};

template
bug_t make_bug(const T&) { return {}; }

template
struct Test {
  template
  Test(const U& , const bug_t = make_bug(0)) {}

  /**
   * Also generates an error, at compile time, related bug ?
   */
  // template
  // Test(const U& , const bug_t = make_bug(0)) {}
};

template
struct img_t : Test {
  using Test::Test;
};

template
img_t make_img(int val) {
  return {val};
}

int main() {
  make_img(2);
}

/tmp/ccix9VDk.o: In function `img_t make_img(int)':
inh.cc:(.text._Z8make_imgIcE5img_tIT_Ei[_Z8make_imgIcE5img_tIT_Ei]+0x1e):
undefined reference to `bug_t make_bug(int const&)'
collect2: error: ld returned 1 exit status

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c   |tree-optimization

[Bug c/82285] [6/7/8 Regression] Optimizing error when using enumeration

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Simplified test-case:

$ cat ~/Programming/testcases/pr82285.c
#define MAX (16)

enum tst {
first = 0,
second = 1
};

int
main (void)
{
  enum tst data[MAX];

  for (unsigned i = 0; i < MAX; i++)
data[i] = (i < 5 ? second : first);

  if (data[2] != second) {
__builtin_abort ();
  }
  return 0;
}

Problem is that vectorizes does:

  vect_cst__20 = { 4, 4, 4, 4 };
  # vect_vec_iv_.0_13 = PHI 
  mask__1.1_21 = vect_vec_iv_.0_13 <= vect_cst__20;
  vect__2.2_25 = VIEW_CONVERT_EXPR(mask__1.1_21);
  MEM[(tst *)vectp_data.3_29] = vect__2.2_25;

which is folded in dom3 to:
gimple_simplified to mask__1.1_21 = { -1, -1, -1, -1 };

Then we end up with:
  MEM[(tst *)] = { 4294967295, 4294967295, 4294967295, 4294967295 };

It's related to fact that vector of true values is represented as {-1,..., -1}.
Leaving to someone skilled in vectorizer ;)

[Bug c++/81860] [7/8 Regression] Call to undefined inline function involving inheriting constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||joel.falcou at lri dot fr

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

[Bug c++/82297] Link error when templated inherited constructor has default arguments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Found it...

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

[Bug c++/82297] Link error when templated inherited constructor has default arguments

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This is a dup of an existing bug, use -fno-new-inheriting-ctors as a
workaround.

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #3 from Paolo Carlini  ---
Hi Martin. Are you still actively working on this? Because something
implementing as trivially as the below what Jason suggested on the mailing list
already appears to pass testing, shouldn't be *that* far from an actual fix...

Index: decl.c
===
--- decl.c  (revision 253091)
+++ decl.c  (working copy)
@@ -12348,7 +12348,11 @@

 /* Set constexpr flag on vars (functions got it in grokfndecl).  */
 if (constexpr_p && VAR_P (decl))
-  DECL_DECLARED_CONSTEXPR_P (decl) = true;
+  {
+   DECL_DECLARED_CONSTEXPR_P (decl) = true;
+   if (!processing_template_decl)
+ complete_type (TREE_TYPE (decl));
+  }

 /* Record constancy and volatility on the DECL itself .  There's
no need to do this when processing a template; we'll do this

[Bug c++/82297] Link error when templated inherited constructor has default arguments

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-22
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you please attach the testcase?  One cannot cut from this website.

[Bug c++/82297] New: Link error when templated inherited constructor has default arguments

[joel.falcou at lri dot fr]

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

Bug ID: 82297
   Summary: Link error when templated inherited constructor has
default arguments
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel.falcou at lri dot fr
  Target Milestone: ---

The following code:

http://coliru.stacked-crooked.com/a/a2657ad530025420

fails to link on g++ 7.1 and 7.2

Older g++ and current clang accept the code.

[Bug c/82296] Wrong code with optimization -O2

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Thomas Koenig  ---
You have...

#define ARRAYSIZE 5
union {
int numbers[ARRAYSIZE];
int dummy[ARRAYSIZE+1];
} gMyUnion;

and then

if (gMyUnion.numbers[i] > 5)
return 1;
if (i == ARRAYSIZE)
fatal_error();
i++;

The compiler is assuming that you never exceed the
bounds of gMyUnion.numbers. Threfore, i can never be 5,
and the call to fatal_error can never happen.

Change .numbers to .dummy, or move the check for i
before the other statement, and the change will not happen.

Is the compiler right to do so? Yes.

Should it warn if asked? IMHO yes (and it doesn't appear
to do so).

Confirmed as an enhancement request.

[Bug c/82296] New: Wrong code with optimization -O2

[lundril at gmx dot de]

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

Bug ID: 82296
   Summary: Wrong code with optimization -O2
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lundril at gmx dot de
  Target Milestone: ---

Created attachment 42226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42226=edit
Compiling this code results in assembler which translates to "return 1;"

To reproduce
  gcc -O2 -S gcc_check.c

The attached C code seems to produce assembler code which just ALWAYs
implements "return 1;" everything else is optimized away.

I think this is wrong ?

I tried this with

* GCC 4.9.2 for x64
* GCC 5.4.0 for x64
* GCC 7.2.1 for x64
* GCC 4.8.4 for ARM
* GCC 6.3.1 for PowerPC

it seems all of these versions produce assembler code, which implements "return
1;".

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|8.0 |7.3
Summary|[8 Regression] wrong code   |[7 Regression] wrong code
   |at -O3 on x86_64-linux-gnu  |at -O3 on x86_64-linux-gnu

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar, queued for backporting as the issue is latent.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Sep 22 12:00:55 2017
New Revision: 253093

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

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

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr82291.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Testcase (takes a bit too long / time for the testsuite):

#define F(i) int F ## i () { return i; }
#define FS(x) F(x ## 0) F(x ## 1) F(x ## 2) F(x ## 3) F(x ## 4) F(x ## 5) F(x
## 6) F(x ## 7) F(x ## 8) F(x ## 9)
#define FS1(x) FS(x ## 0) FS(x ## 1) FS(x ## 2) FS(x ## 3) FS(x ## 4) FS(x ##
5) FS(x ## 6) FS(x ## 7) FS(x ## 8) FS(x ## 9)
#define FS2(x) FS1(x ## 0) FS1(x ## 1) FS1(x ## 2) FS1(x ## 3) FS1(x ## 4)
FS1(x ## 5) FS1(x ## 6) FS1(x ## 7) FS1(x ## 8) FS1(x ## 9)
#define FS3(x) FS2(x ## 0) FS2(x ## 1) FS2(x ## 2) FS2(x ## 3) FS2(x ## 4)
FS2(x ## 5) FS2(x ## 6) FS2(x ## 7) FS2(x ## 8) FS2(x ## 9)
#define FS4(x) FS3(x ## 0) FS3(x ## 1) FS3(x ## 2) FS3(x ## 3) FS3(x ## 4)
FS3(x ## 5) FS3(x ## 6)

FS4(1)

int main() {}

> ./xgcc -B. t.c -flto -g 
/tmp/ccfYIkiwdebugobjtem: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
lto-wrapper: fatal error: ./xgcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

that's with the attached patch, it seems to work fine without it.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Created attachment 42225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42225=edit
patch to really remove discarded sections

The attached removes discarded sections and thus should avoid one class of
warnings.  It's incomplete with now dead code not removed and incomplete in
not handling SHN_XINDEX (I suppose the code marking required sections as needed
isn't handling that correctly either).  I'm quite sure we eventually would
have to care for this given LTO bytecode contains one section per function
(so we need "only" ~65250 functions to trigger an issue).

Note that SHT_NULL is documented as

#define SHT_NULL  0 /* Section header table entry unused */

that doesn't mean that such unused entries do not exist.  Not sure what Solaris
ld is really complaining about...  Alternatively we could use an empty SHT_NOTE
with SHF_EXCLUDE (but maybe it then warns about empty SHT_NOTE or one without
a section name...).

For the symbol table entry issue I'm not sure, I obviously can't produce
an assembler testcase producing a UNDEF global without a referece to it.
But I can believe the linker isn't forced to "remove" unused UNDEFs in
case they are present.  But maybe it is, as said, a question for the Solaris
ld folks again.

Similar to the attached patch a patch rewriting all relocation entries
with a to be produced symbol table mapping would be possible.

[Bug tree-optimization/82289] [8 Regression] ICE at -O3 on x86_64-linux-gnu: in vect_get_num_copies, at tree-vectorizer.h:1093

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Seems like we're considering DRs for statements that aren't relevant.

[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 22 Sep 2017, nunoplopes at sapo dot pt wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82282
> 
> --- Comment #4 from Nuno Lopes  ---
> There are two major transformations going on:
>   if (u != v) {
> v = u;
>   }
> =>
>   v = u
> 
> (with v, u integers)
> 
> and:
> 
>   glb = (int*)(uinptr_t)foo)
> =>
>   glb = foo
> 
> 
> Doing both triggers the end-to-end miscompilation for a C program that 
> exhibits
> no UB.  That means that one of transformations is wrong.
> Disabling integer propagation would be really weird and bad.
> So we are left with making "(int*)(uinptr_t)foo -> foo" an invalid
> transformation in general.  It's correct in some cases, but not always.

The C standard says it is correct as in, it yields the same pointer.

[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

[nunoplopes at sapo dot pt]

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

--- Comment #4 from Nuno Lopes  ---
There are two major transformations going on:
  if (u != v) {
v = u;
  }
=>
  v = u

(with v, u integers)

and:

  glb = (int*)(uinptr_t)foo)
=>
  glb = foo


Doing both triggers the end-to-end miscompilation for a C program that exhibits
no UB.  That means that one of transformations is wrong.
Disabling integer propagation would be really weird and bad.
So we are left with making "(int*)(uinptr_t)foo -> foo" an invalid
transformation in general.  It's correct in some cases, but not always.

AA is behaving correctly because it is working just over pointers (since
integer casts were removed) and thus it is allowed to looking strictly at
data-flow dependencies.

The fix, we believe, is simple: remove the transformation "(int*)(uinptr_t)foo
-> foo", or enable it just in the cases when it's correct.
For example, it's correct in this case:
  int v = p; // p is provably dereferenceable
  int *q = v;
  *q = ..;
=>
  *p = ...;

but it's not correct in this case (at GIMPLE/SSA level):
  int v = p; // p may *not* be dereferenceable
  int *q = v;
  *q = ..;
=>
  *p = ...;

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #15 from Tamar Christina  ---
This patch is causing the aarch64 and arm baremetal builds to fail because
newlib doesn't seem to have lstat.

/tmp/aarch64-none-elf/build/src/gcc/libbacktrace/elf.c: In function
'elf_is_symlink':

/tmp/aarch64-none-elf/build/src/gcc/libbacktrace/elf.c:659:7: error: implicit
declaration of function 'lstat'; did you mean 'stat'?
[-Werror=implicit-function-declaration]

   if (lstat (filename, ) < 0)

   ^

   stat

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

[hermantenbrugge at home dot nl]

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

--- Comment #3 from Herman ten Brugge  ---
If I put:

  if (p_input_matrix->nof_rows > MAX_MATRIX_SIZE || p_input_matrix->nof_cols >
MAX_MATRIX_SIZE) return;

at the start of my function I still get the warning.

I removed some assert statement at the start of the original code because they
did nothing to preevent the warning.

[Bug target/82274] __builtin_mul_overflow fails to detect overflow for int64_t when compiled with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 22 Sep 2017, nunoplopes at sapo dot pt wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82282
> 
> --- Comment #2 from Nuno Lopes  ---
> This is different from PR82177. That bug is in AA, this one is not.
> 
> See the C source:
>   uintptr_t u = (uintptr_t) (x + 1);
>   uintptr_t v = (uintptr_t) y;
> 
>   // if b1 true, then b2 must be true as well
>   int b1 = u != v;
>   int b2 = u+1 != v+1;
> 
>   if (b1) {
> v = u;
>   }
>   // glb = y if b1 false, glb = u if b1 true
>   glb = (int*) v;
> 
>   if (b2) {
> // glb = x
> glb = x;
>   }
> 
>   // glb = y if b1/b2 false, glb = x if b1/b2 true
> 
> So at this point, glb can alias either x or y. There's not UB. The cast is 
> from
> a legitimate value.
> The problem is that gcc replaces
>   if (u != v) {
> v = u;
>   }
> 
> simply with:
> v = u;
> 
> Which is a correct integer transformation. The deal is that it breaks the
> data-flow dependency on 'y'. When the int2ptr cast is removed from "glb =
> (int*)v", we get "glb = x + 1", which is wrong.  This behavior couldn't ever
> happen in the C program.

You say that deriving from the equivalency v == u the equivalency
 + 1 ==  is wrong, correct?  But you are writing an obfuscated

 u = (uintptr_t) (x + 1);
 glb = (int *)u;

and expect glb now magically point to y as well.

Note that the points-to run after phiopt (it re-runs right from before
PRE) produces:

glb.2_3, points-to non-local, points-to escaped, points-to NULL, points-to 
vars: { D.2337 } (escaped)

because there we already have the

  # v_1 = PHI 
  v.0_19 = (int *) v_1;
  glb = v.0_19;

and thus it sees v_1 only pointing to what u points to.

So this is the same as the other PR - it is about an alias derived
from the u == v equivalency.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Odd bisection result, it seems to be a latent issue in if-conversion which
doesn't handle false predicates correctly as it simply skips predicating
writes in that case.

[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

[nunoplopes at sapo dot pt]

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

--- Comment #2 from Nuno Lopes  ---
This is different from PR82177. That bug is in AA, this one is not.

See the C source:
  uintptr_t u = (uintptr_t) (x + 1);
  uintptr_t v = (uintptr_t) y;

  // if b1 true, then b2 must be true as well
  int b1 = u != v;
  int b2 = u+1 != v+1;

  if (b1) {
v = u;
  }
  // glb = y if b1 false, glb = u if b1 true
  glb = (int*) v;

  if (b2) {
// glb = x
glb = x;
  }

  // glb = y if b1/b2 false, glb = x if b1/b2 true

So at this point, glb can alias either x or y. There's not UB. The cast is from
a legitimate value.
The problem is that gcc replaces
  if (u != v) {
v = u;
  }

simply with:
v = u;

Which is a correct integer transformation. The deal is that it breaks the
data-flow dependency on 'y'. When the int2ptr cast is removed from "glb =
(int*)v", we get "glb = x + 1", which is wrong.  This behavior couldn't ever
happen in the C program.

[Bug c++/82295] New: Two errors produced with private/protected deleted methods

[denis.campredon at gmail dot com]

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

Bug ID: 82295
   Summary: Two errors produced with private/protected deleted
methods
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Hello,
The following code produces
---
class C {
int f() = delete;
};

int f() {
return C().f();
}
--
Will produce the followings messages

---
: In function 'int f()':
:6:15: error: 'int C::f()' is private within this context
  return C().f();
   ^
:2:6: note: declared private here
  int f() = delete;
  ^
:6:15: error: use of deleted function 'int C::f()'
  return C().f();
   ^
:2:6: note: declared here
  int f() = delete;
  ^
-

Since the method is deleted only the second error should be displayed.

[Bug c/82285] [6/7/8 Regression] Optimizing error when using enumeration

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|Optimizing error when using |[6/7/8 Regression]
   |enumeration |Optimizing error when using
   ||enumeration
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r230098. Let me take a look.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Looks my sample is not correct as e is global variables and may be out of
bounds of the array.

Similar to your sample:

p_input_matrix->nof_rows and p_input_matrix->nof_cols is not guaranteed to be
in range 0..MAX_MATRIX_SIZE-1. Thus both row and col may be out of bounds.
Well, the warning is not precise, word 'maybe' would be more precise in this
case.

[Bug c++/82294] Array of objects with constexpr constructors initialized from space-inefficient memory image

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Probably similar in that the C++ FE should learn to emit loops for array
initializers...

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Version|unknown |8.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Mine.

[Bug rtl-optimization/82290] [8 Regression] ICE at -O2 on x86_64-linux-gnu: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug go/82284] [7 Regression] go -version segfaults on big endian architectures

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
So fixed.

[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||82177

--- Comment #1 from Richard Biener  ---
This is really the same / similar as PR82177.

  if (u_14 != v_15)
goto ;
  else
goto ;

  :
  # v_1 = PHI 
  v.0_19 = (int *) v_1;
  glb = v.0_19;

so there's a missed trivial optimization not done by phiopt to

  u_14 = (uintptr_t) [(void *) + 4B];
...
  if (u_14 != v_15)
goto ;
  else
goto ;

  :
  v.0_19 = (int *) u_14;

where (int *) u_14 would be folded to just [(void *) + 4B].

It's not partial redundancy elimination but value-numbering does this
kind of cleanup.  forwprop would also do it and there's nothing wrong
with this.

In C you are only allowed to convert a pointer back and forth
with [u]intptr_t, so when you convert it back you get the original
pointer which means it still points to one-after 'x'.  You can't
make it possibly point to 'y' by this trick.  Specifically you
are not allowed to make a uintptr_t from a pointer to object A,
do some magic on that value, convert it to a pointer again and
expect it to point to object B.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82177
[Bug 82177] Alias analysis too aggressive with integer-to-pointer cast

[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 #6 from Paul Thomas  ---
Author: pault
Date: Fri Sep 22 08:38:31 2017
New Revision: 253091

URL: https://gcc.gnu.org/viewcvs?rev=253091=gcc=rev
Log:
2017-09-22  Paul Thomas  

PR fortran/52832
* gfortran.dg/associate_31.f90 : Remove failing test.

Removed:
trunk/gcc/testsuite/gfortran.dg/associate_31.f90

[Bug c++/82294] New: Array of objects with constexpr constructors initialized from space-inefficient memory image

[headch at gmail dot com]

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

Bug ID: 82294
   Summary: Array of objects with constexpr constructors
initialized from space-inefficient memory image
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Consider the following code:

$ cat test.cpp
struct S {
int x;

explicit constexpr S();
};

constexpr S::S() : x{7} {}

struct T {
S objects[256];

explicit T();
};

T::T() {}


Compile it as follows:

$ g++ -Wall -Wextra -march=native -std=c++17 -Os -c test.cpp


Dumping the resulting object file reveals that T::T() is implemented by
memcpying (depending on the target architecture sometimes inline or sometimes
by an actual memcpy call) a kilobyte of data from .rodata into the array being
initialized. For two or three S objects that might be a good, efficient
solution. For 256 of them, a kilobyte of memory entirely filled with sevens to
serve as an initialization image is rather ridiculous compared to just using a
loop to store seven into the objects one by one. This is especially egregious
considering I was asking to optimize for size!

Making S::S() non-constexpr improves the situation, though it’s hardly an ideal
solution.

This might be related to any of #12245, #56671, #59659, #63728, #68399, or
#71165, but none of them describe quite the same problem. The first five are
about memory or CPU time usage during compilation (not about the generated
code), and #71165 is specifically about aggregate initialization and appears to
be an unrolled loop in code rather than a huge data blob.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-22
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I reduced the test-case a bit:

$ cat pr82286.c
typedef struct
{
  float a[10][10];
} b;

float c;
b d;
int e = 0;

void
f ()
{
  int g;
  for (;;)
for (g = 0; g < e; g++)
  c = d.a[e][g];
}

$ ./xgcc -B. ~/Programming/testcases/pr82286.c -O3 -Wall -c
-fdump-tree-all-details
/home/marxin/Programming/testcases/pr82286.c: In function ‘f’:
/home/marxin/Programming/testcases/pr82286.c:16:14: warning: array subscript is
above array bounds [-Warray-bounds]
   c = d.a[e][g];
   ~~~^~~

It's caused by loop unroller:

Loop 2 iterates at most 10 times.
Loop 2 likely iterates at most 10 times.
Estimating sizes for loop 2
 BB: 5, after_exit: 0
  size:   1 e.1_2 = e;
  size:   2 if (e.1_2 > g_3)
   Exit condition will be eliminated in last copy.
 BB: 4, after_exit: 1
  size:   1 _1 = d.a[e.1_2][g_3];
  size:   1 c = _1;
  size:   1 g_8 = g_3 + 1;
   Induction variable computation will be folded away.
size: 6-1, last_iteration: 3-2
  Loop size: 6
  Estimated size after unrolling: 34

Then we end with:

...
   [0.10%] [count: INV]:
  _60 = d.a[e.1_59][8];
  c = _60;
  e.1_65 = e;
  if (e.1_65 > 9)
goto ; [50.00%] [count: INV]
  else
goto ; [50.00%] [count: INV]

   [0.10%] [count: INV]:
  _66 = d.a[e.1_65][9];
  c = _66;
  e.1_2 = e;

   [50.00%] [count: INV]:
  goto ; [100.00%] [count: INV]

Which is not correct, gcc_unreachable is somehow optimized out. I'll take a
look.

[Bug target/82281] Bulldozer/Zen tuning: uses XMM for single 64-bit integer AND, even with a simple mask

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Honza is looking into generic/Zen tuning.

[Bug c++/82293] [8 Regression] ICE in nonlambda_method_basetype at gcc/cp/lambda.c:886

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug c++/82288] Defining a type in a parameter type of a lambda calling an undefined function results in a Segfault

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, ICEs on all releases I have (4.5.0+).

[Bug tree-optimization/82289] [8 Regression] ICE at -O3 on x86_64-linux-gnu: in vect_get_num_copies, at tree-vectorizer.h:1093

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|ICE at -O3 on   |[8 Regression] ICE at -O3
   |x86_64-linux-gnu: in|on x86_64-linux-gnu: in
   |vect_get_num_copies, at |vect_get_num_copies, at
   |tree-vectorizer.h:1093  |tree-vectorizer.h:1093
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r252764.

[Bug rtl-optimization/82290] [8 Regression] ICE at -O2 on x86_64-linux-gnu: verify_flow_info failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||marxin at gcc dot gnu.org
Summary|ICE at -O2 on   |[8 Regression] ICE at -O2
   |x86_64-linux-gnu:   |on x86_64-linux-gnu:
   |verify_flow_info failed |verify_flow_info failed
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r250390.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-22
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|wrong code at -O3 on|[8 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, nice snippet. Started with r247596.

[Bug c++/82293] New: [8 Regression] ICE in nonlambda_method_basetype at gcc/cp/lambda.c:886

[marxin at gcc dot gnu.org]

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

Bug ID: 82293
   Summary: [8 Regression] ICE in nonlambda_method_basetype at
gcc/cp/lambda.c:886
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following ICEs starting from r251433:

$ g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice20.C  
-std=c++14 -Wshadow
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice20.C:6:29:
internal compiler error: Segmentation fault
   int f{[this](){return 42;}()};
 ^~
0xd9905f crash_signal
../../gcc/toplev.c:341
0x6f7a8f nonlambda_method_basetype()
../../gcc/cp/lambda.c:886
0x73010f check_local_shadow
../../gcc/cp/name-lookup.c:2744
0x73010f do_pushdecl
../../gcc/cp/name-lookup.c:3048
0x73010f pushdecl(tree_node*, bool)
../../gcc/cp/name-lookup.c:3111
0x7320e7 do_pushdecl_with_scope
../../gcc/cp/name-lookup.c:3948
0x7327e7 do_pushtag
../../gcc/cp/name-lookup.c:6316
0x7327e7 pushtag(tree_node*, tree_node*, tag_scope)
../../gcc/cp/name-lookup.c:6385
0x69076f xref_tag_1
../../gcc/cp/decl.c:13615
0x69076f xref_tag(tag_types, tree_node*, tag_scope, bool)
../../gcc/cp/decl.c:13671
0x6f4441 begin_lambda_type(tree_node*)
../../gcc/cp/lambda.c:141
0x799acf tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:16862
0x79a943 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18209
0x79ac70 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17522
0x79c1e0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18058
0x6f1047 get_nsdmi(tree_node*, bool, int)
../../gcc/cp/init.c:581
0x860b53 process_init_constructor_record
../../gcc/cp/typeck2.c:1430
0x860b53 process_init_constructor
../../gcc/cp/typeck2.c:1626
0x860b53 digest_init_r
../../gcc/cp/typeck2.c:1135
0x800f80 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
../../gcc/cp/semantics.c:2750

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
  Component|bootstrap   |libfortran
Version|7.2.1   |8.0
   Target Milestone|--- |8.0

--- Comment #4 from Andrew Pinski  ---
Actually there might be an issue here:
typedef _Complex float __attribute__((mode(TC))) __complex128;

in libgfortran/acinclude.m4 .
Because IEEE 128bit uses KC while TC is used for IBM fortran long double.


See PR 81848 which uses KC inside libquadmath rather than TC.

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

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
trying, however this is changed behavior compared to the gcc-7-branch.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Try also adding:
--disable-libquadmath-support

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>--disable-libquadmath


That is most likely the cause.

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

[doko at gcc dot gnu.org]

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

Bug ID: 82292
   Summary: [8 Regression] bootstrap fails in libgfortran on
powerpc64le-linux-gnu
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20170917, 20170921:

libtool: compile:  /<>/build/./gcc/xgcc
-B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../src/libgfortran -iquote../../../src/libgfortran/io
-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config
-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc
-I../../../src/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT single.lo -MD -MP -MF
.deps/single.Tpo -c ../../../src/libgfortran/caf/single.c  -fPIC -DPIC -o
.libs/single.o
libtool: compile:  /<>/build/./gcc/xgcc
-B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../src/libgfortran -iquote../../../src/libgfortran/io
-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config
-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc
-I../../../src/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT bounds.lo -MD -MP -MF
.deps/bounds.Tpo -c ../../../src/libgfortran/runtime/bounds.c  -fPIC -DPIC -o
.libs/bounds.o
In file included from ../../../src/libgfortran/caf/libcaf.h:33:0,
 from ../../../src/libgfortran/caf/single.c:26:
../../../src/libgfortran/libgfortran.h:61:12: fatal error: quadmath_weak.h: No
such file or directory
 #  include "quadmath_weak.h"
^
compilation terminated.
Makefile:2384: recipe for target 'single.lo' failed
make[5]: *** [single.lo] Error 1
make[5]: *** Waiting for unfinished jobs
In file included from ../../../src/libgfortran/runtime/bounds.c:25:0:
../../../src/libgfortran/libgfortran.h:61:12: fatal error: quadmath_weak.h: No
such file or directory
 #  include "quadmath_weak.h"
^
compilation terminated.
Makefile:2391: recipe for target 'bounds.lo' failed
make[5]: *** [bounds.lo] Error 1
make[5]: Leaving directory
'/<>/build/powerpc64le-linux-gnu/libgfortran'
Makefile:1317: recipe for target 'all' failed
make[4]: *** [all] Error 2
make[4]: Leaving directory
'/<>/build/powerpc64le-linux-gnu/libgfortran'
Makefile:19445: recipe for target 'all-target-libgfortran' failed
make[3]: *** [all-target-libgfortran] Error 2

Configured with: -v
 --enable-languages=c,ada,c++,go,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --with-gcc-major-version-only
 --program-prefix=
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --with-sysroot=/
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libquadmath
 --enable-plugin
 --with-system-zlib
 --enable-objc-gc=auto
 --enable-secureplt
 --with-cpu=power8
 --enable-targets=powerpcle-linux
 --disable-multilib
 --enable-multiarch
 --disable-werror
 --with-long-double-128
 --enable-checking=yes
 --build=powerpc64le-linux-gnu
 --host=powerpc64le-linux-gnu
 --target=powerpc64le-linux-gnu