[Bug target/87221] cannot build with -pie

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is related to bug 81523.  How did you configure GCC?

[Bug c++/66968] Incorrect template argument shown in diagnostic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug ipa/60243] IPA is slow on large cgraph tree

[egallager at gcc dot gnu.org]

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

--- Comment #23 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #22)
> > The IPA SRA time is all spent in compute_fn_summary via convert_callers.
> > Not sure why that's necessary here?  Martin, in r152368 you reduced those
> > to once-per-caller but obviously if each function calls each other function
> > as in this testcase this is still O(n^2).  Why's the summary not simply
> > recomputed when we process the caller next?  Thus at most N times?
> 
> This is because summary needs to be ready for early inliner to decide whether
> caller is good for inlning or not.  I think we can simply mark it as dirty
> and
> compute on demand from the inliner.
> 
> I also have finally working patches for incremental update of inline summary
> in
> the IPA inliner.
> 

Cool, looking forward to seeing those patches!

[Bug c/87221] New: cannot build with -pie

[coypu at sdf dot org]

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

Bug ID: 87221
   Summary: cannot build with -pie
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

With any example code,

> /usr/local/bin/gcc -pie -fpie test2.c
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtbegin.o:
relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when
making a shared object
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtend.o:
relocation R_X86_64_32 against `.ctors' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status




The following patch seems to help, but I don't know why the problem doesn't
affect more people:

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 84738e76eaa..4906034555f 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -297,7 +297,7 @@ INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS)
$(HOST_LIBGCC2_CFLAGS) \
 CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
   $(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \
   -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
-  -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
+  -fbuilding-libgcc -fPIC -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
   $(INHIBIT_LIBC_CFLAGS)

 # Extra flags to use when compiling crt{begin,end}.o.

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Gallager  ---
Iain confirmed this on IRC for darwin

[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
Fixed for GCC 9 so far.

[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272

[hjl at gcc dot gnu.org]

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

--- Comment #11 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Sep  4 20:42:06 2018
New Revision: 264096

URL: https://gcc.gnu.org/viewcvs?rev=264096=gcc=rev
Log:
DWARF: Allow hard frame pointer even if frame pointer isn't used

r251028

commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
Author: hjl 
Date:   Thu Aug 10 15:29:05 2017 +

i386: Don't use frame pointer without stack access

When there is no stack access, there is no need to use frame pointer
even if -fno-omit-frame-pointer is used and caller's frame pointer is
unchanged.

frame pointer may not be available even if -fno-omit-frame-pointer is
used.  When this happened, arg pointer may be eliminated by hard frame
pointer.  Since hard frame pointer is encoded with DW_OP_fbreg which
uses the DW_AT_frame_base attribute, not hard frame pointer directly,
we should allow hard frame pointer when generating DWARF info even if
frame pointer isn't used.

gcc/

PR debug/86593
* dwarf2out.c (based_loc_descr): Allow hard frame pointer even
if frame pointer isn't used.
(compute_frame_pointer_to_fb_displacement): Likewise.

gcc/testsuite/

PR debug/86593
* g++.dg/pr86593.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr86593.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug other/87220] -fstack-check produces inefficient and wrong tests

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
-fstack-clash-protection works as desired.

Based on the documentation:

"Most targets do not fully support stack clash protection. However, on those
targets -fstack-clash-protection will protect dynamic stack allocations.
-fstack-clash-protection may also provide limited protection for static stack
allocations if the target supports -fstack-check=specific. "

I understood that -fstack-check would still be needed to get reliable
protection on all targets. Perhaps that's wrong. Is there a recommended
approach for determining at build time the right options for the target to
ensure that code which jumps over the guard page is not generated?

[Bug other/87220] -fstack-check produces inefficient and wrong tests

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
What does -fstack-clash-protection give?  (-fstack-check is an old option 
for specific Ada requirements; for proper stack-clash protection for all 
languages you want -fstack-clash-protection instead.)

[Bug other/87220] New: -fstack-check produces inefficient and wrong tests

[bugdal at aerifal dot cx]

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

Bug ID: 87220
   Summary: -fstack-check produces inefficient and wrong tests
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Given the test case:

void bar(void *);
int foo()
{
char a[10];
bar();
}

-fstack-check produces the code (x86_64; similar for 32-bit):

foo:
subq$4152, %rsp
orq $0, (%rsp)
addq$4128, %rsp
leaq6(%rsp), %rdi
callbar
addq$24, %rsp
ret

This test:
1. Unnecessarily touches an extra page of stack that's not used, wasting
memory.
2. Skips over a whole page, potentially clobbering (data race) data on the
other side of a guard page.
3. Is completely unnecessary; since less than a page of stack is needed, only a
probe of the final desired stack pointer (after the third instruction) is
needed, and it's performed implicitly by the call.

I would expect at least:

foo:
subq$24, %rsp
orq $0, (%rsp)
leaq6(%rsp), %rdi
callbar
addq$24, %rsp
ret

or ideally:

foo:
subq$24, %rsp
leaq6(%rsp), %rdi
callbar
addq$24, %rsp
ret

The excessive stack usage, unsafety (jumping the guard page), and size and
potential performance hit from unnecessary checks seem to make -fstack-check
unsuitable for its intended purpose at this time.

[Bug tree-optimization/87205] Inefficient code generation for switch

[pdimov at gmail dot com]

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

--- Comment #9 from Peter Dimov  ---
For more context, see https://godbolt.org/z/SzfpKr

```
#include 

template struct variant
{
std::aligned_union_t<0, T...> storage_;
unsigned index_;
};

template
auto visit( variant& v, F f )
{
switch( v.index_ )
{
case 0: return f( (T0&)v.storage_ );
case 1: return f( (T1&)v.storage_ );
case 2: return f( (T2&)v.storage_ );
case 3: return f( (T3&)v.storage_ );
case 4: return f( (T4&)v.storage_ );
case 5: return f( (T5&)v.storage_ );
default: __builtin_unreachable();
}
}

struct X
{
int v;
};

template struct Y: X
{
};

using V = variant, Y<1>, Y<2>, Y<3>, Y<4>, Y<5>>;

void f( X& );
int g( int );

int h1( V& v )
{
return visit( v, [](X const& x){ return x.v; } );
}

int h2( V& v )
{
return visit( v, [](auto&& x){ return x.v; } );
}

void h3( V& v )
{
return visit( v, [](auto&& x){ f(x); } );
}

int h4( V& v )
{
return visit( v, [](auto&& x){ return g(x.v); } );
}
```

This generates

```
h1(variant, Y<1>, Y<2>, Y<3>, Y<4>, Y<5> >&):
  mov eax, DWORD PTR [rdi]
  ret
h2(variant, Y<1>, Y<2>, Y<3>, Y<4>, Y<5> >&):
  mov eax, DWORD PTR [rdi]
  ret
h3(variant, Y<1>, Y<2>, Y<3>, Y<4>, Y<5> >&):
  cmp DWORD PTR [rdi+4], 5
  jbe .L15
.L15:
  jmp f(X&)
h4(variant, Y<1>, Y<2>, Y<3>, Y<4>, Y<5> >&):
  cmp DWORD PTR [rdi+4], 5
  jbe .L19
.L19:
  mov edi, DWORD PTR [rdi]
  jmp g(int)
```

so the member access is folded in both cases (which is good!), even though the
first occurs through X& and the second through Y&.

I've been unable to determine what makes the optimizations misfire. This code
should in principle be the same as the simplified one, but it isn't.

[Bug tree-optimization/87205] Inefficient code generation for switch

[pdimov at gmail dot com]

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

--- Comment #8 from Peter Dimov  ---
(In reply to Martin Liška from comment #7)
> I'm not sure here Y are different types here and member access based on
> the type is distinct.

Yes, one could argue that, I suppose. But in the `return ((Y<0>*)p)->v;` case
the member access _is_ lifted outside the jump table. If that's correct there,
it should also be correct here. :-)

[Bug tree-optimization/87188] Function pointer canonicalization optimized away

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #5 from John David Anglin  ---
Created a replacement for D.43111 offset: 0, size: 32: SR.13
Created a replacement for D.43111 offset: 32, size: 32: SR.14

  struct 
  {
bool SV:: (const struct SV *, const struct SV &) * __pfn;
int __delta;
  } D.43111;

   :
  _31 = itCO_7;
  D.43111 = MEM[(const struct  &)_31 + 8];
  SR.13_3 = MEM[(const struct  &)_31 + 8];
  SR.14_20 = MEM[(const struct  &)_31 + 12];
  _4 = SR.13_3;
  if (_4 == operator!=)
goto ; [INV]
  else
goto ; [INV]

I could be wrong but it seems likely the replacement for D.43111.__pfn is
no longer a pointer to a function.

[Bug tree-optimization/87219] New: [9 Regression] internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709

[hjl.tools at gmail dot com]

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

Bug ID: 87219
   Summary: [9 Regression] internal compiler error: in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64, r264069 failed to build 200.sixtrack from SPEC CPU 2000:

[hjl@gnu-35 0002]$ /export/gnu/import/git/gcc-test-spec/usr/bin/-c -o
clor6.o   -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math   clor6.f
bash: /export/gnu/import/git/gcc-test-spec/usr/bin/-c: No such file or
directory
[hjl@gnu-35 0002]$ /export/gnu/import/git/gcc-test-spec/usr/bin/gfortran -c
-o clor6.o   -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math  
clor6.f
during GIMPLE pass: cunroll
clor6.f:3:0:

3 |   subroutine clor6
  | 
internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
0x6b272c check_loop_closed_ssa_def
../../src-trunk/gcc/tree-ssa-loop-manip.c:709
0xe792b0 check_loop_closed_ssa_bb
../../src-trunk/gcc/tree-ssa-loop-manip.c:735
0xe7b376 verify_loop_closed_ssa(bool, loop*)
../../src-trunk/gcc/tree-ssa-loop-manip.c:760
0xe64bda tree_unroll_loops_completely
../../src-trunk/gcc/tree-ssa-loop-ivcanon.c:1493
0xe64c54 execute
../../src-trunk/gcc/tree-ssa-loop-ivcanon.c:1597
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-35 0002]$

[Bug testsuite/87216] FAIL: gcc.dg/tree-prof/pr59521-3.c scan-assembler \\nfoo:\\n.*cmp.*1,.*cmp.*10,.*cmp.*100 on darwin

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-04
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks for the patch, I'll test it and install as obvious.

[Bug tree-optimization/87205] Inefficient code generation for switch

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Peter Dimov from comment #5)
> Another:
> 
> ```
> struct X
> {
> int v;
> };
> 
> template struct Y: X
> {
> };
> 
> void f( int v );
> 
> void h( unsigned ix, void* p )
> {
> switch( ix )
> {
> case 0: f( ((Y<0>*)p)->v ); break;
> case 1: f( ((Y<1>*)p)->v ); break;
> case 2: f( ((Y<2>*)p)->v ); break;
> case 3: f( ((Y<3>*)p)->v ); break;
> case 4: f( ((Y<4>*)p)->v ); break;
> case 5: f( ((Y<5>*)p)->v ); break;
> default: __builtin_unreachable();
> }
> }
> ```
> 
> ```
> h(unsigned int, void*):
>   mov edi, edi
>   jmp [QWORD PTR .L4[0+rdi*8]]
> .L4:
>   .quad .L3
>   .quad .L3
>   .quad .L3
>   .quad .L3
>   .quad .L3
>   .quad .L3
> .L3:
>   mov edi, DWORD PTR [rsi]
>   jmp f(int)
> ```
> 
> https://godbolt.org/z/pGVx6W
> 
> This however demonstrates a different problem, so it may need to go into a
> separate bug.

I'm not sure here Y are different types here and member access based on the
type
is distinct.

[Bug tree-optimization/87205] Inefficient code generation for switch

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---

> ```
> h(unsigned int, void*):
>   cmp edi, 5
>   jbe .L5
> .L5:
>   mov rdi, rsi
>   jmp f(X*)
> ```
> 
> https://godbolt.org/z/2Lh_GZ

Good, my patch can handle that and can generate direct call:

_Z1hjPv:
.LFB0:
.cfi_startproc
movq%rsi, %rdi
jmp _Z1fP1X
.cfi_endproc

[Bug target/87198] ICE in extract_insn, at recog.c:2304

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep  4 17:49:57 2018
New Revision: 264088

URL: https://gcc.gnu.org/viewcvs?rev=264088=gcc=rev
Log:
PR target/87198
* common/config/i386/i386-common.c (OPTION_MASK_ISA_XSAVEOPT_SET,
OPTION_MASK_ISA_XSAVES_SET, OPTION_MASK_ISA_XSAVEC_SET): Use
OPTION_MASK_ISA_XSAVE_SET instead of OPTION_MASK_ISA_XSAVE.
(OPTION_MASK_ISA_XSAVE_UNSET): Add OPTION_MASK_ISA_XSAVES_UNSET
and OPTION_MASK_ISA_XSAVEC_UNSET.

* gcc.target/i386/pr87198.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr87198.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/i386/i386-common.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/87218] Extremely long compile time with 710 line Fortran code using -O2

[toon at moene dot org]

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

--- Comment #1 from Toon Moene  ---
Well, OK - it's more like 9 minutes ...

[Bug tree-optimization/87217] [9 regression] ICE in in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709 when compiling SPEC2000 starting with r264069

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Bill Seurer  ---
Saw this on a power7 powerpc64 big endian machine.

[Bug tree-optimization/87217] New: [9 regression] ICE in in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709 when compiling SPEC2000 starting with r264069

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 87217
   Summary: [9 regression] ICE in in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709 when compiling SPEC2000
starting with r264069
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

0x10bd080b check_loop_closed_ssa_def
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-manip.c:709
0x10bd0b67 check_loop_closed_ssa_bb
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-manip.c:735
0x10bd450f verify_loop_closed_ssa(bool, loop*)
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-manip.c:760
0x10bb31b3 tree_unroll_loops_completely
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-ivcanon.c:1493
0x10bb3313 execute
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-ivcanon.c:1599
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake: *** [clor6.o] Error 1
specmake: *** Waiting for unfinished jobs




seurer@granola:~/gcc/cpu2000/benchspec/CFP2000/200.sixtrack/run/0016$
/home/seurer/gcc/install/gcc-test/bin/gfortran -c -o clor6.o-m64
-O3 -mcpu=power7 -ffast-math -funroll-loops -fpeel-loops -fvect-cost-model
-mpopcntd -mrecip=rsqrt   clor6.f
during GIMPLE pass: cunroll
clor6.f:3:0:

3 |   subroutine clor6
  | 
internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
0x10bd080b check_loop_closed_ssa_def
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-manip.c:709
0x10bd0b67 check_loop_closed_ssa_bb
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-manip.c:735
0x10bd450f verify_loop_closed_ssa(bool, loop*)
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-manip.c:760
0x10bb31b3 tree_unroll_loops_completely
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-ivcanon.c:1493
0x10bb3313 execute
/home/seurer/gcc/gcc-test/gcc/tree-ssa-loop-ivcanon.c:1599
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/87218] New: Extremely long compile time with 710 line Fortran code using -O2

[toon at moene dot org]

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

Bug ID: 87218
   Summary: Extremely long compile time with 710 line Fortran code
using -O2
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toon at moene dot org
  Target Milestone: ---

Created attachment 44660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44660=edit
Source of Fortran routine taking 12+ minutes to compile

Attached file compiled with:

toon@moene:~/src$ gfortran -v -ftime-report -O2 -S suafn.f90 
Using built-in specs.
COLLECT_GCC=gfortran
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-4) 
COLLECT_GCC_OPTIONS='-v' '-ftime-report' '-O2' '-S' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/f951 suafn.f90 -quiet -dumpbase suafn.f90
-mtune=generic -march=x86-64 -auxbase suafn -O2 -version -ftime-report -o
suafn.s -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/8/finclude
GNU Fortran (Debian 8.2.0-4) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Debian 8.2.0-4) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

gives this time report:

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
182 kB (  0%)
 phase parsing  :   0.05 (  0%)   0.00 (  0%)   0.08 (  0%)
   7841 kB (  6%)
 phase opt and generate : 534.57 (100%)   0.45 (100%) 553.90 (100%)
 127110 kB ( 94%)
 dump files :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 callgraph construction :   0.03 (  0%)   0.00 (  0%)   0.06 (  0%)
   4906 kB (  4%)
 ipa function summary   :   0.13 (  0%)   0.00 (  0%)   0.09 (  0%)
  5 kB (  0%)
 ipa pure const :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 ipa icf:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 ipa free inline summary:   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 cfg cleanup: 487.98 ( 91%)   0.04 (  9%) 503.57 ( 91%)
   1045 kB (  1%)
 trivially dead code:   0.10 (  0%)   0.00 (  0%)   0.10 (  0%)
  0 kB (  0%)
 df scan insns  :   0.08 (  0%)   0.03 (  7%)   0.10 (  0%)
  0 kB (  0%)
 df multiple defs   :   0.10 (  0%)   0.00 (  0%)   0.10 (  0%)
  0 kB (  0%)
 df reaching defs   :   0.29 (  0%)   0.01 (  2%)   0.31 (  0%)
  0 kB (  0%)
 df live regs   :   1.07 (  0%)   0.00 (  0%)   1.14 (  0%)
  0 kB (  0%)
 df live regs   :   0.26 (  0%)   0.00 (  0%)   0.29 (  0%)
  0 kB (  0%)
 df must-initialized regs   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 df use-def / def-use chains:   0.12 (  0%)   0.00 (  0%)   0.12 (  0%)
  0 kB (  0%)
 df live reg subwords   :   0.02 (  0%)   0.00 (  0%)   0.02 (  0%)
  0 kB (  0%)
 df reg dead/unused notes   :   0.79 (  0%)   0.01 (  2%)   0.87 (  0%)
   4881 kB (  4%)
 register information   :   0.19 (  0%)   0.00 (  0%)   0.19 (  0%)
  0 kB (  0%)
 alias analysis :   0.26 (  0%)   0.00 (  0%)   0.26 (  0%)
   

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #19 from dave.anglin at bell dot net ---
On 2018-09-04 12:35 PM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>
> --- Comment #18 from Jonathan Wakely  ---
> I don't think we care about glibc < 2.0.6 though.
>
> __max_digits * 4 is not enough for:
>
>std::cout << std::fixed << std::numeric_limits::max();
>
> That needs 4940 bytes, but we don't want to unconditionally alloca that 
> amount.
>
> Maybe:
>
> --- a/libstdc++-v3/include/bits/locale_facets.tcc
> +++ b/libstdc++-v3/include/bits/locale_facets.tcc
> @@ -1008,6 +1008,11 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
>__len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
>  __fbuf, __v);
>
> +#ifdef __hpux
> +   if (__len == -1)
> + __len = __cs_size = 5000;
> +#endif
> +
>  // If the buffer was not large enough, try again with the correct 
> size.
>  if (__len >= __cs_size)
>{
> @@ -1020,6 +1025,11 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
>__len = std::__convert_from_v(_S_get_c_locale(), __cs, 
> __cs_size,
>  __fbuf, __v);
>}
> +
> +#ifdef __hpux
> +   if (__len == -1)
> + return __s;
> +#endif
>   #else
>  // Consider the possibility of long ios_base::fixed outputs
>  const bool __fixed = __io.flags() & ios_base::fixed;
>
Testing.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
I don't think we care about glibc < 2.0.6 though.

__max_digits * 4 is not enough for:

  std::cout << std::fixed << std::numeric_limits::max();

That needs 4940 bytes, but we don't want to unconditionally alloca that amount.

Maybe:

--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -1008,6 +1008,11 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
__fbuf, __v);

+#ifdef __hpux
+   if (__len == -1)
+ __len = __cs_size = 5000;
+#endif
+
// If the buffer was not large enough, try again with the correct size.
if (__len >= __cs_size)
  {
@@ -1020,6 +1025,11 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
__fbuf, __v);
  }
+
+#ifdef __hpux
+   if (__len == -1)
+ return __s;
+#endif
 #else
// Consider the possibility of long ios_base::fixed outputs
const bool __fixed = __io.flags() & ios_base::fixed;

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

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

--- Comment #2 from Andrew Benson  ---
Thanks Janus. That does solve the problem, and regtests cleanly, with this
patch:




Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (revision 264085)
+++ gcc/fortran/gfortran.h  (working copy)
@@ -54,7 +54,9 @@ not after.

 /* Major control parameters.  */

-#define GFC_MAX_SYMBOL_LEN 63   /* Must be at least 63 for F2003.  */
+/* Must be at least 63 for F2003, +1 for null terminator,
+ +12 for prefix "__tmp_class_".  */
+#define GFC_MAX_SYMBOL_LEN 76
 #define GFC_LETTERS 26 /* Number of letters in the alphabet.  */

 #define MAX_SUBRECORD_LENGTH 2147483639   /* 2**31-9 */

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #17 from dave.anglin at bell dot net ---
On 2018-09-04 11:20 AM, redi at gcc dot gnu.org wrote:
> I don't think __cs_size + 1 will be enough in general. There's no reason to
> think it's only 1 byte too small.
>
> Maybe we need a kluge like:
Maybe.  I read in manpage that old glibc versions also return -1 when 
the output is truncated.

I was about to try the attached change.  Was hoping that a slightly 
larger __cs_size would work.

[Bug middle-end/86505] [6/7 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rpirrera at aitek dot it]

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

--- Comment #9 from rpirrera at aitek dot it ---
The patch cannot be applied to the compiler we are using (GCC 5), we get a
function not defined error.
Is it possible to have a patch for GCC 5 too?

Thank you.

[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00994.html

[Bug c++/86740] [8/9 Regression] ICE with hana and nested lambdas (likely a regression, tsubst_copy, at cp/pt.c:15325)

[michal.w.urbanczyk at gmail dot com]

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

Michal Urbanczyk  changed:

   What|Removed |Added

 CC||michal.w.urbanczyk at gmail 
dot co
   ||m

--- Comment #4 from Michal Urbanczyk  ---
I have encountered a similar issue without using Boost.Hana. My code worked
with GCC 7.3 and stopped compiling with GCC 8.1.

The reduced testcase:

struct Constant
{
static constexpr int value = 0;
};
template
void invokeWithConstant(F &)
{
f(Constant{});
}
int foo()
{
int count = 0;
invokeWithConstant([&] (auto id1)
{
invokeWithConstant([&] (auto id2)
{
if constexpr(id1.value == 0  &&  id2.value == 0)
{
[&] { count = 1; } ();
}
});
});
return count;
}



Can be tested online at https://godbolt.org/z/N5rNYl

My case yields ICE from the very same line.

[Bug testsuite/87216] New: FAIL: gcc.dg/tree-prof/pr59521-3.c scan-assembler \\nfoo:\\n.*cmp.*1,.*cmp.*10,.*cmp.*100 on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 87216
   Summary: FAIL: gcc.dg/tree-prof/pr59521-3.c scan-assembler
\\nfoo:\\n.*cmp.*1,.*cmp.*10,.*cmp.*100 on darwin
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

The test gcc.dg/tree-prof/pr59521-3.c fails on darwin. This is "fixed" with the
following patch:

--- ../_clean/gcc/testsuite/gcc.dg/tree-prof/pr59521-3.c2018-09-03
10:54:47.0 +0200
+++ gcc/testsuite/gcc.dg/tree-prof/pr59521-3.c  2018-09-04 17:25:45.0
+0200
@@ -31,4 +31,4 @@ int main()
   }
 }

-/* { dg-final-use-not-autofdo { scan-assembler
"\nfoo:\n.*cmp.*1,.*cmp.*10,.*cmp.*100" { target i?86-*-* x86_64-*-* } } } */
+/* { dg-final-use-not-autofdo { scan-assembler
"\n_?foo:\n.*cmp.*1,.*cmp.*10,.*cmp.*100" { target i?86-*-* x86_64-*-* } } } */
[

[Bug tree-optimization/87205] Inefficient code generation for switch

[pdimov at gmail dot com]

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

--- Comment #5 from Peter Dimov  ---
Another:

```
struct X
{
int v;
};

template struct Y: X
{
};

void f( int v );

void h( unsigned ix, void* p )
{
switch( ix )
{
case 0: f( ((Y<0>*)p)->v ); break;
case 1: f( ((Y<1>*)p)->v ); break;
case 2: f( ((Y<2>*)p)->v ); break;
case 3: f( ((Y<3>*)p)->v ); break;
case 4: f( ((Y<4>*)p)->v ); break;
case 5: f( ((Y<5>*)p)->v ); break;
default: __builtin_unreachable();
}
}
```

```
h(unsigned int, void*):
  mov edi, edi
  jmp [QWORD PTR .L4[0+rdi*8]]
.L4:
  .quad .L3
  .quad .L3
  .quad .L3
  .quad .L3
  .quad .L3
  .quad .L3
.L3:
  mov edi, DWORD PTR [rsi]
  jmp f(int)
```

https://godbolt.org/z/pGVx6W

This however demonstrates a different problem, so it may need to go into a
separate bug.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Yes I've just realised that passing 0 was a red herring, because we take the 
#if _GLIBCXX_USE_C99_STDIO branch. Sorry.

I don't think __cs_size + 1 will be enough in general. There's no reason to
think it's only 1 byte too small.

Maybe we need a kluge like:

--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -1008,6 +1008,20 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
__fbuf, __v);

+#ifdef __hpux
+   while (__len == -1 && __cs_size < 1024)
+ {
+   __cs_size *= 2;
+   char* __cs = static_cast(__builtin_alloca(__cs_size));
+   if (__use_prec)
+ __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+ __fbuf, __prec, __v);
+   else
+ __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+ __fbuf, __v);
+ }
+#endif
+
// If the buffer was not large enough, try again with the correct size.
if (__len >= __cs_size)
  {

[Bug tree-optimization/87205] Inefficient code generation for switch

[pdimov at gmail dot com]

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

--- Comment #4 from Peter Dimov  ---
If the code is not the same the jump table is not optimized out and there's no
extra check. But it also happens with code that is not the same on the C++
side, for example:

```
struct X
{
int v;
};

template struct Y: X
{
};

void f( X* x );

void h( unsigned ix, void* p )
{
switch( ix )
{
case 0: f( (Y<0>*)p ); break;
case 1: f( (Y<1>*)p ); break;
case 2: f( (Y<2>*)p ); break;
case 3: f( (Y<3>*)p ); break;
case 4: f( (Y<4>*)p ); break;
case 5: f( (Y<5>*)p ); break;
default: __builtin_unreachable();
}
}
```

```
h(unsigned int, void*):
  cmp edi, 5
  jbe .L5
.L5:
  mov rdi, rsi
  jmp f(X*)
```

https://godbolt.org/z/2Lh_GZ

A variation on the same theme, which demonstrates another kind of missed
optimization:

```
struct X
{
int v;
};

template struct Y: X
{
};

int h( unsigned ix, void* p )
{
switch( ix )
{
case 0: return ((Y<0>*)p)->v;
case 1: return ((Y<1>*)p)->v;
case 2: return ((Y<2>*)p)->v;
case 3: return ((Y<3>*)p)->v;
case 4: return ((Y<4>*)p)->v;
case 5: return ((Y<5>*)p)->v;
default: __builtin_unreachable();
}
}
```

```
h(unsigned int, void*):
  mov edi, edi
  mov eax, DWORD PTR [rsi]
  jmp [QWORD PTR .L4[0+rdi*8]]
.L4:
  .quad .L9
  .quad .L8
  .quad .L7
  .quad .L6
  .quad .L5
  .quad .L3
.L5:
  ret
.L3:
  ret
.L9:
  ret
.L8:
  ret
.L7:
  ret
.L6:
  ret
```

https://godbolt.org/z/lCzlR2

There's a table, so there's no redundant check.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #15 from dave.anglin at bell dot net ---
On 2018-09-04 4:51 AM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>
> --- Comment #6 from Jonathan Wakely  ---
> And the previous line an alloca call using __len:
>
>  _CharT* __ws = static_cast<_CharT*>(__builtin_alloca(sizeof(_CharT)
>   * __len));
>  __ctype.widen(__cs, __cs + __len, __ws);
>
>
> The code assumes __convert_from_v always returns a valid length, but it seems
> to be failing and returning -1.
It appears to me we are using the first hunk of the #if:

#if _GLIBCXX_USE_C99_STDIO
     // Precision is always used except for hexfloat format.
     const bool __use_prec =
   (__io.flags() & ios_base::floatfield) != ios_base::floatfield;

     // First try a buffer perhaps big enough (most probably sufficient
     // for non-ios_base::fixed outputs)
     int __cs_size = __max_digits * 3;
     char* __cs = static_cast(__builtin_alloca(__cs_size));
     if (__use_prec)
   __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
     __fbuf, __prec, __v);
     else
   __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
     __fbuf, __v);

     // If the buffer was not large enough, try again with the 
correct size.
     if (__len >= __cs_size)
   {
     __cs_size = __len + 1;
     __cs = static_cast(__builtin_alloca(__cs_size));
     if (__use_prec)
   __len = std::__convert_from_v(_S_get_c_locale(), __cs, 
__cs_size,
     __fbuf, __prec, __v);
     else
   __len = std::__convert_from_v(_S_get_c_locale(), __cs, 
__cs_size,
     __fbuf, __v);
   }
#else
     // Consider the possibility of long ios_base::fixed outputs
     const bool __fixed = __io.flags() & ios_base::fixed;
     const int __max_exp =
__gnu_cxx::__numeric_traits<_ValueT>::__max_exponent10;

     // The size of the output string is computed as follows.
     // ios_base::fixed outputs may need up to __max_exp + 1 chars
     // for the integer part + __prec chars for the fractional part
     // + 3 chars for sign, decimal point, '\0'. On the other hand,
     // for non-fixed outputs __max_digits * 2 + __prec chars are
     // largely sufficient.
     const int __cs_size = __fixed ? __max_exp + __prec + 4
   : __max_digits * 2 + __prec;
     char* __cs = static_cast(__builtin_alloca(__cs_size));
     __len = std::__convert_from_v(_S_get_c_locale(), __cs, 0, __fbuf,
   __prec, __v);
#endif

In the first hunk, __cs_size is not zero but __max_digits * 3.  If the 
buffer is too small,
__len will be -1.  We need to check for -1 in second if.  Is 
incrementing __cs_size by
1 enough?

[Bug target/86744] gcc.target/i386/addr-sel-1.c XPASSes on 32-bit x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
Fixed for 9.0.

[Bug target/86744] gcc.target/i386/addr-sel-1.c XPASSes on 32-bit x86

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Author: ro
Date: Tue Sep  4 15:00:41 2018
New Revision: 264086

URL: https://gcc.gnu.org/viewcvs?rev=264086=gcc=rev
Log:
Don't xfail gcc.target/i386/addr-sel-1.c (PR target/86744)

PR target/86744
* gcc.target/i386/addr-sel-1.c: Don't xfail "b\\+1" scan.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/addr-sel-1.c

[Bug tree-optimization/87205] Inefficient code generation for switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug fortran/87212] Declaration with array constructor: Error message on valid code

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
The same error occurs with SUM.

[Bug c++/87205] Inefficient code generation for switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #3 from Martin Liška  ---
I can confirm that. I've got quite simple patch that eventually generates:

h:
.LFB0:
movl$42, %edi
jmp f

for both cases you provided.

By the way do you have a more complex test-case? This one is simple as all
non-default cases contain same code.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #14 from dave.anglin at bell dot net ---
On 2018-09-04 10:16 AM, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>
> --- Comment #13 from dave.anglin at bell dot net ---
> On 2018-09-04 9:48 AM, redi at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>>
>> --- Comment #12 from Jonathan Wakely  ---
>> (In reply to dave.anglin from comment #11)
>>> JAGaf47646: with small buffer vsnprintf always returns -1
>> Aha, that is probably it. We pass 0 as the size, which is supposed to make
>> vsnprintf tell you how many bytes it would have written (as that's how we 
>> find
>> out the required length).
>>
>> It's curious that it printed "returned 4, errno = 0" when you tested it 
>> though.
>> Maybe GCC optimized the call and didn't use the OS function.
>>
>> Does it return -1 if you use -fno-builtin-vsnprintf ?
> No.  I checked .s file and GCC isn't optimizing the call.  It returns -1
> when passed a nonzero size
> that is too small.
>
> Passing 4 causes it to return -1:
> using vsnprintf
> returned -1, errno = 0
>
> Passing 5 is okay:
> using vsnprintf
> returned 4, errno = 0
>
> Maybe it's returning an incorrect length when passed 0 in some locales?
No, it uses the buffer when passed a a size of 0:
https://stackoverflow.com/questions/619497/heap-corruption-in-hp-ux

[Bug c++/87208] dependent name resolution selects a function it should have NEVER considered

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-04
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=51577
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Ah yes, I didn't look closely enough.

Confirmed. Every release I tested from 4.3 onwards has the same behaviour, so
it doesn't seem to be a regression.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2018-09-04 9:48 AM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>
> --- Comment #12 from Jonathan Wakely  ---
> (In reply to dave.anglin from comment #11)
>> JAGaf47646: with small buffer vsnprintf always returns -1
> Aha, that is probably it. We pass 0 as the size, which is supposed to make
> vsnprintf tell you how many bytes it would have written (as that's how we find
> out the required length).
>
> It's curious that it printed "returned 4, errno = 0" when you tested it 
> though.
> Maybe GCC optimized the call and didn't use the OS function.
>
> Does it return -1 if you use -fno-builtin-vsnprintf ?
No.  I checked .s file and GCC isn't optimizing the call.  It returns -1 
when passed a nonzero size
that is too small.

Passing 4 causes it to return -1:
using vsnprintf
returned -1, errno = 0

Passing 5 is okay:
using vsnprintf
returned 4, errno = 0

Maybe it's returning an incorrect length when passed 0 in some locales?

Dave

[Bug c++/87208] dependent name resolution selects a function it should have NEVER considered

[SztfG at yandex dot ru]

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

--- Comment #2 from SztfG at yandex dot ru ---
(In reply to Jonathan Wakely from comment #1)
> Dup of PR 51577 ?
Strictly speaking, it is not a dup, because PR 51577 and all the bugs marked as
dups of PR 51577 are about finding an operator with namespaced parameters in
the global namespace, but here the situation is the reverse. But the bugs could
be closely related.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to dave.anglin from comment #11)
> JAGaf47646: with small buffer vsnprintf always returns -1

Aha, that is probably it. We pass 0 as the size, which is supposed to make
vsnprintf tell you how many bytes it would have written (as that's how we find
out the required length).

It's curious that it printed "returned 4, errno = 0" when you tested it though.
Maybe GCC optimized the call and didn't use the OS function.

Does it return -1 if you use -fno-builtin-vsnprintf ?

[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz,
   ||paul.hua.gm at gmail dot com

--- Comment #1 from Paul Hua  ---
confirmed.

cced: Jan Hubicka 

[Bug tree-optimization/87211] [9 Regression] gcc ICE at O2: in set_ssa_val_to, at tree-ssa-sccvn.c:3628

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87214] [9 Regression] SPEC CPU2017, CPU2006 520/620, 403 runfails after r263772 with march=skylake-avx512

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug debug/87215] Unused debug info with -std=c++17

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
There's a related PR about us emitting more unused debug for global
declarations
(rather than types) and DWARF mode not implementing
-feliminate-unused-debug-symbols).  This probably is the reason for this
regression by making the previously unused types no longer unused.

[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses

[neha.gnu.gcc at gmail dot com]

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

Neha Gowda  changed:

   What|Removed |Added

 CC||neha.gnu.gcc at gmail dot com

--- Comment #7 from Neha Gowda  ---
cat test.cpp

==
#define _NOEXCEPT_OP(x) noexcept(x)

template inline
bool _Swap_adl(_Ty& _Left, _Ty& _Right)
{   
return (true);
}

template
struct pair
{   
typedef pair<_Ty1, _Ty2> _Myt;
typedef _Ty1 first_type;
typedef _Ty2 second_type;

void swap(_Myt& _Right)
_NOEXCEPT_OP(_NOEXCEPT_OP(_Swap_adl(this->first, _Right.first))
&& _NOEXCEPT_OP(_Swap_adl(this->second,
_Right.second)))

{   
if (this != &_Right)
{   // different, worth swapping
_Swap_adl(first, _Right.first);
_Swap_adl(second, _Right.second);
}
}
_Ty1 first; 
_Ty2 second;
};
==
g++ test.cpp -c

test.cpp:18:39: error: invalid use of ‘this’ at top level
test.cpp:19:30: error: invalid use of ‘this’ at top level

Same issue with the current upstream sources as well.
Please let me know if there is any patch or workaround to fix the issue.

Else please let me know how to fix this issue in GCC.

Thanks

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  ---
On i9-7960X I get (cc1 is -O0 checking build, so bootstrapped compiler might be
much faster), will repeat that with bootstrapped compiler if it succeeds.  The
__int128 and unsigned __int128 tests are clearly too expensive.

for i in 1 2 3 4 5 6; do time ./cc1 -quiet -O2 -o pr82853-$i.{s,c}; gcc -o
pr82853-$i{,.s}; time ./pr82853-$i; echo $?; done
real0m11.273s
user0m11.182s
sys 0m0.039s

real0m2.997s
user0m2.993s
sys 0m0.001s
0

real0m8.145s
user0m8.082s
sys 0m0.026s

real0m2.166s
user0m2.165s
sys 0m0.000s
0

real0m11.683s
user0m11.597s
sys 0m0.033s

real0m5.315s
user0m5.312s
sys 0m0.000s
0

real0m7.972s
user0m7.903s
sys 0m0.032s

real0m3.801s
user0m3.798s
sys 0m0.001s
0

real0m12.846s
user0m12.762s
sys 0m0.028s

real0m17.471s
user0m17.458s
sys 0m0.001s
0

real0m8.546s
user0m8.486s
sys 0m0.022s

real0m13.738s
user0m13.728s
sys 0m0.000s

[Bug target/66203] aarch64-none-elf does not automatically find librdimon

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
The Arm builds that do not need anything from libgloss (and thus do not need a
specs file) while linking come from a configuration that hard codes the
underlying runtime monitor (usually the arm semihosting ABI) directly into
newlib.

I understand that's deprecated and was not implemented for AArch64.

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[rearnsha at gcc dot gnu.org]

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

--- Comment #27 from Richard Earnshaw  ---
(In reply to Jakub Jelinek from comment #26)

> A test generator for x % c1 == c2 expansion for unsigned, int, unsigned long
> long, long long, unsigned int128 and int128 types (assuming ilp32 or lp64)
> plus tests for those types.  Takes about 2 minutes to compile + run on a fast
> box and uses random (), so not really sure the tests should go into the
> testsuite.  Thoughts on that?  After all, the generator isn't extra smart and
> doesn't try to find problematic corner cases.

If you work on the 'guess' of a 10x slowdown when using simulators, that's
probably too long particularly if it's not delivering high value. 

Ultimately, it will depend on how much of that 2 minutes is during
generate/compile and how much during run time.

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Created attachment 44658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44658=edit
pr82853-tests.tar.xz

A test generator for x % c1 == c2 expansion for unsigned, int, unsigned long
long, long long, unsigned int128 and int128 types (assuming ilp32 or lp64)
plus tests for those types.  Takes about 2 minutes to compile + run on a fast
box and uses random (), so not really sure the tests should go into the
testsuite.  Thoughts on that?  After all, the generator isn't extra smart and
doesn't try to find problematic corner cases.

[Bug debug/87215] New: Unused debug info with -std=c++17

[holger.hopp at sap dot com]

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

Bug ID: 87215
   Summary: Unused debug info with -std=c++17
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com
  Target Milestone: ---

gcc-7 and gcc-8 produce much more unused (?) debug info when compiling in C++17
mode (compared to C++14 or C++11 mode).
Seems that unused debug info elimination (-f[no-]eliminate-unused-debug-types )
does not work properly with C++17.

Source (not preprocessed, but simple):

#include 

Reproduce:

g++ -std=c++14 -g -o limits-14.o -c limits.cpp 
g++ -std=c++14 -g -fno-eliminate-unused-debug-types -o limits-14-ne.o -c
limits.cpp 
g++ -std=c++17 -g -o limits-17.o -c limits.cpp 
g++ -std=c++17 -g -fno-eliminate-unused-debug-types -o limits-17-ne.o -c
limits.cpp 
g++ -std=c++17 -g -feliminate-unused-debug-types -o limits-17-e.o -c limits.cpp 
wc -c limits*.o

With gcc-7 or gcc-8:
 37872 limits-14-ne.o
  3096 limits-14.o
 69720 limits-17-e.o
 69728 limits-17-ne.o
 69688 limits-17.o

Ok with gcc-6:
 36816 limits-14-ne.o
  2864 limits-14.o
  2888 limits-17-e.o
 36816 limits-17-ne.o
  2864 limits-17.o

(no difference between 'g++ -std=c++14 -E limits.cpp' and 'g++ -std=c++17 -E
limits.cpp' preprocessed outputs)

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #25 from Jakub Jelinek  ---
Created attachment 44657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44657=edit
gcc9-pr82853.patch

Full untested patch.  For x % C1 == C2 it handles all unsigned cases where C1
is odd, if C1 is even, just cases where C2 <= -1U % C1, if signed modulo, just
x % C1 == 0 cases (where C1 is not INT_MIN).

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #11 from dave.anglin at bell dot net ---
On 2018-09-04 7:58 AM, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>
> --- Comment #10 from dave.anglin at bell dot net ---
> On 2018-09-04 4:51 AM, redi at gcc dot gnu.org wrote:
>> The code assumes __convert_from_v always returns a valid length, but it seems
>> to be failing and returning -1.
> vsnprintf/snprintf can return a negative value if an error occurs.
I think we are hitting one of these problems:

JAGaf80770: vsnprintf and snprintf return doesn't conform to C99
JAGaf47646: with small buffer vsnprintf always returns -1

Probably, we should use libiberty version unless we can work around the 
buffer size issue.

[Bug tree-optimization/87211] [9 Regression] gcc ICE at O2: in set_ssa_val_to, at tree-ssa-sccvn.c:3628

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  4 12:04:42 2018
New Revision: 264079

URL: https://gcc.gnu.org/viewcvs?rev=264079=gcc=rev
Log:
2018-09-04  Richard Biener  

PR tree-optimization/87211
* tree-ssa-sccvn.c (visit_phi): When value-numbering to a
backedge value we're supposed to treat as VARYING also number
the PHI to VARYING in case it got a different value-number already.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87211.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/87214] New: [9 Regression] SPEC CPU2017, CPU2006 520/620, 403 runfails after r263772 with march=skylake-avx512

[alexander.nesterovskiy at intel dot com]

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

Bug ID: 87214
   Summary: [9 Regression] SPEC CPU2017, CPU2006 520/620, 403
runfails after r263772 with march=skylake-avx512
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.nesterovskiy at intel dot com
  Target Milestone: ---

There are runfails for the following benchmarks since r263772:
SPEC2017 520/620: (Segmentation fault, minimal optset to reproduce: "-O3
-march=skylake-avx512 -flto")
SPEC2006 445: (SPEC miscompare, minimal optset to reproduce: "-O3
-march=skylake-avx512")

Running 520.omnetpp_r under GDB:
---
...
Program received signal SIGSEGV, Segmentation fault.
0x004a611e in isName (s=, this=) at
simulator/ccomponent.cc:143
143 if (paramv[i].isName(parname))
(gdb) backtrace
#0  0x004a611e in isName (s=, this=) at
simulator/ccomponent.cc:143
#1  cComponent::findPar (this=0x76633380, parname=0x76603548 "bs") at
simulator/ccomponent.cc:143
#2  0x004a87b3 in cComponent::par(char const*) () at
simulator/ccomponent.cc:133
#3  0x004b676d in cNEDNetworkBuilder::doParam(cComponent*,
ParamElement*, bool) () at simulator/cnednetworkbuilder.cc:179
#4  0x004b8610 in doParams (isSubcomponent=false, paramsNode=, component=0x76633380, this=0x7fffaaf0) at
simulator/cnednetworkbuilder.cc:139
#5  cNEDNetworkBuilder::addParametersAndGatesTo(cComponent*, cNEDDeclaration*)
() at simulator/cnednetworkbuilder.cc:105
#6  0x0048843b in addParametersAndGatesTo (module=0x76633380,
this=) at /include/c++/9.0.0/bits/stl_tree.h:211
#7  cModuleType::create(char const*, cModule*, int, int) () at
simulator/ccomponenttype.cc:156
#8  0x0045916f in setupNetwork (network=,
this=0x7653bc40) at simulator/cnamedobject.h:117
#9  Cmdenv::run() () at simulator/cmdenv.cc:253
#10 0x005186ec in EnvirBase::run(int, char**, cConfiguration*) () at
simulator/envirbase.cc:230
#11 0x0043d60d in setupUserInterface(int, char**, cConfiguration*)
[clone .constprop.112] () at simulator/startup.cc:234
#12 0x0042446a in main (argc=1, argv=0x7fffb1c8) at
simulator/main.cc:39
---

403.gcc miscompares: 200.s, g23.s, scilab.s.
For example:
---
$ diff -u g23_ref.s g23.s | head -n 16
--- g23_ref.s
+++ g23.s
@@ -1746,19 +1746,19 @@
testq   %rbx, %rbx
jne .L904
movq%r12, %rdx
-   xorl%r8d, %r8d
+   xorl%esi, %esi
negq%rdx
 .L905:
addq%rcx, %rdx
-   leaq(%rax,%r8), %rax
+   leaq(%rax,%rsi), %rax
leaq1(%rdx), %rcx
-   cmpq%r8, %rax
+   cmpq%rsi, %rax

---

Unfortunately I didn't manage to create a reproducer.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2018-09-04 4:51 AM, redi at gcc dot gnu.org wrote:
> The code assumes __convert_from_v always returns a valid length, but it seems
> to be failing and returning -1.
vsnprintf/snprintf can return a negative value if an error occurs.

[Bug c++/87207] ODR issue with static functions and lambda templates

[blastrock at free dot fr]

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

--- Comment #6 from blastrock at free dot fr ---
Great, thanks!

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2018-09-04 6:38 AM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
>
> --- Comment #8 from Jonathan Wakely  ---
> Could you see what this prints on the target please?
# ./test
using vsnprintf
returned 4, errno = 0

>
> #include 
>
> int
> getlen(char* __out, int __size __attribute__((unused)), const char* __fmt, 
> ...)
> {
>__builtin_va_list __args;
>__builtin_va_start(__args, __fmt);
>
> #if _GLIBCXX_USE_C99_STDIO
>__builtin_puts("using vsnprintf");
>const int __ret = __builtin_vsnprintf(__out, __size, __fmt, __args);
> #else
>__builtin_puts("using vsprintf");
>const int __ret = __builtin_vsprintf(__out, __fmt, __args);
> #endif
>return __ret;
> }
>
> int main()
> {
>char out[64];
>errno = 0;
>int len = getlen(out, 0, "%.*g", 6, 1.99);
>__builtin_printf("returned %d, errno = %d\n", len, errno);
> }
>

[Bug tree-optimization/87176] [9 Regression] wrong code at -Os and above on x86-64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87176] [9 Regression] wrong code at -Os and above on x86-64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  4 10:55:46 2018
New Revision: 264077

URL: https://gcc.gnu.org/viewcvs?rev=264077=gcc=rev
Log:
2018-09-04  Richard Biener  

PR tree-optimization/87176
* tree-ssa-sccvn.c (visit_phi): Remove redundant allsame
variable.  When value-numbering a virtual PHI node make sure
to not value-number to the backedge value.

* gcc.dg/torture/pr87176.c: New testcase.
* gcc.dg/torture/ssa-fre-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87176.c
trunk/gcc/testsuite/gcc.dg/torture/ssa-fre-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Could you see what this prints on the target please?

#include 

int
getlen(char* __out, int __size __attribute__((unused)), const char* __fmt, ...)
{
  __builtin_va_list __args;
  __builtin_va_start(__args, __fmt);

#if _GLIBCXX_USE_C99_STDIO
  __builtin_puts("using vsnprintf");
  const int __ret = __builtin_vsnprintf(__out, __size, __fmt, __args);
#else
  __builtin_puts("using vsprintf");
  const int __ret = __builtin_vsprintf(__out, __fmt, __args);
#endif
  return __ret;
}

int main()
{
  char out[64];
  errno = 0;
  int len = getlen(out, 0, "%.*g", 6, 1.99);
  __builtin_printf("returned %d, errno = %d\n", len, errno);
}

[Bug middle-end/87162] [6.2.0] Internal compiler error: Error reporting routines re-entered.

[yellowriver2010 at hotmail dot com]

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

--- Comment #5 from Wen Yang  ---
(gdb) p *(opt_pass *) 0x2434380
$4 = { = {type = GIMPLE_PASS, name = 0x18530f0 "*tminit",
optinfo_flags = 0, tv_id = TV_TRANS_MEM, properties_required = 40,
properties_provided = 0,
properties_destroyed = 0, todo_flags_start = 524288, todo_flags_finish =
0}, _vptr.opt_pass = 0x1853508 ,
  sub = 0x24343e0, next = 0x2434500, static_pass_number = -1,
graph_dump_initialized = false, m_ctxt = 0x240b3d0}
(gdb) p cfun
$5 = (function *) 0x7fffd16e83f0
(gdb) p *cfun
$6 = {eh = 0x7fffd12e8030, cfg = 0x0, gimple_body = 0x0, gimple_df = 0x0,
x_current_loops = 0x0, su = 0x0, value_histograms = 0x0, decl = 0x7fffd24e8e00,
  static_chain_decl = 0x0, nonlocal_goto_save_area = 0x0, local_decls = 0x0,
cilk_frame_decl = 0x0, machine = 0x7fffd36e88c0, language = 0x0,
used_types_hash = 0x0,
  fde = 0x0, last_stmt_uid = 0, funcdef_no = 72, function_start_locus = 0,
function_end_locus = 0, curr_properties = 0, last_verified = 0,
cannot_be_copied_reason = 0x0,
  last_clique = 0, va_list_gpr_size = 255, va_list_fpr_size = 255, calls_setjmp
= 0, calls_alloca = 0, is_cilk_function = 0, calls_cilk_spawn = 0,
has_nonlocal_label = 0,
  has_forced_label_in_static = 0, cannot_be_copied_set = 0, stdarg = 0,
after_inlining = 0, always_inline_functions_inlined = 0,
can_throw_non_call_exceptions = 0,
  can_delete_dead_exceptions = 0, returns_struct = 0, returns_pcc_struct = 0,
has_local_explicit_reg_vars = 0, is_thunk = 0, has_force_vectorize_loops = 0,
  has_simduid_loops = 0, tail_call_marked = 0}


cfun->cfg is NULL.

[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib

[vigerske at math dot hu-berlin.de]

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

Stefan Vigerske  changed:

   What|Removed |Added

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

--- Comment #7 from Stefan Vigerske  ---
Hmm, I think you are right!

With GCC 8.2.0, which I'm using, there still was AC_CHECK_LIB([z], [compress],
[]). The empty [] in the third argument does not seem to have the desired
effect of suppressing the addition of -lz to LIBS. It is still there:
https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure?revision=259610=markup#l12945

With revision 263320 from August 5, the third argument of AC_CHECK_LIB is
nontrivial and then -lz is not appended to LIBS anymore:
https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure?r1=259610=263320

Sorry, I didn't realize this behavior of AC_CHECK_LIBS, but the documentation
also says clearly that augmenting LIBS is only the default behavior if not
overwritten.

Then everything should be fine with the next GCC release.

[Bug fortran/87212] Declaration with array constructor: Error message on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-04
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> The following is from c.l.f. Jan 26, 2018 but seems to never have been
> filed as a bug report here (?), though Dominique d'Humieres presented
> a workaround for the code below.

Confirmed from 4.8 up to trunk (9.0). The workaround is to replace

  [(product([(j,j=1,i)]),i=0,13)] 

with

  product(reshape([([(j,j=1,i),(1_INT64,j=i+1,13)],i=0,13)],[13,14]),
dim=1)

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
I assume the implementation in libstdc++-v3/config/locale/generic/c_locale.h is
used for HPUX, so one of these is returning an error, which we then use as
__len:

#if _GLIBCXX_USE_C99_STDIO
const int __ret = __builtin_vsnprintf(__out, __size, __fmt, __args);
#else
const int __ret = __builtin_vsprintf(__out, __fmt, __args);
#endif

[Bug middle-end/87162] [6.2.0] Internal compiler error: Error reporting routines re-entered.

[yellowriver2010 at hotmail dot com]

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

--- Comment #4 from Wen Yang  ---
Program received signal SIGSEGV, Segmentation fault.
0x00929fa1 in calculate_dominance_info (dir=CDI_DOMINATORS) at
../../gcc-6.2.0/gcc/dominance.c:633
633   if (dom_computed[dir_index] == DOM_OK)
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64
gmp-6.0.0-15.el7.x86_64 libmpc-1.0.1-3.el7.x86_64 mpfr-3.1.1-4.el7.x86_64
zlib-1.2.7-17.el7.x86_64
(gdb) bt
#0  0x00929fa1 in calculate_dominance_info (dir=CDI_DOMINATORS) at
../../gcc-6.2.0/gcc/dominance.c:633
#1  0x00d62673 in gate_tm_init () at
../../gcc-6.2.0/gcc/trans-mem.c:2100
#2  0x00d6289b in (anonymous namespace)::pass_tm_init::gate
(this=0x2434380) at ../../gcc-6.2.0/gcc/trans-mem.c:2156
#3  0x00c44738 in dump_one_pass (pass=0x2434380, pass_indent=1) at
../../gcc-6.2.0/gcc/passes.c:908
#4  0x00c4483e in dump_pass_list (pass=0x2434380, indent=1) at
../../gcc-6.2.0/gcc/passes.c:930
#5  0x00c44915 in gcc::pass_manager::dump_passes (this=0x242e580) at
../../gcc-6.2.0/gcc/passes.c:956
#6  0x00c4488f in dump_passes () at ../../gcc-6.2.0/gcc/passes.c:942
#7  0x008eaa25 in symbol_table::finalize_compilation_unit
(this=0x704ed0a8) at ../../gcc-6.2.0/gcc/cgraphunit.c:2538
#8  0x00d58f45 in compile_file () at ../../gcc-6.2.0/gcc/toplev.c:488
#9  0x00d5b3ee in do_compile () at ../../gcc-6.2.0/gcc/toplev.c:1986
#10 0x00d5b678 in toplev::main (this=0x7fffa7a0, argc=585,
argv=0x7fffa8a8) at ../../gcc-6.2.0/gcc/toplev.c:2094
#11 0x0167e46e in main (argc=585, argv=0x7fffa8a8) at
../../gcc-6.2.0/gcc/main.c:39
(gdb) p  dir_index
$1 = 0
(gdb) l
628 void
629 calculate_dominance_info (cdi_direction dir)
630 {
631   unsigned int dir_index = dom_convert_dir_to_idx (dir);
632
633   if (dom_computed[dir_index] == DOM_OK)
634 {
635   checking_verify_dominators (dir);
636   return;
637 }


 #define dom_computed (cfun->cfg->x_dom_computed)


(gdb) disassemble calculate_dominance_info
Dump of assembler code for function calculate_dominance_info(cdi_direction):
   0x00929f6e <+0>: push   %rbp
   0x00929f6f <+1>: mov%rsp,%rbp
   0x00929f72 <+4>: sub$0xc0,%rsp
   0x00929f79 <+11>:mov%edi,-0xb4(%rbp)
   0x00929f7f <+17>:mov-0xb4(%rbp),%eax
   0x00929f85 <+23>:mov%eax,%edi
   0x00929f87 <+25>:callq  0x928e19

   0x00929f8c <+30>:mov%eax,-0xc(%rbp)
   0x00929f8f <+33>:mov0x19bd1a2(%rip),%rax# 0x22e7138

   0x00929f96 <+40>:mov0x8(%rax),%rax
   0x00929f9a <+44>:mov-0xc(%rbp),%edx
   0x00929f9d <+47>:add$0xc,%rdx
   0x00929fa1 <+51>:mov0x4(%rax,%rdx,4),%eax
   0x00929fa5 <+55>:cmp$0x2,%eax
   0x00929fa8 <+58>:jne0x929fbc

..



(gdb) p  *(struct function *) 0x22e7138
$3 = {eh = 0x7fffd16e83f0, cfg = 0x0, gimple_body = 0x0, gimple_df = 0x49,
x_current_loops = 0x0, su = 0x0, value_histograms = 0x0, decl = 0x0,
static_chain_decl = 0x0,
  nonlocal_goto_save_area = 0x0, local_decls = 0x0, cilk_frame_decl =
0x1, machine = 0x24230c0, language = 0x0, used_types_hash = 0x0, fde =
0x0, last_stmt_uid = 0,
  funcdef_no = 0, function_start_locus = 0, function_end_locus = 0,
curr_properties = 0, last_verified = 0, cannot_be_copied_reason = 0x0,
last_clique = 0,
  va_list_gpr_size = 0, va_list_fpr_size = 0, calls_setjmp = 0, calls_alloca =
0, is_cilk_function = 0, calls_cilk_spawn = 0, has_nonlocal_label = 0,
  has_forced_label_in_static = 0, cannot_be_copied_set = 0, stdarg = 0,
after_inlining = 0, always_inline_functions_inlined = 0,
can_throw_non_call_exceptions = 0,
  can_delete_dead_exceptions = 0, returns_struct = 0, returns_pcc_struct = 0,
has_local_explicit_reg_vars = 0, is_thunk = 0, has_force_vectorize_loops = 0,
  has_simduid_loops = 0, tail_call_marked = 0}

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
And the previous line an alloca call using __len:

_CharT* __ws = static_cast<_CharT*>(__builtin_alloca(sizeof(_CharT)
 * __len));
__ctype.widen(__cs, __cs + __len, __ws);


The code assumes __convert_from_v always returns a valid length, but it seems
to be failing and returning -1.

[Bug c++/87207] ODR issue with static functions and lambda templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk by r260017 so this is PR 85646

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

[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||blastrock at free dot fr

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

[Bug c++/87207] ODR issue with static functions and lambda templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|8.0 |7.2.0

--- Comment #4 from Jonathan Wakely  ---
Version field updated because the gcc -v output shows you're using 7.2.0 not
8.0

[Bug c++/87207] ODR issue with static functions and lambda templates

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I can reproduce it with FSF GCC 7.3 and FSF GCC 8.1 but not with FSF GCC 8.2 so
it might be a duplicate of another bug that got fixed.

[Bug tree-optimization/87211] [9 Regression] gcc ICE at O2: in set_ssa_val_to, at tree-ssa-sccvn.c:3628

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-04
Version|unknown |9.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
Summary|gcc ICE at O2: in   |[9 Regression] gcc ICE at
   |set_ssa_val_to, at  |O2: in set_ssa_val_to, at
   |tree-ssa-sccvn.c:3628   |tree-ssa-sccvn.c:3628
 Ever confirmed|0   |1

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

[Bug middle-end/87209] Wuninitialized or Wmaybe-uninitialized doesn't warn when malloc's return value is used without being initialized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-04
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Since we allow calloc to be declared with 'malloc' attribute the warning would
need to be special-cased on 'malloc'.  Currently the warning uses the alias
machinery and that sees malloc clobber ints if not -fno-math-errno.  The
machinery doesn't check whether the ref is to the memory returned by malloc.

/* If the call in statement CALL may clobber the memory reference REF
   return true, otherwise return false.  */

bool
call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref)
{
...
/* Allocating memory does not have any side-effects apart from
   being the definition point for the pointer.  */
case BUILT_IN_MALLOC:
case BUILT_IN_ALIGNED_ALLOC:
case BUILT_IN_CALLOC:
case BUILT_IN_STRDUP:
case BUILT_IN_STRNDUP:
  /* Unix98 specifies that errno is set on allocation failure.  */
  if (flag_errno_math
  && targetm.ref_may_alias_errno (ref))
return true;
  return false;

note that -fno-math-errno doesn't fix it which is because of

  /* Do not warn if it can be initialized outside this function.
 If we did not reach function entry then we found killing
 clobbers on all paths to entry.  */
  if (fentry_reached
  /* ???  We'd like to use ref_may_alias_global_p but that
 excludes global readonly memory and thus we get bougs
 warnings from p = cond ? "a" : "b" for example.  */
  && (!VAR_P (base)
  || is_global_var (base)))
continue;

so we do not handle uninit reads from pointer refs in this case.

[Bug c++/87207] ODR issue with static functions and lambda templates

[blastrock at free dot fr]

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

--- Comment #2 from blastrock at free dot fr ---
This seems to be due to this symbol in each .o file:

 W
shared::shared(toto()::{lambda()#1}&&)::{lambda()#1}>(toto()::{lambda()#1})::{lambda()#1}::~shared()

It is weak and global, but I think it should be local since it depends on
toto() which is static.

[Bug target/87213] New: ICE in final_scan_insn_1, at final.c:3070

[marxin at gcc dot gnu.org]

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

Bug ID: 87213
   Summary: ICE in final_scan_insn_1, at final.c:3070
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-linux-gnu

Following causes ICE:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr82001.c
-mno-direct-move -O3
xgcc: warning: ‘-mno-direct-move’ is deprecated
cc1: warning: ‘-mno-direct-move’ is deprecated
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr82001.c: In function
‘mulhi’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr82001.c:19:1: error:
could not split insn
19 | }
   | ^
(insn 15 10 16 (set (reg/i:DI 3 3)
(sign_extend:DI (reg:SI 32 0 [orig:124 a ] [124])))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr82001.c":19 38
{extendsidi2}
 (expr_list:REG_DEAD (reg:SI 32 0 [orig:124 a ] [124])
(nil)))
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr82001.c:19:1: internal
compiler error: in final_scan_insn_1, at final.c:3070
0x10e36a27 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x108a0cc7 final_scan_insn_1
../../gcc/final.c:3070
0x108a1187 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3149
0x1089dd7b final_1
../../gcc/final.c:2019
0x108a547f rest_of_handle_final
../../gcc/final.c:4660
0x108a599f execute
../../gcc/final.c:4734

[Bug fortran/87212] New: Declaration with array constructor: Error message on valid code

[juergen.reuter at desy dot de]

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

Bug ID: 87212
   Summary: Declaration with array constructor: Error message on
valid code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following is from c.l.f. Jan 26, 2018 but seems to never have been filed as
a bug report here (?), though Dominique d'Humieres presented a workaround for
the code below.
The following standard-conforming code is not parsed correctly by gfortran:
bug.f90:7:18:

7 |[(product([(j,j=1,i)]),i=0,13)]
  |  1
Error: Invalid character in name at (1)

The problem dates back to at least gfortran 5.4.

program bug
use ISO_FORTRAN_ENV
implicit none
integer i
integer(INT64) j
integer(INT64), parameter :: A(0:13) = &
[(product([(j,j=1,i)]),i=0,13)]
integer(INT64) B(0:13)
B = [(product([(j,j=1,i)]),i=0,13)]
write(*,*) 'A ='
write(*,*) A
write(*,*) 'B ='
write(*,*) B
end program bug

[Bug tree-optimization/87211] New: gcc ICE at O2: in set_ssa_val_to, at tree-ssa-sccvn.c:3628

[helloqirun at gmail dot com]

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

Bug ID: 87211
   Summary: gcc ICE at O2: in set_ssa_val_to, at
tree-ssa-sccvn.c:3628
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

It happens after the patch in r264069.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180903 (experimental) [trunk revision 264070] (GCC)


$ gcc-trunk -O2 abc.c -c
during GIMPLE pass: cunrolli
abc.c:7:6: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:3628
7 | void f() {
  |  ^
0x6cb479 set_ssa_val_to
../../gcc/gcc/tree-ssa-sccvn.c:3628
0xe6c8da visit_phi
../../gcc/gcc/tree-ssa-sccvn.c:4229
0xe6ce8f visit_stmt
../../gcc/gcc/tree-ssa-sccvn.c:4272
0xe6e9e8 process_bb
../../gcc/gcc/tree-ssa-sccvn.c:5890
0xe6fca9 do_rpo_vn
../../gcc/gcc/tree-ssa-sccvn.c:6421
0xe70a37 do_rpo_vn(function*, edge_def*, bitmap_head*)
../../gcc/gcc/tree-ssa-sccvn.c:6567
0xdf7de8 tree_unroll_loops_completely
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1479
0xdf7fd8 execute
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1655
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ cat abc.c
int a, b;
int c(int *d, int *e) {
  for (; b;)
d = e;
  return d;
}
void f() {
  for (;;) {
int *g[1];
int h = 0;
for (; h < 3; h++)
  g[0] = 
 == g[0] || i(c(g, g[0]));
  }
}