[Bug fortran/82372] Rejects valid parenthesis

[jvdelisle at gcc dot gnu.org]

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

--- Comment #1 from Jerry DeLisle  ---
Another, reduced:

program vincenty
implicit none

integer,  parameter :: wp = selected_real_kind (18) ! Working Precision
real(wp), parameter :: f = 1.0_wp/298.257223563_wp
real(wp) :: tmp

tmp = 1.0 − f

end program

$ cat bug1.f90 
program vincenty
implicit none

integer,  parameter :: wp = selected_real_kind (18) ! Working Precision
real(wp), parameter :: f = 1.0_wp/298.257223563_wp
real(wp) :: tmp

tmp = 1.0 − f

end program
[jerry@amda8 vincenty]$ gfc bug1.f90 
bug1.f90:8:0:

 tmp = 1.0 − f

Error: Unclassifiable statement at (1)

[Bug fortran/82372] New: Rejects valid parenthesis

[jvdelisle at gcc dot gnu.org]

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

Bug ID: 82372
   Summary: Rejects valid parenthesis
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

program vincenty
implicit none

integer,  parameter :: wp = selected_real_kind (18) ! Working Precision
real(wp), parameter :: f = 1.0_wp/298.257223563_wp
real(wp), parameter  :: pi = 3.141592653589793238462643383279502884197_wp
real(wp) :: theta1, theta2
real(wp) :: U1, U2

theta1 = 2.0_wp * pi * 46.222539_wp
theta2 = 0.7_wp

U1 = sin((1.0 − f) * tan(theta1))

end program

$ gfc bug1.f90 
bug1.f90:13:13:

 U1 = sin((1.0 − f) * tan(theta1))
 1
Error: Expected a right parenthesis in expression at (1)

I am not seeing whats is wrong. Please someone confirm.

[Bug plugins/82371] [5/6/7/8 Regression] Cross-compiling GCC fails when build platform has fread_unlocked but host platform doesn't

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
  Component|c   |plugins
   Target Milestone|--- |5.5
Summary|Cross-compiling GCC fails   |[5/6/7/8 Regression]
   |when build platform has |Cross-compiling GCC fails
   |fread_unlocked but host |when build platform has
   |platform doesn't|fread_unlocked but host
   ||platform doesn't
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Oh this is a regression too when building gengtype was added to be a host
utility for plugin support.

Which was introduced by:
commit 6d70c7134ed4620d4fe74f777ab771602845e135
Author: jakub 
Date:   Thu Aug 4 11:30:45 2011 +

2011-08-04  Romain Geissler  

* gengtype-state.c: Include "bconfig.h" if
GENERATOR_FILE is defined, "config.h" otherwise.
* gengtype.c: Likewise.
* gengtype-lex.l: Likewise.
* gengtype-parse.c: Likewise.
* Makefile.in (gengtype-lex.o-warn): New variable.
(plugin_resourcesdir): Likewise.
(plugin_bindir): Likewise.
(plugin_includedir): Use $(plugin_resourcesdir) as prefix base.
(MOSTLYCLEANFILES): Add gengtype$(exeext).
(native): Depend on gengtype$(exeext) is $enable_plugin
is set to "yes".
(gtype.state): Depend on s-gtype. Use temporary file.
(gengtype-lex.o): New rule.
(gengtype-parse.o): Likewise.
(gengtype-state.o): Likewise.
(gengtype$(exeext)): Likewise.
(install-gengtype): Likewise.
(gengtype.o): Likewise.
(build/gengtype.o): Depend on version.h.
(build/gengtype-state): Depend on double-int.h, version.h,
$(HASHTAB_H), $(OBSTACK_H), $(XREGEX_H) and build/errors.o.
(install-plugin): Depend on install-gengtype.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@177358
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c/82371] New: Cross-compiling GCC fails when build platform has fread_unlocked but host platform doesn't

[bugs at rkjnsn dot net]

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

Bug ID: 82371
   Summary: Cross-compiling GCC fails when build platform has
fread_unlocked but host platform doesn't
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at rkjnsn dot net
  Target Milestone: ---

Note: I encountered this on 5.4.0, but I took a quick peek at the trunk source
code and the error still seems to be present.

When attempting to cross-compile GCC for a host system that does not have
fread_unlocked on a build system that does, the build fails with the following
error:

gengtype-lex.o: In function `yy_get_next_buffer':
/path/to/gcc-build/gcc/../../gcc-5.4.0/gcc/gengtype-lex.c:2182: undefined
reference to `fread_unlocked'

The problem seems to stem from the fact that gcc/gengtype-lex.l needs to be
compiled for both the build and host platforms, but includes bconfig.h in both
cases. The include directives in gcc/gengtype-lex.l itself, however, are
properly guarded:

#ifdef HOST_GENERATOR_FILE
#include "config.h"
#define GENERATOR_FILE 1
#else
#include "bconfig.h"
#endif

After some digging I discovered that the problem appears to be in
gcc/Makefile.in:

# Generated source files for gengtype.  Prepend inclusion of
# bconfig.h because AIX requires _LARGE_FILES to be defined before
# any system header is included.
gengtype-lex.c : gengtype-lex.l
-$(FLEX) $(FLEXFLAGS) -o$@ $< && { \
  echo '#include "bconfig.h"' > $@.tmp; \
  cat $@ >> $@.tmp; \
  mv $@.tmp $@; \
}

This causes the generated gcc/gengtype-lex.c to include bconfig.h regardless of
whether compiling for the build system or the host system, resulting in
HAVE_FREAD_UNLOCKED being defined when it shouldn't be (which leads to the
linker error).

[Bug target/82370] New: AVX512 can use a memory operand for immediate-count vpsrlw, but gcc doesn't.

[peter at cordes dot ca]

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

Bug ID: 82370
   Summary: AVX512 can use a memory operand for immediate-count
vpsrlw, but gcc doesn't.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ssemmx
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include 
#include 
#include 
void pack_high8_alignhack(uint8_t *restrict dst, const uint8_t *restrict src,
size_t bytes) {
  uint8_t *end_dst = dst + bytes;
  do{
 __m128i v0 = _mm_loadu_si128((__m128i*)src);
 __m128i v1_offset = _mm_loadu_si128(1+(__m128i*)(src-1));
 v0 = _mm_srli_epi16(v0, 8);
 __m128i v1 = _mm_and_si128(v1_offset, _mm_set1_epi16(0x00FF));
 __m128i pack = _mm_packus_epi16(v0, v1);
 _mm_storeu_si128((__m128i*)dst, pack);
 dst += 16;
 src += 32;  // 32 bytes
  } while(dst < end_dst);
}

pack_high8_alignhack:
vmovdqa64   .LC0(%rip), %xmm2# pointless EVEX when VEX is
shorter
addq%rdi, %rdx
.L18:
vmovdqu64   (%rsi), %xmm0
vpandq  15(%rsi), %xmm2, %xmm1   # pointless EVEX vs. VPAND
addq$16, %rdi
addq$32, %rsi
vpsrlw  $8, %xmm0, %xmm0 # could use a memory source.
vpackuswb   %xmm1, %xmm0, %xmm0
vmovups %xmm0, -16(%rdi)
cmpq%rdi, %rdx
ja  .L18
ret

There's no benefit to using VPANDQ (4-byte EVEX prefix) instead of VPAND
(2-byte VEX prefix).  Same for VMOVDQA64.  We should only use the AVX512
version when we need masking, ZMM register size, or xmm/ymm16-31.

Or in this case, to use the AVX512VL+AVX512BW form that lets us fold a load
into a memory operand:  VPSRLW xmm1 {k1}{z}, xmm2/m128, imm8 
(https://hjlebbink.github.io/x86doc/html/PSRLW_PSRLD_PSRLQ.html).  IACA2.3 says
it micro-fuses, so it's definitely worth it.

Clang gets everything right and emits:

pack_high8_alignhack:
addq%rdi, %rdx
vmovdqa .LCPI2_0(%rip), %xmm0# Plain AVX (VEX prefix)
.LBB2_1:
vpsrlw  $8, (%rsi), %xmm1# load folded into AVX512BW version
vpand   15(%rsi), %xmm0, %xmm2   # AVX-128 VEX encoding.
vpackuswb   %xmm2, %xmm1, %xmm1
vmovdqu %xmm1, (%rdi)
addq$16, %rdi
addq$32, %rsi
cmpq%rdx, %rdi
jb  .LBB2_1
retq

vmovdqu is the same length as vmovups, so there's no benefit.  But AFAIK, no
downside on any CPU to always using FP stores on the results of vector-integer
ALU instructions.

(There isn't a separate mnemonic for EVEX vmovups, so the assembler uses the
VEX encoding whenever it's encodeable that way.  Or maybe for medium-size
displacements that are multiples of the vector width, it can save a byte by
using an EVEX + disp8 instead of VEX + disp32.)

[Bug target/82369] "optimizes" indexed addressing back into two pointer increments

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
IV-opts is doing this.

But the cost must be for a reason.
Someone would need to understand why the x86 backend cost to handle this case.

It might be the case the cost is taking account the vector modes.

[Bug other/82368] [8 regression] with r253275 several new test cases in libbacktrace fail

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  ---
These are in effect the same failure as the earlier one (FAIL: backtrace_simple
noinline).  The new tests are the same code as the existing code, merely built
in a different way.  The way they are built does not affect the failure, so it
still fails.

It looks like backtrace_syminfo does not work on ppc64be.  The function is not
finding the symbol that corresponds to a PC.  As I recall on ppc64be function
symbol values point to a function descriptor, rather than to the code itself. 
If I'm remembering correctly, do you know what mechanisms there are to map from
the code address to the symbol?

[Bug target/82369] New: "optimizes" indexed addressing back into two pointer increments

[peter at cordes dot ca]

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

Bug ID: 82369
   Summary: "optimizes" indexed addressing back into two pointer
increments
   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 defeats this attempt to get it to reduce the front-end bottleneck in this
loop (simplified from a version of the loop in pr82356).

Indexing src by  (dst-src) + src  is easy to do in C, and works well.  But when
one pointer advances faster than the other it's very clunky to express in C.

#include 
#include 
#include 

// index src relative to dst, but use a pointer-increment for dst
// so the store still has a simple addressing mode (and can run on port7)
// gcc and clang "optimize" back to two separate pointers, but ICC13 leaves it
alone
// Saves one ADD instruction in the loop.
void pack_high8_indexed_src(uint8_t *restrict dst, const uint16_t *restrict
src, size_t bytes) {
  uintptr_t end_dst = (uintptr_t)(dst + bytes);
  uintptr_t srcu = (uintptr_t)src, dstu = (uintptr_t)dst;

  ptrdiff_t src_dst_offset = srcu - 2*dstu;
  do{
 __m128i v0 = _mm_loadu_si128((__m128i*)(dstu*2+src_dst_offset));
 __m128i v1 = _mm_loadu_si128((__m128i*)(dstu*2+src_dst_offset)+1);
 __m128i res = _mm_packus_epi16(v1,v0);

 _mm_storeu_si128((__m128i*)dstu, res);
 dstu += 16;
 //src += 16;  // 32 bytes
  } while(dstu < end_dst);
}

https://godbolt.org/g/pycLQC
gcc -O3 -mtune=skylake  de-optimizes it to this:

pack_high8_indexed_src:   # gcc and clang do this:
addq%rdi, %rdx
.L2:
movdqu  16(%rsi), %xmm0
movdqu  (%rsi), %xmm1
addq$16, %rdi
addq$32, %rsi# 2 separate pointer increments
packuswb%xmm1, %xmm0
movups  %xmm0, -16(%rdi)
cmpq%rdi, %rdx
ja  .L2
ret

Intel SnB-family: 7 fused-domain uops.  (The store micro-fuses, and the cmp/ja
macro-fuses).  In theory, this bottlenecks on front-end throughput (4 uops per
clock), running at 1 iter per 1.75 cycles.  The store uses a simple addressing
mode, so its store-address uop can run on port7.  If not for the front-end
bottleneck, the back-end could run this at nearly 1 per clock.

ICC13/16/17 compiles it the way I was hoping to hand-hold gcc into doing, to 6
fused-domain uops, and should run 1 iter per 1.5 clocks on SnB/HSW/SKL.  This
might also be good on Silvermont, since it's fewer instructions.

Possibly a similar benefit on K10 / BD (although AMD would benefit from using
simple array indexing, because indexed addressing modes for stores aren't worse
AFAIK.  But -mtune=bdver2 doesn't do that.)

pack_high8_indexed_src:   # ICC17
lea   (%rdi,%rdi), %rax
negq  %rax
addq  %rdi, %rdx
addq  %rax, %rsi
..B1.2:
movdqu16(%rsi,%rdi,2), %xmm1   # src indexed via dst*2
movdqu(%rsi,%rdi,2), %xmm0
packuswb  %xmm0, %xmm1
movdqu%xmm1, (%rdi)# dst with a simple
addressing mode.
addq  $16, %rdi# 16B of dst, 32B of src
cmpq  %rdx, %rdi
jb..B1.2
ret

A mov-load with a complex addressing mode is a single uop on all CPUs.  It
might have 1c higher latency than a simple addressing mode, but that doesn't
matter when the address math is off the critical path.

With unrolling, the actual work is only 4 fused-domain uops for 2x load + pack
+ store, so the front-end can just barely keep the back-end fed with infinite
unrolling.  For any sane unroll factor, saving 1 uop of loop overhead is a
slight win.

A store with an indexed addressing-mode can't run on port7 on Haswell/Skylake. 
With any unrolling, that would become a bottleneck.  On SnB/IvB, indexed stores
are un-laminated into 2 fused-domain uops, so simple array-indexing gets worse
with unrolling.


BTW, with an indexed store, we could count a negative index up towards zero. 
That would avoid the CMP, since the loop overhead could be just a single
macro-fused uop: add $16, %rdx / jnc.  (But only SnB-family macro-fuses
add/jcc.  AMD and Core2/Nehalem only macro-fuse test/cmp.)  But on a CPU that
doesn't macro-fuse at all, it's good.  (e.g. Silvermont / KNL).

---

BTW, with AVX, micro-fused loads are un-laminated on Haswell/Skylake.  e.g.

vmovdqu   16(%rsi,%rdi,2), %xmm0
vpackuswb (%rsi,%rdi,2), %xmm0, %xmm1
vmovdqu   %xmm1, (%rdi)

is 3 fused-domain uops in the decoders/uop cache, but its 4 fused-domain uops
for the issue/rename stage and in the ROB.  The vpackuswb un-laminates.

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
% svn diff resolve.c 
Index: resolve.c
===
--- resolve.c   (revision 253236)
+++ resolve.c   (working copy)
@@ -7387,8 +7387,14 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code, bo
   if (code->ext.alloc.ts.type == BT_CHARACTER && !e->ts.deferred
   && !UNLIMITED_POLY (e))
 {
-  int cmp = gfc_dep_compare_expr (e->ts.u.cl->length,
- code->ext.alloc.ts.u.cl->length);
+  int cmp;
+
+  if (!e->ts.u.cl->length)
+   goto failure;
+
+  cmp = gfc_dep_compare_expr (e->ts.u.cl->length,
+ code->ext.alloc.ts.u.cl->length);
+
   if (cmp == 1 || cmp == -1 || cmp == -3)
{
  gfc_error ("Allocating %s at %L with type-spec requires the same "

[Bug target/77480] netbsd specfile will not link against libc when building -shared (+patch)

[kristerw at gcc dot gnu.org]

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

Krister Walfridsson  changed:

   What|Removed |Added

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

--- Comment #4 from Krister Walfridsson  ---
Fixed for trunk and GCC 7.3.  Closing this bug as I'm not planning to backport
to GCC 6.

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
ICE confirmed from 4.8 up to trunk.

Compiling the test with my instrumented gfortran gives

../../work/gcc/fortran/dependency.c:321:11: runtime error: member access within
null pointer of type 'struct gfc_expr'
ASAN:DEADLYSIGNAL
=
==15952==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x0001003d484b bp 0x7fff5fbfe4b0 sp 0x7fff5fbfe490 T0)
==15952==The signal is caused by a READ memory access.
==15952==Hint: address points to the zero page.
#0 0x1003d484a in gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003d484a)
#1 0x100337829 in resolve_allocate_expr(gfc_expr*, gfc_code*, bool*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x100337829)
#2 0x10033f34d in resolve_allocate_deallocate(gfc_code*, char const*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10033f34d)
#3 0x1003535ee in gfc_resolve_code(gfc_code*, gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003535ee)
#4 0x100355d83 in resolve_codes(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x100355d83)
#5 0x100355b2b in resolve_codes(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x100355b2b)
#6 0x1002f42e1 in gfc_resolve(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1002f42e1)
#7 0x10029a2bf in gfc_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10029a2bf)
#8 0x1003f14f2 in gfc_be_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003f14f2)
#9 0x1045a4bac in compile_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1045a4bac)
#10 0x1045ad7fe in do_compile()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1045ad7fe)
#11 0x10651f30d in toplev::main(int, char**)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10651f30d)
#12 0x1065249ce in main
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1065249ce)
#13 0x7fffbcb65234 in start (/usr/lib/system/libdyld.dylib+0x5234)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003d484a)
in gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
8820864)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
f951: internal compiler error: Abort trap: 6


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug target/77480] netbsd specfile will not link against libc when building -shared (+patch)

[kristerw at gcc dot gnu.org]

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

--- Comment #3 from Krister Walfridsson  ---
Author: kristerw
Date: Fri Sep 29 21:34:00 2017
New Revision: 253309

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

Backport from mainline
2017-06-29  Maya Rashish  

PR target/77480
* config/netbsd.h (NETBSD_LIB_SPEC): Add -lc when creating shared
objects.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/netbsd.h

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
Thomas, the code generated by gcc has changed (after some patches by Jakub
IIRC). Do you consider the issue fixed or is the generated asm still
problematic?

.L13:
vpextrq $1, %xmm2, %rax
testq   %rax, %rax
je  .L2
vextractf128$0x1, %ymm2, %xmm2
vmovq   %xmm2, %rax
testq   %rax, %rax
jne .L2
vpextrq $1, %xmm2, %rax
vmovapd %ymm4, %ymm3
testq   %rax, %rax
jne .L2
.L3:
vmulpd  %ymm3, %ymm3, %ymm4
vmulpd  %ymm8, %ymm3, %ymm3
vsubpd  %ymm10, %ymm4, %ymm4
vmulpd  %ymm9, %ymm3, %ymm3
vaddpd  %ymm0, %ymm4, %ymm4
vaddpd  %ymm1, %ymm3, %ymm9
vaddpd  %ymm4, %ymm4, %ymm2
vmulpd  %ymm9, %ymm9, %ymm10
vaddpd  %ymm10, %ymm2, %ymm2
vcmpltpd%ymm7, %ymm2, %ymm2
vpaddq  %xmm2, %xmm5, %xmm3
vextractf128$1, %ymm2, %xmm6
vmovq   %xmm2, %rax
vextractf128$1, %ymm5, %xmm5
testq   %rax, %rax
vpaddq  %xmm6, %xmm5, %xmm5
vinsertf128 $0x1, %xmm5, %ymm3, %ymm5
jne .L13

[Bug other/82368] New: [8 regression] with r253275 several new test cases in libbacktrace fail

[seurer at gcc dot gnu.org]

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

Bug ID: 82368
   Summary: [8 regression] with r253275 several new test cases in
libbacktrace fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This is on powerpc64 BE.  There have been a few long time failures in here on
BE but with this revision there are some new failures.  Note that everything
including the new ones work fine on powerpc64 LE.

So after r235275:

make[1]: Entering directory
`/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libbacktrace'
PASS: backtrace_full noinline
PASS: backtrace_full inline
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
FAIL: backtrace_simple noinline
PASS: backtrace_simple inline
PASS: backtrace_syminfo variable
FAIL: btest
PASS: stest
PASS: inflate empty
PASS: inflate hello
PASS: inflate goodbye
PASS: inflate large
backtrace time: 1958740 ns
zlib time:: 1726764 ns
percentage: 0.881569
PASS: ztest
PASS: backtrace_full alloc stress
PASS: edtest
PASS: threaded backtrace_full noinline
PASS: ttest
PASS: backtrace_full noinline
PASS: backtrace_full inline
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
FAIL: backtrace_simple noinline
PASS: backtrace_simple inline
PASS: backtrace_syminfo variable
FAIL: ctestg
PASS: backtrace_full noinline
PASS: backtrace_full inline
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
FAIL: backtrace_simple noinline
PASS: backtrace_simple inline
PASS: backtrace_syminfo variable
FAIL: ctesta
===
3 of 7 tests failed
===

Previously it was like this:

make[1]: Entering directory
`/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libbacktrace'
PASS: backtrace_full noinline
PASS: backtrace_full inline
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
FAIL: backtrace_simple noinline
PASS: backtrace_simple inline
test5: unexpected syminfo name got elf_add expected global
FAIL: backtrace_syminfo variable
FAIL: btest
PASS: stest
PASS: backtrace_full alloc stress
PASS: edtest
PASS: threaded backtrace_full noinline
PASS: ttest
===
1 of 4 tests failed
===

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[w6ws at earthlink dot net]

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

--- Comment #1 from Walter Spector  ---
PGI and NAG both catch this error.  I can try Intel if needed.

[Bug fortran/82367] New: ICE with deferred length string allocate on non-deferred length argument

[w6ws at earthlink dot net]

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

Bug ID: 82367
   Summary: ICE with deferred length string allocate on
non-deferred length argument
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net
  Target Milestone: ---

Incorrect code caused a ICE:

wws@w6ws-4:/tmp$ cat cls.f90
module cls_allocmod
  implicit none

contains

 subroutine cls_alloc (n, str)
integer,  intent(in) :: n
character(*), allocatable, intent(out) :: str
!  Note: Star ^ should have been a colon (:)

allocate (character(n)::str)

  end subroutine

end module

program cls
  use cls_allocmod
  implicit none

  character(:), allocatable :: string

  call cls_alloc (42, string)
  print *, 'string len =', len(string)

end program
wws@w6ws-4:/tmp$ 

Gfortran 5.4 produces an ICE.  So do older versions (e.g., 4.8 on one of my
other machines.):

wws@w6ws-4:/tmp$ gfortran --version
GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

wws@w6ws-4:/tmp$ gfortran cls.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
wws@w6ws-4:/tmp$ 

The trunk as of a couple of days ago also produces an ICE - this time with a
compiler traceback:

wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran --version
GNU Fortran (GCC) 8.0.0 20170927 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran cls.f90
f951: internal compiler error: Segmentation fault
0xc906cf crash_signal
../../gcc-trunk/gcc/toplev.c:326
0x727af8 gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
../../gcc-trunk/gcc/fortran/dependency.c:321
0x6fe687 resolve_allocate_expr
../../gcc-trunk/gcc/fortran/resolve.c:7391
0x6fe687 resolve_allocate_deallocate
../../gcc-trunk/gcc/fortran/resolve.c:7782
0x70067a gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11212
0x701c02 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:16236
0x701b07 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:16221
0x701d06 gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:16271
0x6eb54c gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6217
0x7313af gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
wws@w6ws-4:/tmp$

[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Actually the gdb output does show the right libstdc++ is being used:

Reading symbols from /dvl/oms6/gcc-7.1.0/lib64/libstdc++.so.6...done.
Loaded symbols for /dvl/oms6/gcc-7.1.0/lib64/libstdc++.so.6

Try using _GLIBCXX_USE_CXX11_ABI=0 anyway, and see if that helps.

[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
It looks like the libstdc++.so.6 that the application links to is older than
the version you compiled against, and doesn't have support for the new
std::string type used in your callback.

It might work to build your code with the macro _GLIBCXX_USE_CXX11_ABI defined
to 0, but what you're trying to do (compile against a new libstdc++ then use an
older one at run-time) is not supported and cannot work in general.

[Bug c++/82299] -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

--- Comment #7 from Matt Godbolt  ---
Perfect! Thanks for clarifying, sorry for the confusion :)

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
{ target c++11 } means the test is run for -std=c++{11,14,17,2a,17 -fconcepts}.
And the test wants to make sure that the warning isn't emitted in any of those
modes.

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)

> Vlad, can you please have a look?  I'll still try to see if we can have a
> single file testcase here.

Yes, it seems as LRA rematerialization bug.  I'll work on it but the patch will
be ready only in a week.

[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436

[ygribov at gcc dot gnu.org]

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

--- Comment #8 from Yury Gribov  ---
Author: ygribov
Date: Fri Sep 29 19:40:16 2017
New Revision: 253307

URL: https://gcc.gnu.org/viewcvs?rev=253307=gcc=rev
Log:
2017-09-29  Yury Gribov  

PR middle-end/82319
gcc/
* match.pd: Fix handling of NaNs in pattern.

gcc/testsuite/
* c-c++/common/pr57371-4.c: Test NaN comparisons.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr57371-4.c

[Bug c++/82299] -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

--- Comment #5 from Matt Godbolt  ---
NB the proposed patch above has a test that compiles with -std=c++11 -- this
bug only occurs with std=c++1z, not 11. The fix may be right, but I wonder if
the test needs to be changed? Unless I've misread something.

[Bug libstdc++/82366] New: std::regex constructor called from shared library throws std::bad_cast

[spamdrop at fodvo dot org]

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

Bug ID: 82366
   Summary: std::regex constructor called from shared library
throws std::bad_cast
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spamdrop at fodvo dot org
  Target Milestone: ---

Created attachment 42265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42265=edit
Included source code to the callback function, the .ii file

I am writing a callback function in C++ that will be called from Oracle
GoldenGate via the User Exit Function API; hence I don't have the source to the
calling program.  The code is linked in as a share lib .so module.

My code (ggpost.cpp) in the attachment is about as simple a shared lib I can
create, all it does is create the following lines:

std::string test = "${foobar}";
std::smatch m;
std::regex e ("\\$\\{[a-zA-Z_]+[a-zA-Z0-9_]*}");
bool foo = std::regex_search(test, m, e);
std::cerr << "Foo = " << foo << endl;

When the code is compiled against 7.1.0, and run from Oracle GG, is creates the
following :
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast
Aborted (core dumped)

However, if I compile the same code in gcc 4.9.2, it works fine.  Also I have
attempted to construct my own calling program and I cannot duplicate the
problem with either compiler.

I have gathered as much detail as I can, but because it required OGG to
duplicate the full problem, I'm handicapped providing all the information
requested in the submission form.

CUsrText is my attempt to create a local parent program to duplicate the
problem, I include it, but it doesn't show the problem.

Below is the detailed writeup, and an attachment is included with the code I
can provide.
-
Compile machine
uname -r
2.6.32-642.15.1.el6.x86_64


gcc --version
gcc (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



configure lines:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ../gcc-7.1.0/configure --prefix=/dvl/odb/tools/gcc-7.1.0/

## - ##
## Platform. ##
## - ##

hostname = evdla176.delta.com
uname -m = x86_64
uname -r = 2.6.32-642.15.1.el6.x86_64
uname -s = Linux
uname -v = #1 SMP Mon Feb 20 02:26:38 EST 2017



Build of libggpost.so:
make
 g++ -save-temps -fPIC -g -ggdb -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -Wnon-virtual-dtor -ggdb
-D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -DTIXML_USE_STL -D_LINUX_
-fpermissive  -std=c++11   -I/. -I/usr/include/ -I/../../include
-I/home/b/bfoddy/odb5/dev/cc/snapshots/a26811_snap_linux.4/vobs/soc/include -c
ggpost.cpp -o ggpost.o 
evdla176:/home/b/bfoddy/odb5/dev/cc/snapshots/a26811_snap_linux.4/vobs/soc/ODB/goldengate
> g++  -fPIC -save-temps ggpost.o -o libggpost.so -shared

evdla176:/home/b/bfoddy/odb5/dev/cc/snapshots/a26811_snap_linux.4/vobs/soc/ODB/goldengate
> ll *.i*
-rw-r--r-- 1 545165 dtdev 1653968 Sep 29 18:04 ggpost.ii


ll libggpost.so
-rwxr-xr-x 1 545165 dtdev 1956286 Sep 29 18:05 libggpost.so

evdla176:/home/b/bfoddy/odb5/dev/cc/snapshots/a26811_snap_linux.4/vobs/soc/ODB/goldengate
> ldd libggpost.so
linux-vdso.so.1 =>  (0x7ffd4eff)
libstdc++.so.6 => /dvl/odb/tools/gcc-7.1.0/lib64/libstdc++.so.6
(0x7f4e72248000)
libm.so.6 => /lib64/libm.so.6 (0x7f4e71faf000)
libgcc_s.so.1 => /dvl/odb/tools/gcc-7.1.0/lib64/libgcc_s.so.1
(0x7f4e71d99000)
libc.so.6 => /lib64/libc.so.6 (0x7f4e71a05000)
/lib64/ld-linux-x86-64.so.2 (0x7f4e7287f000)

If I use my CUsrExitText program, no problem.   
./CUsrExitText 
Start , open DL
Open success.
Calling lib
Foo = 1

Now copy libggpost.so to runtime machine where Oracle GG installed.

from runtime machine:
uname -r
2.6.32-431.el6.x86_64


[omsd@evdla078 JMS_Adapter]$ ldd libggpost.so 
linux-vdso.so.1 =>  (0x7fff855ff000)
libstdc++.so.6 => /dvl/oms6/gcc-7.1.0/lib64/libstdc++.so.6
(0x7fc4dc023000)
libm.so.6 => /lib64/libm.so.6 (0x7fc4dbd8e000)
libgcc_s.so.1 => /dvl/oms6/gcc-7.1.0/lib64/libgcc_s.so.1
(0x7fc4dbb78000)
libc.so.6 => /lib64/libc.so.6 (0x7fc4db7e4000)
/lib64/ld-linux-x86-64.so.2 (0x7fc4dc65a000)


Now run the Oracle GG Extract program, which is configured to open libggpost.so
and call the function CUSEREXIT with EXIT_CALL_START as its first argument.

 ./extract PARAMFILE ./dirprm/foddyue.prm 

[Bug other/82365] New: excessive stack usage with norreturn attribute

[clyon at gcc dot gnu.org]

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

Bug ID: 82365
   Summary: excessive stack usage with norreturn attribute
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

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

We have noticed that gcc fails to reuse stack locations in presence of noreturn
attribute in the call graph.

Basically, the attached testcase has
case 1: { struct XXX localvar; bla1; break; }
case 2: { struct XXX localvar; bla2; break; }
case 3: { struct XXX localvar; bal3; break; }

With noreturn attribute:

aarch64-linux-gnu-gcc -Wall -O2 -S bz-3265.c --param asan-stack=1
-Wframe-larger-than=1 
bz-3265.c: In function ‘em28xx_dvb_init’:
bz-3265.c:99:1: warning: the frame size of 480 bytes is larger than 1 bytes
[-Wframe-larger-than=]


Without noreturn attribute:
aarch64-linux-gnu-gcc -Wall -O2 -S bz-3265.c --param asan-stack=1
-Wframe-larger-than=1 -DNONORETURN
bz-3265.c: In function ‘em28xx_dvb_init’:
bz-3265.c:99:1: warning: the frame size of 128 bytes is larger than 1 bytes
[-Wframe-larger-than=]


The code fragment is extracted from the linux kernel where this causes more
problems with using -fsanitize=kernel-address, where this causes excessive
stack usage.

I used an aarch64 compiler here, but Arnd observed similar problems on x86_64
too.

[Bug go/82131] FAIL: TestCgoCallbackGC in gotools testsuite; segfaults in morestack.S:529

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
I have not been able to create this.

Are you using GNU ld or the gold linker?  I've tried both and for me it works
either way, but it might help to know.


Can you find out why it is getting a segmentation violation on the call
instruction?  Is the problem that the stack pointer has become invalid?

[Bug c/82364] New: [7 Regression] Enormous memory usage when building on 32bit i386 with >= -O1

[bunk at stusta dot de]

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

Bug ID: 82364
   Summary: [7 Regression] Enormous memory usage when building on
32bit i386 with >= -O1
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bunk at stusta dot de
  Target Milestone: ---

Created attachment 42263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42263=edit
piglit-util-gl-enum-gen.i

piglit fails to build on 32bit i386 in Debian unstable, the problem is:

$ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O0
40364
$ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O1
54460
$ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O2
79688
$ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O3
79904
$ /usr/bin/time -f "%M" gcc-7 piglit-util-gl-enum-gen.i -c -O0
41732
$ /usr/bin/time -f "%M" gcc-7 piglit-util-gl-enum-gen.i -c -O1
679260
$ /usr/bin/time -f "%M" gcc-7 piglit-util-gl-enum-gen.i -c -O2

cc1: out of memory allocating 396567608 bytes after a total of 3083091968 bytes
Command exited with non-zero status 1
3476008
$ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i
-c -O0
42044
$ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i
-c -O1
51152
$ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i
-c -O2
83636
$ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i
-c -O3
83668
$ gcc-6 --version
gcc-6 (Debian 6.4.0-7) 6.4.0 20170920
...
$ gcc-7 --version
gcc-7 (Debian 7.2.0-7) 7.2.0
...
$ /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20170923-1) 8.0.0 20170923 (experimental) [trunk revision 253114]
...
$ 

7.2.0-7 is based on SVN 20170923 (r253114) from the gcc-7-branch.

Building on 64bit amd64 with -m32 has a normal memory usage (98 MB).

[Bug go/82348] make[4]: Circular runtime.lo <- bytes.gox dependency dropped.

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
My apologies for jumping to conclusions.

If you are building from trunk there should not be any references to
internal/cpu.gox.  What does your TARGET/libgo/math.lo.dep file look like?

[Bug go/82348] make[4]: Circular runtime.lo <- bytes.gox dependency dropped.

[mfe at live dot de]

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

--- Comment #3 from martin  ---
As suggested (in another bugreport) I built gcc from the gcc-trunk source
without any local modification. 

I compiled gcc from the following revision:

>gcc-trunk# svn info
>Path: .
>URL: svn://gcc.gnu.org/svn/gcc/trunk
>Repository Root: svn://gcc.gnu.org/svn/gcc
>Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
>Revision: 253004
>Node Kind: directory
>Schedule: normal
>Last Changed Author: jakub
>Last Changed Rev: 253004
>Last Changed Date: 2017-09-20 11:04:22 +0200 (Wed, 20 Sep 2017)

I also can ensure that I did not modify any local files of the gcc source
files, which I checked with `svn status`, or any other generated gcc build
files. 
Anyway, I understand your concerns, and I will proceed as you described.

[Bug tree-optimization/82363] New: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

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

This seems to be a recent regression. 

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


-


int printf (const char *, ...);

struct A
{ 
  int b;
  int c;
  int d;
};

struct E
{ 
  int f;
  int g:18;
  struct A h;
};

struct I
{ 
  int b;
  int j;
  struct E k;
};

int l, *m = 

struct A n;
struct I o;

int main ()
{ 
  while (1)
{ 
  struct I q = { 0, 0, {0, 0, {1, 1, 1}}}, p = q, r = p, *s = 
  if (p.k.h.c)
o = p;
  *m = r.k.h.d;
  n = (*s).k.h;
  break;
}
  printf ("%d\n", l);
  return 0;
}

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Sep 29 17:39:58 2017
New Revision: 253300

URL: https://gcc.gnu.org/viewcvs?rev=253300=gcc=rev
Log:
2017-09-29  Vladimir Makarov  

PR target/81481
* ira-costs.c (scan_one_insn): Don't take into account PIC equiv
with a symbol for LRA.

2017-09-29  Vladimir Makarov  

PR target/81481
* gcc.target/i386/pr81481.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr81481.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82338] valgrind error in inherit_in_ebb

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Sep 29 17:15:24 2017
New Revision: 253299

URL: https://gcc.gnu.org/viewcvs?rev=253299=gcc=rev
Log:
2017-09-29  Vladimir Makarov  

PR rtl-optimization/82338
* lra-constraints.c (inherit_in_ebb): Check usage_insns check.


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

[Bug fortran/82362] [8 Regression] SPEC CPU2006 436.cactusADM ~7% performance deviation with trunk@251713

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/82337] [5/6/7/8 Regression] ICE: SSA corruption at tree-ssa-coalesce.c:1010

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Fixed in trunk so far.  Backports to follow after a few days of burn-in.

[Bug tree-optimization/82337] [5/6/7/8 Regression] ICE: SSA corruption at tree-ssa-coalesce.c:1010

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Sep 29 14:55:14 2017
New Revision: 253293

URL: https://gcc.gnu.org/viewcvs?rev=253293=gcc=rev
Log:
[gcc]

2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gimple-ssa-strength-reduction.c (find_phi_def): Don't record a
phi definition if the PHI result appears in an abnormal PHI.
(find_basis_for_base_expr): Don't record a basis if the LHS of the
basis appears in an abnormal PHI.

[gcc]

2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gcc.c-torture/compile/pr82337.c: New file.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82337.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82361] Useless "mov eax, eax" in generated code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 42262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42262=edit
gcc8-pr82361-wip.patch

REE pass skips all instructions with multiple sets, but e.g. combiner doesn't.
With the following WIP patch the unnecessary zero extension is gone, similarly
for
unsigned long long foo (unsigned a, unsigned b) { return a / b; }
But I think a couple more are needed to also deal with signed division and the
various optimizations.

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #17 from Peter Bergner  ---
(In reply to Peter Bergner from comment #16)
> I have a patch that I am testing that fixes both new problems.

Patch for these two problems submitted here:

  https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01924.html

[Bug go/82208] exec_linux.go:197:27: error: reference to undefined name 'SYS_UNSHARE'

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
There is no reference to SYS_UNSHARE in libgo.  As best as I can tell, you are
using gccgo to compile the gc syscall package.  That can't work.

[Bug go/82348] make[4]: Circular runtime.lo <- bytes.gox dependency dropped.

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
OK, now I remember that you are doing some kind of complicated mix of the GCC 7
compiler and the mainline libgo, for reasons that I don't understand.

With respect, bugzilla is not the right place to report problems while doing
that.  Bugzilla is for bugs in the ordinary unmodified releases and mainline
compiler.  If you are moving things around, and something breaks, you are
responsible for figuring out whether you broke it or whether it was always
broken.  And if you file a report in Bugzilla anyhow, please always explain
exactly what you changed.  It's impossible for us to fix problems in sources
that have been modified in ways that we don't know about.

My time, like the time of all GCC developers, is very limited.  The time I
spend investigating bug reports in modified sources is time that I am not doing
useful work.  Please 1) use a release; or 2) use unmodified mainline; or 3)
figure out these problems yourself, perhaps using a mailing list, such as
gcc-h...@gcc.gnu.org or gofrontend-...@googlegroups.com.  If you use a mailing
list, please explain exactly what you are doing and why.  I can't promise that
anyone will help, but, in any case, please don't use bugzilla.

I'm sorry I can't be more helpful about this, but it's just not a productive
use of my limited time.

[Bug c++/82360] tree check fail in get_inner_reference, at expr.c:6996

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---

Here is a possibly better example, that is legal C++ code:

class a {};
template  class b {
  b(b &) : d(static_cast(c.d)) {}
  a d;
};

[Bug fortran/82362] New: [8 Regression] SPEC CPU2006 436.cactusADM ~7% performance deviation with trunk@251713

[alexander.nesterovskiy at intel dot com]

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

Bug ID: 82362
   Summary: [8 Regression] SPEC CPU2006 436.cactusADM ~7%
performance deviation with trunk@251713
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.nesterovskiy at intel dot com
  Target Milestone: ---

r251713 brings reasonable improvement to alloca. However there is a side effect
of this patch - 436.cactusADM performance became unstable when compiled with
-Ofast -march=core-avx2 -mfpmath=sse -funroll-loops
The impact is more noticeable when compiled with auto-parallelization
-ftree-parallelize-loops=N

Comparing performance for particular 7-runs
(relative to median performance of r251711):
r251711: 92,8%   92,9%   93,0%   106,7%  107,0%  107,0%  107,2%
r251713: 99,5%   99,6%   99,8%   100,0%  100,3%  100,6%  100,6%

r251711 is prettty stable, while r251713 is +7% faster on some runs and -7%
slower on other.

There are few dynamic arrays in the body of Bench_StaggeredLeapfrog2 sub in
StaggeredLeapfrog2.fppized.f.
When compiled with "-fstack-arrays" (default for "-Ofast") arrays are allocated
by alloca.
Allocated memory size is rounded-up to 16-bytes in r251713 with code like "size
= (size + 15) & -16".
In prior revisions it differs in just one byte: "size = (size + 22) & -16"
Which actually may just waste extra 16 bytes for each array depending on
initial "size" value.

Actual r251713 code, built with
gfortran -S -masm=intel -o StaggeredLeapfrog2.fppized_r251713.s
-O3 -fstack-arrays -march=core-avx2 -mfpmath=sse -funroll-loops
-ftree-parallelize-loops=8 StaggeredLeapfrog2.fppized.f

lea rax, [15+r13*8] ; size = <...> + 15
shr rax, 4  ; zero-out
sal rax, 4  ; lower 4 bits
sub rsp, rax
mov QWORD PTR [rbp-4984], rsp   ; Array 1
sub rsp, rax
mov QWORD PTR [rbp-4448], rsp   ; Array 2
sub rsp, rax 
mov QWORD PTR [rbp-4784], rsp   ; Array 3 ... and so on


Aligning rsp to cache line size (on each allocation or even once in the
beginning) brings performance to stable high values:

lea rax, [15+r13*8] 
shr rax, 4
sal rax, 4
shr rsp, 6  ; Align rsp to
shl rsp, 6  ; 64-byte border
sub rsp, rax
mov QWORD PTR [rbp-4984], rsp
sub rsp, rax
mov QWORD PTR [rbp-4448], rsp
sub rsp, rax 
mov QWORD PTR [rbp-4784], rsp


64-byte aligned version performance
compared to the same median performance of r251711:
106,7%  107,0%  107,0%  107,1%  107,1%  107,2%  107,4%

Maybe what is necessary here is some kind of option to force array aligning for
gfortran (like "-align array64byte" for ifort) ?

[Bug go/82348] make[4]: Circular runtime.lo <- bytes.gox dependency dropped.

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
There is no internal/cpu.gox file in GCC 7, so something strange is going on. 
On current mainline internal/cpu exists, but the Makefile does not build it. 
You must have modified the libgo sources in some way.

> I would like to ask, whether gcc-compiled/gcc/gccgo is the final go compiler 
> or it is previous generated compiler from bootstrapping.

I'm not sure I understand the question, but by the time libgo is being built,
gccgo is the final Go compiler driver.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #28 from Dominique d'Humieres  ---
Closing.

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at gcc dot gnu.org]

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

--- Comment #27 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Sep 29 13:19:21 2017
New Revision: 253287

URL: https://gcc.gnu.org/viewcvs?rev=253287=gcc=rev
Log:
2017-09-29  Dominique d'Humieres  

PR fortran/25071
* gfortran.dg/argument_checking_3.f90: Change warnings to errors.
* gfortran.dg/argument_checking_4.f90: Likewise.
* gfortran.dg/argument_checking_5.f90: Likewise.
* gfortran.dg/argument_checking_6.f90: Likewise.
* gfortran.dg/argument_checking_10.f90: Likewise.
* gfortran.dg/argument_checking_13.f90: Likewise.
* gfortran.dg/argument_checking_15.f90: Likewise.
* gfortran.dg/argument_checking_18.f90: Likewise.
* gfortran.dg/gomp/udr8.f90: Likewise.
* gfortran.dg/warn_argument_mismatch_1.f90: Add -std=legacy to
the dg-options.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/argument_checking_10.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_13.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_15.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_18.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_3.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_4.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_5.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_6.f90
trunk/gcc/testsuite/gfortran.dg/gomp/udr8.f90
trunk/gcc/testsuite/gfortran.dg/warn_argument_mismatch_1.f90

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
It was actually r240449

Implement P0138R2, C++17 construction rules for enum class values
* cp-tree.h (is_direct_enum_init): Declare.
* decl.c (is_direct_enum_init): New function.
(reshape_init): Use it.
* typeck.c (convert_for_assignment): Likewise.

* g++.dg/cpp1z/direct-enum-init1.C: New test.

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at gcc dot gnu.org]

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

--- Comment #26 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Sep 29 13:15:26 2017
New Revision: 253286

URL: https://gcc.gnu.org/viewcvs?rev=253286=gcc=rev
Log:
2017-09-29  Dominique d'Humieres  

PR fortran/25071
* interface.c (compare_actual_formal): Change warnings to errors
when "Actual argument contains too few elements for dummy
argument", unless -std=legacy is used.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c

[Bug c++/82361] Useless "mov eax, eax" in generated code

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
The ree pass skips

(insn 31 30 10 2 (parallel [
(set (reg:SI 0 ax [95])
(udiv:SI (reg/v:SI 0 ax [orig:93 a ] [93])
(reg/v:SI 4 si [orig:94 b ] [94])))
(set (reg:SI 1 dx [96])
(umod:SI (reg/v:SI 0 ax [orig:93 a ] [93])
(reg/v:SI 4 si [orig:94 b ] [94])))
(use (reg:SI 1 dx [96]))
(clobber (reg:CC 17 flags))
]) 374 {*udivmodsi4_noext}
 (nil))

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

[doko at gcc dot gnu.org]

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

--- Comment #5 from Matthias Klose  ---
still searching ...

/usr/lib/gcc/i686-linux-gnu/7/include/stddef.h:20440:11: internal compiler
error: in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429
0x8858876 equal_mem_array_ref_p
../../src/gcc/tree-ssa-scopedtables.c:429
0x8858876 hashable_expr_equal_p
../../src/gcc/tree-ssa-scopedtables.c:466
0x8858876 expr_elt_hasher::equal(expr_hash_elt* const&, expr_hash_elt* const&)
../../src/gcc/tree-ssa-scopedtables.c:916
0x885983d hash_table::find_slot_with_hash(expr_hash_elt* const&, unsigned int,
insert_option)
../../src/gcc/hash-table.h:889
0x88591a8 hash_table::find_slot(expr_hash_elt*
const&, insert_option)
../../src/gcc/hash-table.h:414
0x88591a8 avail_exprs_stack::lookup_avail_expr(gimple*, bool, bool)
../../src/gcc/tree-ssa-scopedtables.c:156
0x887d01a record_temporary_equivalences_from_stmts_at_dest
../../src/gcc/tree-ssa-threadedge.c:336
0x887d6ee thread_through_normal_block
../../src/gcc/tree-ssa-threadedge.c:994
0x887f0ac thread_across_edge
../../src/gcc/tree-ssa-threadedge.c:1229
0x887f49b thread_outgoing_edges(basic_block_def*, gcond*, const_and_copies*,
avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*,
basic_block_def*))
../../src/gcc/tree-ssa-threadedge.c:1289
0x87d2cf8 dom_opt_dom_walker::after_dom_children(basic_block_def*)
../../src/gcc/tree-ssa-dom.c:1206
0x8ce5d6b dom_walker::walk(basic_block_def*)
../../src/gcc/domwalk.c:307
0x87d52d3 execute
../../src/gcc/tree-ssa-dom.c:459
Please submit a full bug report,
with preprocessed source if appropriate.

these are distro packages, and apparently only seen with a toolchain defaulting
to hardening defaults.

[Bug c++/82360] tree check fail in get_inner_reference, at expr.c:6996

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---

I don't think this is still C++ code, but it 
does seem to provoke the error:

class a {
} template  class c {  c(c &) : (static_cast a && e.d;  a
d

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Looking into it.

[Bug c++/82361] New: Useless "mov eax, eax" in generated code

[antoshkka at gmail dot com]

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

Bug ID: 82361
   Summary: Useless "mov eax, eax" in generated code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following function

struct ret_t {
unsigned quot, rem;
};

ret_t my_div(unsigned a, unsigned b) {
return {a / b, a % b};
}


Produces suboptimal assembly:

my_div(unsigned int, unsigned int):
  mov eax, edi
  xor edx, edx
  div esi
  sal rdx, 32
  mov eax, eax  # <==
  or rax, rdx
  ret

Clang produces an assembly without "mov eax, eax" instead:

my_div(unsigned int, unsigned int): # @my_div(unsigned int, unsigned int)
  xor edx, edx
  mov eax, edi
  div esi
  shl rdx, 32
  or rax, rdx
  ret

[Bug preprocessor/82359] #line does not allow C++14 quotes in number

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops, that wasn't very clear. Digit-separators are not a defect (although that
depends who you ask). But the fact that the #line directive allows them is a
defect.

[Bug preprocessor/82359] #line does not allow C++14 quotes in number

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Andrew Schepler from comment #0)
> In C++14 and later, any integer literal may contain single quote characters
> (aka apostrophe, ASCII 0x27).

That's a standard defect (and has already been raised as such on the committee
reflector).

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

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
> at expansion time (the reason for that is that sanopt pass doesn't perform
> the optimization of redundant pointer overflow checks yet (Martin, do you
> have it still on your todo list or shall I have a look?)).

Yes I have, just finishing switch expansion and will return to that hopefully
next week.

Martin

[Bug c++/82360] New: tree check fail in get_inner_reference, at expr.c:6996

[dcb314 at hotmail dot com]

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

Bug ID: 82360
   Summary: tree check fail in get_inner_reference, at expr.c:6996
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 42260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42260=edit
gzipped C++ source code

The attached c++ code, when compiled by today's trunk gcc, does this:

/usr/include/boost/smart_ptr/weak_ptr.hpp:109:82: internal compiler error: tree 
check: expected tree that contains ‘decl common’ structure, have
‘identifier_nod
e’ in get_inner_reference, at expr.c:6996
 BOOST_NOEXCEPT : px( r.px ), pn( static_cast< boost::detail::weak_count && 
>( r.pn ) )

The problem seems to exist between versions 253249 and 253276.

I'll have a go at reducing the code.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Confirmed, but it is actually a RTL optimization bug, not a problem with the
sanitization.
We have:
(insn 202 201 203 29 (set (reg:DI 98 [ _12 ])
(symbol_ref:DI ("tf_2_struct_obj_2") [flags 0x40] )) "pr82353-2.C":19 -1
 (nil))
(insn 203 202 204 29 (parallel [
(set (reg:DI 143 [ _60 ])
(plus:DI (reg:DI 98 [ _12 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "pr82353-2.C":19 -1
 (nil))
(insn 204 203 205 29 (set (reg:CC 17 flags)
(compare:CC (reg:DI 98 [ _12 ])
(const_int -16 [0xfff0]))) "pr82353-2.C":19 -1
 (nil))
(jump_insn 205 204 206 29 (set (pc)
(if_then_else (ltu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref 212)
(pc))) "pr82353-2.C":19 -1
 (int_list:REG_BR_PROB 39986 (nil))
 -> 212)
...
(code_label 212 211 213 31 22 (nil) [1 uses])
(note 213 212 214 31 [bb 31] NOTE_INSN_BASIC_BLOCK)
(insn 214 213 215 31 (set (mem/c:SI (symbol_ref:DI ("tf_2_var_233") [flags
0x40] ) [9 tf_2_var_233+0 S4 A32])
(reg:SI 92 [ _6 ])) "pr82353-2.C":19 -1
 (nil))
(insn 215 214 216 31 (set (reg:DI 114 [ _29 ])
(symbol_ref:DI ("tf_2_struct_obj_2") [flags 0x40] )) "pr82353-2.C":20 -1
 (nil))
(insn 216 215 217 31 (parallel [
(set (reg:DI 118 [ _33 ])
(plus:DI (reg:DI 114 [ _29 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "pr82353-2.C":20 -1
 (nil))
(insn 217 216 218 31 (set (reg:CC 17 flags)
(compare:CC (reg:DI 114 [ _29 ])
(const_int -16 [0xfff0]))) "pr82353-2.C":20 -1
 (nil))
(jump_insn 218 217 219 31 (set (pc)
(if_then_else (ltu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref 225)
(pc))) "pr82353-2.C":20 -1
 (int_list:REG_BR_PROB 39986 (nil))
 -> 225)

at expansion time (the reason for that is that sanopt pass doesn't perform the
optimization of redundant pointer overflow checks yet (Martin, do you have it
still on your todo list or shall I have a look?)).
Then fwprop1 figures out that insn 215 and 216 are redundant and removes them.
Then cse2 figures out the insn 217 is redundant and removes it.
This is still valid, there is a comparison that sets flags, then conditional
jump to code_label 212 (fallthrough into __ubsan_pointer_overflow_abort call),
there the store in insn 214 followed by a conditional jump which uses the still
computed flags, though of course if we were smarter we could have changed it
into unconditional jump at that point.
*.ira still looks correct, but then something in LRA isn't aware that the flags
register is live on the edge from bb29 to bb31 and inside of bb31 until
jump_insn 218, and rematerializes? there pseudo 92 which is stored in insn 214
and we end up with invalid:
(code_label 212 211 213 33 22 (nil) [1 uses])
(note 213 212 470 33 [bb 33] NOTE_INSN_BASIC_BLOCK)
(insn 470 213 466 33 (parallel [
(set (reg:SI 0 ax [orig:92 _6 ] [92])
(mult:SI (reg:SI 40 r11 [orig:91 _5 ] [91])
(const_int 89 [0x59])))
(clobber (reg:CC 17 flags))
]) "pr82353-2.C":19 328 {*mulsi3_1}
 (nil))
(note 466 470 214 33 NOTE_INSN_DELETED)
(insn 214 466 218 33 (set (mem/c:SI (symbol_ref:DI ("tf_2_var_233") [flags
0x40] ) [9 tf_2_var_233+0 S4 A32])
(reg:SI 0 ax [orig:92 _6 ] [92])) "pr82353-2.C":19 82 {*movsi_internal}
 (nil))
(jump_insn 218 214 219 33 (set (pc)
(if_then_else (ltu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref 225)
(pc))) "pr82353-2.C":20 632 {*jcc_1}
 (int_list:REG_BR_PROB 39986 (nil))
 -> 225)
where the multiplication clobbers the flags and then we use them in insn 218.

Vlad, can you please have a look?  I'll still try to see if we can have a
single file testcase here.

[Bug preprocessor/64965] __FILE__ doesn't work if the filename contains newline

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Rasmus Villemoes from comment #1)
> Created attachment 34693 [details]
> Make __FILE__ work for filenames containing newline

Please post this patch to gcc-patc...@gcc.gnu.org for review - thanks!

https://gcc.gnu.org/contribute.html#patches

[Bug preprocessor/64965] __FILE__ doesn't work if the filename contains newline

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Andrew, if you write PR 66317 or Bug 66317 (or variations like Bug
preprocessor/66317) then Bugzilla automatically makes it a hyperlink :-)

Reproducer from that bug:

Test case (a 2 line source file named "filename_bug.c"):
#line 1 "new\nline.c"
const char filename[] = __FILE__;

Output of "cpp filename_bug.c" (there is no newline on the last line of
output):
# 1 "filename_bug.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "filename_bug.c"
# 1 "new
line.c"
new
line.c:1:1: warning: missing terminating " character
new
line.c:1:25: internal compiler error: invalid built-in macro "__FILE__"
...

Also https://bugs.debian.org/838874

[Bug preprocessor/66317] Preprocessor chokes on __FILE__ containing a newline

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
.

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

[Bug preprocessor/64965] __FILE__ doesn't work if the filename contains newline

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||Keith.S.Thompson at gmail dot 
com

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

[Bug preprocessor/82359] New: #line does not allow C++14 quotes in number

[aschepler at gmail dot com]

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

Bug ID: 82359
   Summary: #line does not allow C++14 quotes in number
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aschepler at gmail dot com
  Target Milestone: ---

In C++14 and later, any integer literal may contain single quote characters
(aka apostrophe, ASCII 0x27).  But the #line preprocessing directive does not
allow it.

For example,
#line 1'000
results in:
error: "1'000" after #line is not a positive integer

The relevant grammar is found in [cpp], [cpp.line], and [lex.fcon]:

control-line:
...
# line pp-tokens new-line
...

digit-sequence:
digit
digit-sequence '_opt digit

where a line directive after macro substitution must have one of the two forms

# line digit-sequence new-line
# line digit-sequence " s-char-sequence_opt " new-line

The #if directive seems to have no problems with quote characters in numbers,
though.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |MOVED

--- Comment #23 from Jonathan Wakely  ---
I think MOVED is more appropriate, as it's handled at
https://sourceware.org/bugzilla/show_bug.cgi?id=0

[Bug preprocessor/64965] __FILE__ doesn't work if the filename contains newline

[aschepler at gmail dot com]

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

Andrew Schepler  changed:

   What|Removed |Added

 CC||aschepler at gmail dot com

--- Comment #4 from Andrew Schepler  ---
Duplicated by 66317.

[Bug tree-optimization/82355] [8 Regression] ICE in outermost_loop_in_sese, at sese.c:301

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I somehow knew you'd come up with infinite loop testcases ;)

This is because of

static inline bool
bb_in_region (const_basic_block bb, const_basic_block entry, const_basic_block
exit)
{
  return dominated_by_p (CDI_DOMINATORS, bb, entry)
 && !(dominated_by_p (CDI_DOMINATORS, bb, exit)
  && !dominated_by_p (CDI_DOMINATORS, entry, exit));
}

and when the exit of the SESE region is the latch edge then indeed the loop
doesn't belong to the region.  An infinite loop doesn't have an exit after
all ...

I'm not quite sure we shouldn't make it have an exit by means of a fake edge
but that would probably fix the ICE.

The reason for the strange region is merge_sese being overly "clever".

I have a patch in testing that avoids asking outermost_loop_in_sese for this
case.

[Bug target/82358] New: [8 regression] i386/stack-check-11.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 82358
   Summary: [8 regression] i386/stack-check-11.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r252999 triggers this fail:

FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times subq 4

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm

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

[kristerw at gcc dot gnu.org]

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

--- Comment #14 from Krister Walfridsson  ---
Author: kristerw
Date: Fri Sep 29 09:38:08 2017
New Revision: 253283

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

Backport from mainline
2017-09-26  Krister Walfridsson  

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

Added:
branches/gcc-7-branch/gcc/config/netbsd-protos.h
branches/gcc-7-branch/gcc/config/netbsd.c
branches/gcc-7-branch/gcc/config/t-netbsd
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config.gcc
branches/gcc-7-branch/gcc/config/netbsd.h

[Bug rtl-optimization/82356] auto-vectorizing pack of 16->8 has a redundant AND after a shift

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-29
  Component|tree-optimization   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The vectorizer itself just emits

   [81.00%]:
  # ivtmp.30_143 = PHI <0(12), ivtmp.30_144(13)>
  # ivtmp.35_145 = PHI <0(12), ivtmp.35_146(13)>
  vect__1.15_75 = MEM[base: vectp_src.14_71, index: ivtmp.35_145, step: 2,
offset: 0B];
  vect__1.16_77 = MEM[base: vectp_src.14_71, index: ivtmp.35_145, step: 2,
offset: 16B];
  vect__2.17_78 = vect__1.15_75 >> 8;
  vect__2.17_79 = vect__1.16_77 >> 8;
  vect__3.18_80 = VEC_PACK_TRUNC_EXPR ;
  MEM[base: vectp_dst.20_81, index: ivtmp.35_145, offset: 0B] = vect__3.18_80;
  ivtmp.30_144 = ivtmp.30_143 + 1;
  ivtmp.35_146 = ivtmp.35_145 + 16;
  if (bnd.9_65 > ivtmp.30_144)
goto ; [83.34%]

it seems the ands come from VEC_PAC_TRUNC_EXPR expansion somehow.

(insn 150 149 151 (set (reg:V8HI 219)
(and:V8HI (reg:V8HI 221)
(reg:V8HI 214 [ vect__2.17 ]))) "t.c":5 -1
 (nil))

(insn 151 150 152 (set (reg:V8HI 220)
(and:V8HI (reg:V8HI 221)
(reg:V8HI 216 [ vect__2.17 ]))) "t.c":5 -1
 (nil))

(insn 152 151 153 (set (reg:V16QI 218 [ vect__3.18 ])
(vec_concat:V16QI (us_truncate:V8QI (reg:V8HI 219))
(us_truncate:V8QI (reg:V8HI 220 "t.c":5 -1
 (nil))

and combine / simplify-rtx are not able to remove them again (no wonders,
simplify-rtx is notoriously unaware of vectors).

[Bug target/82344] [8 Regression] SPEC CPU2006 435.gromacs ~10% performance regression with trunk@250855

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/82357] [8 Regression] bogus error: cannot bind bitfield

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0

[Bug tree-optimization/82355] [8 Regression] ICE in outermost_loop_in_sese, at sese.c:301

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-29
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug rtl-optimization/82338] valgrind error in inherit_in_ebb

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug other/82352] [7/8 Regression] comdat-local function called by void h::i() outside its comdat

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-29
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |7.3
Summary|link error 'defined in  |[7/8 Regression]
   |discarded section'  |comdat-local function
   ||called by void h::i()
   ||outside its comdat
 Ever confirmed|0   |1

[Bug other/82352] link error 'defined in discarded section'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Created attachment 42259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42259=edit
Reduced single compilation unit test-case

Confirmed, following ICEs in GCC (with -fchecking):

g++-7 pr82352-2.cpp -O2 -c -fchecking
pr82352-2.cpp:42:7: warning: direct base ‘B’ inaccessible in ‘o’ due to
ambiguity
 class o : B, n
   ^
pr82352-2.cpp:51:1: error: comdat-local function called by void h::i() outside
its comdat
 }
 ^
_ZN1fI1oE1dEv.part.0/38 (void f::d() [with e = o]) @0x149a95bd5450
  Type: function definition analyzed
  Visibility: comdat_group:_ZN1fI1oE1dEv artificial
  Same comdat group as: _ZN1fI1oE1dEv/26
  References: _ZTI1a/24 (addr)
  Referring: 
  Availability: local
  First run: 1
  Function flags: body local icf_merged split_part unlikely_executed
  Called by: _ZN1h1iEv.part.1/39 (1.00 per call) (can throw external)
_ZN1fI1oE1dEv/26 (can throw external) 
  Calls: __cxa_allocate_exception/31 (1.00 per call) __cxa_throw/32 (1.00 per
call) (can throw external) 
pr82352-2.cpp:51: confused by earlier errors, bailing out

Caused by my commit r246848.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-29
   Target Milestone|--- |8.0
Summary|runtime ubsan crash |[8 Regression] runtime
   ||ubsan crash
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color

[jhasse at bixense dot com]

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

--- Comment #2 from Jan Niklas Hasse  ---
I guess that's because one doesn't want the build output to depend on an
environment variable (most build systems won't rebuild on env variable
changes)?

-fdiagnostics-color doesn't affect the build output, therefore it would be a
perfect fit for an env variable. Currently adding it causes an unnecessary full
rebuild.

[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

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

--- Comment #22 from Martin Liška  ---
(In reply to Gubbins from comment #21)
> (In reply to Martin Liška from comment #20)
> > Your failure happens even w/o LTO, am I right?
> > But yes, the problem looks very similar to what happens for ld.bfd.
> 
> You are right.
> 
> Does anyone know how I would raise this with someone who can fix it on the
> Darwin side? Or could it be worked around by gcc?

Linker should provide precise information to GCC.
The bug is fixed in binutils, I'm closing this.

[Bug c/82340] volatile ignored in compound literal

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 29 07:35:37 2017
New Revision: 253280

URL: https://gcc.gnu.org/viewcvs?rev=253280=gcc=rev
Log:
PR c/82340
* c-decl.c (build_compound_literal): Use c_apply_type_quals_to_decl
instead of trying to set just TREE_READONLY manually.

* gcc.dg/tree-ssa/pr82340.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82340.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82339] Inefficient movabs instruction

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 29 07:20:09 2017
New Revision: 253279

URL: https://gcc.gnu.org/viewcvs?rev=253279=gcc=rev
Log:
PR target/82339
* config/i386/i386.md (*movdi_internal peephole2): New -Os peephole
for movabsq $(i32 << shift), r64.

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

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter  ---
Interestingly, I get the problem only with Xcode 9.0 and MAC OS X Sierra Darwin
16.6, but not with Xcode 9.0 and Mac OS X High Sierra Darwin 16.7.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Started with r240498 apparently, although it doesn't look relevant:

* ipa-inline-analysis.c (find_foldable_builtin_expect): Use
gimple_call_internal_p.
* ipa-split.c (find_return_bb): Likewise.
(execute_split_functions): Likewise.
* omp-low.c (dump_oacc_loop_part): Likewise.
(oacc_loop_xform_head_tail): Likewise.
* predict.c (predict_loops): Likewise.
* sanopt.c (pass_sanopt::execute): Likewise.
* tree-cfg.c (get_abnormal_succ_dispatcher): Likewise.
* tree-parloops.c (oacc_entry_exit_ok_1): Likewise.
* tree-stdarg.c (gimple_call_ifn_va_arg_p): Remove function.
(expand_ifn_va_arg_1): Use gimple_call_internal_p.
(expand_ifn_va_arg): Likewise.
* tree-vect-loop.c (vect_determine_vectorization_factor): Likewise.
(optimize_mask_stores): Likewise.
* tree-vect-stmts.c (vect_simd_lane_linear): Likewise.
(vect_transform_stmt): Likewise.
* tree-vectorizer.c (vect_loop_vectorized_call): Likewise.
* tsan.c (instrument_memory_accesses): Likewise.

[Bug c++/82357] [8 Regression] bogus error: cannot bind bitfield

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r253266:

commit 4cedc476c94a41551d965bc57fbbe0186983c3c4
Author: jason 
Date:   Thu Sep 28 19:39:45 2017 +

PR c++/56973, DR 696 - capture constant variables only as needed.

[Bug c++/82357] New: [8 Regression] bogus error: cannot bind bitfield

[trippels at gcc dot gnu.org]

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

Bug ID: 82357
   Summary: [8 Regression] bogus error: cannot bind bitfield
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

% < api.ii
template  struct A {
  A() { x |= 0; }
  int x : 8;
};

 % g++ -c api.ii
api.ii: In constructor ‘A<  >::A()’:
api.ii:2:14: error: cannot bind bitfield ‘((A< 
>*)this)->A<  >::x’ to ‘int&’
   A() { x |= 0; }
  ^