[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Yuri Gribov  ---
Cc Martin to comment, as he added the problematic part in
combine_predictions_for_bb.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Created attachment 41698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41698=edit
Draft patch (not working)

This can be added easily but I ran into a block in combine_predictions_for_bb
which resets predictions whenever block has more than one outgoing edge and
predictor is not strong enough (like e.g. noreturn predictor).

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

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #11 from Yuri Gribov  ---
Note that this is a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165

[Bug other/67165] please enable libbacktrace to work with compressed debug sections

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Patch under review here:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01868.html

[Bug fortran/81350] New: gfortran OpenMP taskloop segfaults or incorrect

[jeff.science at gmail dot com]

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

Bug ID: 81350
   Summary: gfortran OpenMP taskloop segfaults or incorrect
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Created attachment 41697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41697=edit
source code associated with bug

Code is correct with Intel 18 but generates erroneous results or segfaults with
GCC 7.1.

jrhammon-mac01:FORTRAN jrhammon$ ifort -std08 -fpp -g -O3 -xHOST -DRADIUS=2
-DSTAR -qopenmp stencil-taskloop-openmp.f90 -o stencil-taskloop-openmp-ifort

jrhammon-mac01:FORTRAN jrhammon$ gfortran-7 -std=f2008 -cpp -g -O3
-mtune=native -DRADIUS=2 -DSTAR -fopenmp stencil-taskloop-openmp.f90 -o
stencil-taskloop-openmp-gfortran

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-ifort 10 1000
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size= 1000
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
Solution validates
Rate (MFlops/s):   7787.263159 Avg time (s):  0.002420

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-gfortran 10 1000
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size= 1000
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
Segmentation fault: 11

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-ifort 10 100
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size=  100
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
Solution validates
Rate (MFlops/s):411.036158 Avg time (s):  0.000426

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-gfortran 10 100
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size=  100
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
ERROR: L1 norm =  0.00 Reference L1 norm = 22.00
Rate (MFlops/s):814.866756 Avg time (s):  0.000215

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

[Bug target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Note, the fix that introduced this patch has been back-ported to GCC 7.x, but
not GCC 6.x, so we will need a backport to GCC 7.2.

[Bug target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 41696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41696=edit
Proposed patch to fix the problem

[Bug target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-07
 CC||dje at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Michael Meissner  ---
It is a typo in the power9 splitter for loading up a short value to an Altivec
register, sign extending it in preparation for converting it to floating point.

If you look at rs6000.md around line 943, the splitter uses operands[1] (which
is a memory address), when it should use operands[0].

[Bug c++/81349] New: Classes with deleted constructor templates incorrectly labeled as non-aggregates

[eraz at umich dot edu]

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

Bug ID: 81349
   Summary: Classes with deleted constructor templates incorrectly
labeled as non-aggregates
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eraz at umich dot edu
  Target Milestone: ---

Simple test case (https://wandbox.org/permlink/HrAlAYZCEoJJMo1w):

#include 

struct S {
template 
S(T) = delete;
}

int main() {
static_assert(std::is_aggregate_v);
}

According to [dcl.init.aggr-1] (http://eel.is/c++draft/dcl.init.aggr#1), the
class `S` satisifes the requirements of an aggregate. The constructor template
is not user-provided since it is explicitly deleted on its first declaration
(http://eel.is/c++draft/dcl.fct.def.default#5.sentence-2). The rest of the
requirements are evidently satisfied.

Consequently, this bug manifests as an invalid selection of the constructor
template as an overload candidate when attempting aggregate initialization
(https://wandbox.org/permlink/jDwulQNsoAR5BIIT). This behavior can be observed
with every GCC version back to 4.7.3 compiled using the C++11 standard
(https://wandbox.org/permlink/5EvKUdxllToCDbYH). Though the requirements have
changed in C++17 from that in C++11 and C++14
(https://timsong-cpp.github.io/cppwp/n3337/dcl.init.aggr#1), the class still
satisfies the requirements but is treated as a non-aggregate type.

[Bug target/81348] New: PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2

[anton at samba dot org]

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

Bug ID: 81348
   Summary: PowerPC64: Code built with -mcpu=power9 hits SEGV in
RTL split2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux

I hit a SEGV with csmith, a cut down test case:

int a;
short b;
float ***c;

void d(void)
{
int e = 3;

if (a)
e = b;

***c = e;
}

# gcc -Og -mcpu=power9 crash1b.c

during RTL pass: split2
crash1b.c: In function ‘d’:
crash1b.c:13:1: internal compiler error: Segmentation fault
 }
 ^
0x109452d3 crash_signal
../../gcc/gcc/toplev.c:338
0x10440568 df_install_refs
../../gcc/gcc/df-scan.c:2379
0x10440707 df_refs_add_to_chains
../../gcc/gcc/df-scan.c:2424
0x10448ed3 df_insn_rescan(rtx_insn*)
../../gcc/gcc/df-scan.c:1091
0x104d8387 emit_insn_after_1
../../gcc/gcc/emit-rtl.c:4492
0x104d8387 emit_pattern_after_noloc
../../gcc/gcc/emit-rtl.c:4541
0x104d8603 emit_pattern_after_setloc
../../gcc/gcc/emit-rtl.c:4694
0x104d9a77 emit_insn_after_setloc(rtx_def*, rtx_def*, int)
../../gcc/gcc/emit-rtl.c:4739
0x104d9a77 try_split(rtx_def*, rtx_insn*, int)
../../gcc/gcc/emit-rtl.c:3839
0x10871d97 split_insn
../../gcc/gcc/recog.c:2889
0x10878107 split_all_insns()
../../gcc/gcc/recog.c:2978
0x10878177 rest_of_handle_split_before_sched2
../../gcc/gcc/recog.c:4018
0x10878177 execute
../../gcc/gcc/recog.c:4057

[Bug other/81345] -Wall resets -Wstringop-overflow to 1 from the default 2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00350.html

[Bug c++/81347] New: g++ confused by namespaces and friend classes

[thomasanderson at google dot com]

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

Bug ID: 81347
   Summary: g++ confused by namespaces and friend classes
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomasanderson at google dot com
  Target Milestone: ---

Created attachment 41695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41695=edit
Preprocessed test.cpp

Compile test.cpp below using libc++ headers:

-test.cpp-
#include 

class C {
  std::set s;
};

#include 

using std::map;
--

$ g++ -c test.cpp -nostdinc++ -isystem/path/to/libc++/trunk/include

g++ fails to compile and gives:
main.cpp:9:12: error: ‘map’ is already declared in this scope
 using std::map;

I've attached a preprocessed output for convenience.

$ g++ -c test_preproc.cpp 2>/dev/null && echo pass || echo fail
fail
$ clang++ -c test_preproc.cpp 2>/dev/null && echo pass || echo fail
pass

[Bug tree-optimization/81346] Missed constant propagation into comparison

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Most likely the optimization is in fold-const.c and has not been moved to
match.pd yet.

[Bug tree-optimization/81346] Missed constant propagation into comparison

[gergo.barany at inria dot fr]

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

--- Comment #1 from Gergö Barany  ---
Sorry, forgot to add the command line. I use gcc -O3 on all platforms

[Bug tree-optimization/81346] New: Missed constant propagation into comparison

[gergo.barany at inria dot fr]

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

Bug ID: 81346
   Summary: Missed constant propagation into comparison
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gergo.barany at inria dot fr
  Target Milestone: ---

Created attachment 41694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41694=edit
Input C file for triggering the issue

The attached C file contains the following function:

int fn1(int p1) {
  int b = (p1 / 12 == 6);
  return b;
}

As these are integers, the expression (p1 / 12 == 6) can be optimized to a
subtraction and an unsigned compare. GCC can do this (here for ARM):

fn1:
sub r0, r0, #72
cmp r0, #11
movhi   r0, #0
movls   r0, #1
bx  lr

The attached file also contains the following function:

int fn2(int p1) {
  int a = 6;
  int b = (p1 / 12 == a);
  return b;
}

This is equivalent to the above code; the value of a can only ever be 6.
Consequently, the output machine code should be equivalent. However, GCC does
not recognize the above pattern and generates more complex code:

fn2: 
movwr3, #43691
movtr3, 10922
smull   r2, r3, r3, r0
asr r0, r0, #31
rsb r0, r0, r3, asr #1
sub r0, r0, #6
clz r0, r0
lsr r0, r0, #5
bx  lr

I believe this is a target-independent optimization issue because x86-64 and
PowerPC behave analogously, for example (x86-64):

fn1:
subl$72, %edi
xorl%eax, %eax
cmpl$11, %edi
setbe   %al
ret

fn2:
movl%edi, %eax
movl$715827883, %edx
sarl$31, %edi
imull   %edx
xorl%eax, %eax
sarl%edx
subl%edi, %edx
cmpl$6, %edx
sete%al
ret

Version:
gcc version 8.0.0 20170706 (experimental) (GCC)
Configured with: --target=armv7a-eabihf --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float-abi=hard --with-float=hard
or
with: --target=x86_64-pc-linux-gnu
or
with: --target=ppc-eabi

[Bug other/81345] -Wall resets -Wstringop-overflow to 1 from the default 2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Version|8.0 |7.0
   Keywords||diagnostic
   Last reconfirmed||2017-07-06
  Component|driver  |other
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|-Wall resets default option |-Wall resets
   |arguments to 1  |-Wstringop-overflow to 1
   ||from the default 2

--- Comment #3 from Martin Sebor  ---
Doh!  Thanks for the hint!  This ability is already there in LangEnabledBy:

  LangEnabledBy(language, opt, posarg, negarg)

I expected the default LangEnabledBy setting to use the default value specified
by the Init() directive.

So it's a bug in the -Wstringop-overflow specification in the c.opt file.  It
should be:

Wstringop-overflow=
C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow)
Init(2) Warning LangEnabledBy(C ObjC C++ ObjC++, Wall, 2, 0) IntegerRange(0, 4)

With this it works as expected.

[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-06
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00345.html

[Bug fortran/81304] [5/6/7/8 Regression] Bogus warning with -Wsurprising and -fopenmp: Type specified for intrinsic function 'min' / 'max'

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Note that the bogus warning goes away when using scalar reduction variables:


program bogus_warning
   integer :: i
   real :: Dx_min, Dx_max
!$omp parallel do default(shared) private(i) reduction(min: Dx_min)
reduction(max: Dx_max)
   do i = 1,16
   end do
!$omp end parallel do
end

[Bug driver/81345] -Wall resets default option arguments to 1

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>LangEnabledBy(C ObjC C++ ObjC++, Wall)

Just says -Wall sets that variable to 1.  You might need to expand the awk
script to allow for an optional constant for the value you want.

[Bug driver/81345] -Wall resets default option arguments to 1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|-Wall resets|-Wall resets default option
   |-Wstringop-overflow to 1|arguments to 1
   |from the default 2  |

--- Comment #1 from Martin Sebor  ---
Applying the patch below makes it clear that -Wall resets the default option
argument to 1:

$ gcc -S -Wall -xc - 

[Bug fortran/70071] ICE on wrong usage of a subscript triplet

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on trunk with r250039. Since it's not a regression, I see no need for
backporting. Therefore I'll just close this PR.

[Bug fortran/70071] ICE on wrong usage of a subscript triplet

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Jul  6 19:49:33 2017
New Revision: 250039

URL: https://gcc.gnu.org/viewcvs?rev=250039=gcc=rev
Log:
2017-07-06  Harald Anlauf  

PR fortran/70071
* array.c (gfc_ref_dimen_size): Handle bad subscript triplets.


2017-07-06  Harald Anlauf  

PR fortran/70071
* gfortran.dg/coarray_44.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/coarray_44.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/81345] New: -Wall resets -Wstringop-overflow to 1 from the default 2

[msebor at gcc dot gnu.org]

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

Bug ID: 81345
   Summary: -Wall resets -Wstringop-overflow to 1 from the default
2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While debugging some new tests of mine I noticed that the
warn_stringop_overflow variable corresponding to the -Wstringop-overflow option
documented to default to 2 is actually set to 1 in the compiler when -Wall
alone is used.  That's wrong and it prevents the option from diagnosing a bunch
of instances of buffer overflow such as those where the destination is a member
array as in the test case below.

The option does appear to be set to 2 in c-family/c.opt as shown below so
something isn't working correctly there:

Wstringop-overflow
C ObjC C++ ObjC++ Warning Alias(Wstringop-overflow=, 2, 0)
...
Wstringop-overflow=
C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow)
Init(2) Warning LangEnabledBy(C ObjC C++ ObjC++, Wall) IntegerRange(0, 4)


The script below shows that when GCC is invoked with no warning options, both
instances of the warning are diagnosed as expected (that also implies that the
default -Wstringop-overflow=2 is in effect).  The same happens when
-Wstringop-overflow is on the command line.  But when -Wall is on the command
line alone, only one warning is issued because -Wstringop-overflow has been
reset to 1.

$ (set -x && cat t.c && for w in '' -Wstringop-overflow '-Wall'; do
/ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S $w t.c; done)+ cat
t.c
char a[3];

void f (const char *s)
{
  __builtin_strncpy (a, s, sizeof a + 1);
}

struct S { char a[3]; int i; };

void g (struct S *d, const char *s)
{
  __builtin_strncpy (d->a, s, sizeof d->a + 1);
}
+ for w in ''\'''\''' -Wstringop-overflow ''\''-Wall'\'''
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S t.c
t.c: In function ‘f’:
t.c:5:3: warning: ‘__builtin_strncpy’ writing 4 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (a, s, sizeof a + 1);
   ^~
t.c: In function ‘g’:
t.c:12:3: warning: ‘__builtin_strncpy’ writing 4 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (d->a, s, sizeof d->a + 1);
   ^~~~
+ for w in ''\'''\''' -Wstringop-overflow ''\''-Wall'\'''
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S
-Wstringop-overflow t.c
t.c: In function ‘f’:
t.c:5:3: warning: ‘__builtin_strncpy’ writing 4 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (a, s, sizeof a + 1);
   ^~
t.c: In function ‘g’:
t.c:12:3: warning: ‘__builtin_strncpy’ writing 4 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (d->a, s, sizeof d->a + 1);
   ^~~~
+ for w in ''\'''\''' -Wstringop-overflow ''\''-Wall'\'''
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S -Wall t.c
t.c: In function ‘f’:
t.c:5:3: warning: ‘__builtin_strncpy’ writing 4 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (a, s, sizeof a + 1);
   ^~

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
(still fixed, by the patch for bug 54769)

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Thu Jul  6 18:26:59 2017
New Revision: 250037

URL: https://gcc.gnu.org/viewcvs?rev=250037=gcc=rev
Log:
PR c++/81204 - parse error with dependent template-name
* parser.c (cp_parser_lookup_name): Revert previous change.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mem_fn2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Jul  6 18:27:05 2017
New Revision: 250038

URL: https://gcc.gnu.org/viewcvs?rev=250038=gcc=rev
Log:
PR c++/81204 - parse error with dependent template-name
* parser.c (cp_parser_lookup_name): Revert previous change.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/variadic-mem_fn2.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/parser.c

[Bug rtl-optimization/81340] ICE in compute_bb_dataflow, at var-tracking.c:6877

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #1 from Pat Haugen  ---
Started with r249960.

[Bug fortran/81344] New: Can't disable -ffpe-trap (or not documented)

[jellby at yahoo dot com]

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

Bug ID: 81344
   Summary: Can't disable -ffpe-trap (or not documented)
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jellby at yahoo dot com
  Target Milestone: ---

Once I enable a floating point exception trap with "-ffpe-trap=whatever", it
doesn't seem to be possible to disable it in the same command line (as it is
possible with warnings, for instance. An empty list as in "-ffpe-trap=" is
accepted, but it doesn't disable traps.

This would be useful when using a tool like CMake, where it is convenient to
set a default set of flags, and then override them if desired in specific
files, rather.

[Bug tree-optimization/81343] missing strlen optimization with intervening strcat of unknown strings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81330

--- Comment #1 from Martin Sebor  ---
See also pr81330 for another strlen optimization opportunity.

[Bug tree-optimization/81343] New: missing strlen optimization with intervening strcat of unknown strings

[msebor at gcc dot gnu.org]

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

Bug ID: 81343
   Summary: missing strlen optimization with intervening strcat of
unknown strings
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC is able to eliminate the second of a pair of strlen(src) with an unknown
string src even with an intervening call to strcpy(dst, src) with an unknown
dst.  This is possible because the strcpy call can be assumed not to modify the
source string.  However, GCC doesn't perform the same simplification when the
intervening call is one to strcat(dst, src), even though that call too can be
assumed not to modify str.  The test case below shows the difference.

From stepping through the code it looks to me like this is caused by the
handle_builtin_strcat() function in tree-ssa-strlen.c returning early in this
case, without retrieving the strinfo for the source string and setting the
dont_invalidate flag on it.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
typedef __SIZE_TYPE__ size_t;

void f (char *d, const char *s)
{
   size_t n0 = __builtin_strlen (s);

   __builtin_strcpy (d, s);

   size_t n1 = __builtin_strlen (s);   // call eliminated

   if (n0 != n1)
 __builtin_abort ();
}

void g (char *d, const char *s)
{
   size_t n0 = __builtin_strlen (s);

   __builtin_strcat (d, s);

   size_t n1 = __builtin_strlen (s);   // call not eliminated

   if (n0 != n1)
 __builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

f (char * d, const char * s)
{
  size_t n0;
  long unsigned int _8;

   [100.00%] [count: INV]:
  n0_3 = __builtin_strlen (s_2(D));
  _8 = n0_3 + 1;
  __builtin_memcpy (d_4(D), s_2(D), _8); [tail call]
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1823, cgraph_uid=1, symbol_order=1)

g (char * d, const char * s)
{
  size_t n1;
  size_t n0;

   [100.00%] [count: INV]:
  n0_3 = __builtin_strlen (s_2(D));
  __builtin_strcat (d_4(D), s_2(D));
  n1_6 = __builtin_strlen (s_2(D));
  if (n0_3 != n1_6)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

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

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

}

[Bug c/81342] New: LTO: lto1: internal compiler error: Segmentation fault

[anatol.pomozov at gmail dot com]

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

Bug ID: 81342
   Summary: LTO: lto1: internal compiler error: Segmentation fault
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anatol.pomozov at gmail dot com
  Target Milestone: ---

I am using the latest version of gcc (7.1.0 built using
https://github.com/travisg/toolchains on Ubuntu 14.04) and I have following
crash if I try to use LTO with my project. The crash happens when I run liner
stage:

/home/anatol/sources/toolchains/x86_64-elf-7.1.0-Linux-x86_64/bin/x86_64-elf-gcc
arch/x86/apic.o arch/x86/interrupt.o arch/x86/interrupt_handler.o
arch/x86/mmu.o arch/x86/multiboot1.o arch/x86/pit.o arch/x86/start.o
arch/x86/start_64.o arch/x86/vga_console.o core/mem.o core/printf.o
core/string.o core/app.o -o out/app.elf -g -ggdb -flto -nostdlib -ffreestanding
-std=c11 -fno-stack-protector -mno-red-zone -fno-common -W -Wall -Wextra -O3
-I./include -Wl,-n -Wl,--gc-sections -Wl,-Tarch/x86/linker.ld


Here is the message from gcc:



lto1: internal compiler error: Segmentation fault
0x994e8f crash_signal
../../gcc-7.1.0/gcc/toplev.c:337
0xb4205d streamer_get_pickled_tree(lto_input_block*, data_in*)
../../gcc-7.1.0/gcc/tree-streamer-in.c:
0x8785b4 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc-7.1.0/gcc/lto-streamer-in.c:1452
0x87880a lto_input_tree(lto_input_block*, data_in*)
../../gcc-7.1.0/gcc/lto-streamer-in.c:1492
0xb41e97 lto_input_ts_decl_minimal_tree_pointers
../../gcc-7.1.0/gcc/tree-streamer-in.c:695
0xb41e97 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../gcc-7.1.0/gcc/tree-streamer-in.c:1051
0x877edf lto_read_tree_1
../../gcc-7.1.0/gcc/lto-streamer-in.c:1333
0x878498 lto_read_tree
../../gcc-7.1.0/gcc/lto-streamer-in.c:1363
0x878498 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc-7.1.0/gcc/lto-streamer-in.c:1475
0x878779 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
../../gcc-7.1.0/gcc/lto-streamer-in.c:1387
0x5eaa3e lto_read_decls
../../gcc-7.1.0/gcc/lto/lto.c:1696
0x5ec41e lto_file_finalize
../../gcc-7.1.0/gcc/lto/lto.c:2040
0x5ec41e lto_create_files_from_ids
../../gcc-7.1.0/gcc/lto/lto.c:2050
0x5ec41e lto_file_read
../../gcc-7.1.0/gcc/lto/lto.c:2091
0x5ec41e read_cgraph_and_symbols
../../gcc-7.1.0/gcc/lto/lto.c:2803
0x5ec41e lto_main()
../../gcc-7.1.0/gcc/lto/lto.c:3308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error:
/usr/local/google/home/anatol/sources/toolchains/x86_64-elf-7.1.0-Linux-x86_64/bin/x86_64-elf-gcc
returned 1 exit status
compilation terminated.
/mnt/cold/sources/toolchains/x86_64-elf-7.1.0-Linux-x86_64/bin/../lib/gcc/x86_64-elf/7.1.0/../../../../x86_64-elf/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug fortran/81341] New: trunk/gcc/fortran/class.c:313: redundant condition ?

[dcb314 at hotmail dot com]

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

Bug ID: 81341
   Summary: trunk/gcc/fortran/class.c:313: redundant condition ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/fortran/class.c:313] -> [trunk/gcc/fortran/class.c:310]: (style) Same
expression on both sides of '&&'.

  else if (ref->next && ref->next->type == REF_ARRAY
&& !ref->next->next
&& ref->type == REF_COMPONENT
&& ref->next->type == REF_ARRAY
&& ref->next->u.ar.type != AR_ELEMENT)

[Bug libgcc/70800] libgcc/config/libbid/bid_binarydecimal.c: suspicious comparison ?

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
I just discovered that clang++ can be made to find this bug by
adding flag -Wtautological-compare.

jan22a.cc:6:17: warning: bitwise comparison always
  evaluates to false [-Wtautological-compare]
if ((n & 0x30) == 1)
~~~^~~~

[Bug libgcc/70800] libgcc/config/libbid/bid_binarydecimal.c: suspicious comparison ?

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Number of bugs found by this enhancement in the Linux kernel up
from six to eight.

[Bug rtl-optimization/81340] New: ICE in compute_bb_dataflow, at var-tracking.c:6877

[pthaugen at gcc dot gnu.org]

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

Bug ID: 81340
   Summary: ICE in compute_bb_dataflow, at var-tracking.c:6877
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

$ cat table_cache.ii
class a {
  struct b {
b(int, int);
  } c;

public:
  int d;
  a(char *) : c(0, d) {}
};
class e {
  int f(const int &, const int &, const int &, bool, bool, bool, int, bool);
};
class g {
public:
  static g *h();
  void i(a, void *);
};
int e::f(const int &, const int &, const int &, bool j, bool, bool, int, bool)
{
  g::h()->i("", );
}


$ ~/install/gcc/trunk/bin/g++ -S -O2 -g -fsanitize=address table_cache.ii
table_cache.ii: In member function ‘int e::f(const int&, const int&, const
int&, bool, bool, bool, int, bool)’:
table_cache.ii:19:19: warning: ISO C++ forbids converting a string constant to
‘char*’ [-Wwrite-strings]
   g::h()->i("", );
   ^
during RTL pass: vartrack
table_cache.ii:20:1: internal compiler error: in compute_bb_dataflow, at
var-tracking.c:6877
 }
 ^
0x10f691af compute_bb_dataflow
/home/pthaugen/src/gcc/trunk/gcc/gcc/var-tracking.c:6877
0x10f696d3 vt_find_locations
/home/pthaugen/src/gcc/trunk/gcc/gcc/var-tracking.c:7118
0x10f6a3a3 variable_tracking_main_1
/home/pthaugen/src/gcc/trunk/gcc/gcc/var-tracking.c:10332
0x10f6a3a3 variable_tracking_main()
/home/pthaugen/src/gcc/trunk/gcc/gcc/var-tracking.c:10378
0x10f6a3a3 execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/var-tracking.c:10415
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/81305] [avr] avrtiny uses LDS for SREG in ISR routines which is out of range of LDS.

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
Author: gjl
Date: Thu Jul  6 15:31:42 2017
New Revision: 250029

URL: https://gcc.gnu.org/viewcvs?rev=250029=gcc=rev
Log:
PR target/81305
* gcc.target/avr/isr-test.h: Fix warnings.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/avr/isr-test.h

[Bug c++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
(In reply to Martin Liška from comment #4)
Thanks; that seems to a slightly different issue, but we may as well keep this
bug open for tracking it.

Am investigating.

It appears to be here, within maybe_unwind_expanded_macro_loc:
212 source_location resolved_exp_loc =
213   linemap_resolve_location (line_table,
214 MACRO_MAP_EXPANSION_POINT_LOCATION
(iter->map),
215 LRK_MACRO_DEFINITION_LOCATION,
NULL);

where:

MACRO_MAP_EXPANSION_POINT_LOCATION (iter->map) is 0x8001:

(gdb) call inform (0x8001, "")
tc.cpp:2:1: note: 
 MOZALLOC_THROW_BAD_ALLOC_IF_HAS_EXCEPTIONS
 ^~

but resolved_exp_loc is 164736:

(gdb) call inform (164736, "")
tc.cpp:2:1: note: 
 MOZALLOC_THROW_BAD_ALLOC_IF_HAS_EXCEPTIONS
 ^

so the call to linemap_resolve_location seems to be stripping off the range
information.

[Bug tree-optimization/81330] missing strlen optimization with intervening memcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Martin Sebor  ---
You're right, I didn't consider this case.  When copying (strlen(s) + 1) or
more bytes, d cannot point at the terminating NUL at (s + strlen(s)) because
the copy would then overlap, so the transformation is only valid for such
copies.  When copying fewer bytes than that (or when the number is unknown), it
would not be valid.  Thanks for clarifying that!

So the missed optimization opportunity is in the "or more bytes" case, when GCC
can also assume the NUL isn't overwritten.  I.e., a test case for it would be
the same as the original in comment #0 except with a call to __builtin_memcpy
(d, s, n0 + 2) in g() (or any constant or known N greater than 1).

Btw., the comment above handle_builtin_memcpy() in tree-ssa-strlen.c copied
below hints that the constraint is deliberate but it doesn't explain why.  I'll
see about adding some detail to it since I happen to be working in this area.

/* Handle a memcpy-like ({mem{,p}cpy,__mem{,p}cpy_chk}) call.
   If strlen of the second argument is known and length of the third argument
   is that plus one, strlen of the first argument is the same after this
   call.  */

[Bug libstdc++/81338] stringstream remains empty after being moved into multiple times

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The problem is that basic_stringbuf::overflow assumes that if pptr() == epptr()
then we need to reallocate.

After a move we might have pptr() == epptr() but also have unused capacity in
the string. We should move epptr() to use that capacity, instead we reallocate
to double the string's capacity, which keeps trying to allocate bigger and
bigger buffers until allocation fails.

[Bug c++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
The commit in comment #5 is a slightly reworked version of the candidate patch
from comment #2:
  https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00330.html

[Bug c++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jul  6 14:17:24 2017
New Revision: 250022

URL: https://gcc.gnu.org/viewcvs?rev=250022=gcc=rev
Log:
diagnostics: fix end-points of ranges within macros (PR c++/79300)

gcc/ChangeLog:
PR c++/79300
* diagnostic-show-locus.c (layout::layout): Use start and finish
spelling location for the start and finish of each range.
* genmatch.c (linemap_client_expand_location_to_spelling_point):
Add unused aspect param.
* input.c (expand_location_1): Add "aspect" param, and use it
to access the correct part of the location.
(expand_location): Pass LOCATION_ASPECT_CARET to new param of
expand_location_1.
(expand_location_to_spelling_point): Likewise.
(linemap_client_expand_location_to_spelling_point): Add "aspect"
param, and pass it to expand_location_1.

gcc/testsuite/ChangeLog:
PR c++/79300
* c-c++-common/Wmisleading-indentation-3.c (fn_14): Update
expected underlining within macro expansion.
* c-c++-common/pr70264.c: Likewise.
* g++.dg/plugin/diagnostic-test-expressions-1.C
(test_within_macro_1): New test.
(test_within_macro_2): Likewise.
(test_within_macro_3): Likewise.
(test_within_macro_4): Likewise.
* gcc.dg/format/diagnostic-ranges.c (test_macro_3): Update
expected underlining within macro expansion.
(test_macro_4): Likewise.
* gcc.dg/plugin/diagnostic-test-expressions-1.c
(test_within_macro_1): New test.
(test_within_macro_2): Likewise.
(test_within_macro_3): Likewise.
(test_within_macro_4): Likewise.
* gcc.dg/spellcheck-fields-2.c (test_macro): Update expected
underlining within macro expansion.

libcpp/ChangeLog:
PR c++/79300
* include/line-map.h (enum location_aspect): New enum.
(linemap_client_expand_location_to_spelling_point): Add
enum location_aspect param.
* line-map.c (rich_location::get_expanded_location): Update for
new param of linemap_client_expand_location_to_spelling_point.
(rich_location::maybe_add_fixit): Likewise.
(fixit_hint::affects_line_p): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/genmatch.c
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation-3.c
trunk/gcc/testsuite/c-c++-common/pr70264.c
trunk/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
trunk/gcc/testsuite/gcc.dg/format/diagnostic-ranges.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c
trunk/gcc/testsuite/gcc.dg/spellcheck-fields-2.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug c++/81339] New: no error for invalid decltype(T()) expression in immediate context

[redi at gcc dot gnu.org]

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

Bug ID: 81339
   Summary: no error for invalid decltype(T()) expression in
immediate context
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct true_type { static const bool value = true; };
struct false_type { static const bool value = false; };

template 
struct IsDefaultConstructibleT
{
// using T here (instead of U) should be an error
template 
  static true_type test(void*);

template 
  static false_type test(...);

static constexpr bool value = decltype(test(nullptr))::value;
};

struct S {
  S() = delete;
};

static_assert( IsDefaultConstructibleT::value, "" ); // wrong

This should fail to compile, because T() is invalid, and is not a substitution
failure, but GCC compiles it, and even selects the true_type overload (so the
static assertion passes, which is doubly wrong).

Clang says:

n.cc:8:47: error: call to deleted constructor of 'S'
template 
  ^
n.cc:21:16: note: in instantiation of template class
'IsDefaultConstructibleT' requested here
static_assert( IsDefaultConstructibleT::value, "" );
   ^
n.cc:18:3: note: 'S' has been explicitly marked deleted here
  S() = delete;
  ^
n.cc:21:1: error: static_assert failed ""
static_assert( IsDefaultConstructibleT::value, "" );
^  ~
2 errors generated.

And EDG says:

"n.cc", line 8: error: the default constructor of "S" cannot be referenced --
  it is a deleted function
  template 
^
  detected during instantiation of class "IsDefaultConstructibleT
[with T=S]" at line 21

1 error detected in the compilation of "n.cc".

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
oh, sorry r299923 FAIL

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
r299904 PASS
r299023 FAIL

~/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=yes --disable-multilib --enable-languages=c,c++

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[akim.demaille at gmail dot com]

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

--- Comment #11 from Akim Demaille  ---
The project I work on has this:

auto const f = std::bind(::operator (),
 , std::ref(args)...);

instead of a simple lambda.

--- Comment #12 from Akim Demaille  ---
The project I work on has this:

auto const f = std::bind(::operator (),
 , std::ref(args)...);

instead of a simple lambda.

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[akim.demaille at gmail dot com]

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

--- Comment #11 from Akim Demaille  ---
The project I work on has this:

auto const f = std::bind(::operator (),
 , std::ref(args)...);

instead of a simple lambda.

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[kretz at kde dot org]

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

Matthias Kretz  changed:

   What|Removed |Added

 CC||kretz at kde dot org

--- Comment #10 from Matthias Kretz  ---
I have the following in my code now:

// this could be much simpler:
//
// return {V([&](auto i) { return x[i + Indexes * V::size()]; })...};   
//
// Sadly GCC has a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226.
The 
// following works around it by placing the pack outside of the code block
of the 
// lambda:  
return {[](size_t j, const datapar ) {  
return V([&](auto i) { return y[i + j * V::size()]; }); 
}(Indexes, x)...};

[Bug tree-optimization/81330] missing strlen optimization with intervening memcpy

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Wed, 5 Jul 2017, msebor at gcc dot gnu.org wrote:

> GCC eliminates redundant calls to strlen() with intervening calls to strcpy 
> but
> it misses an opportunity to do the same when the intervening call is to memcpy
> instead.  In the test case below, since both strcpy and memcpy require that 
> the
> copies do not overlap, it's safe to assume that neither call modifies any part
> of the source string, including the terminating nul, and so the second strlen
> call can be replaced with the result of the first in both functions, not just
> in f().  The strlen dump shows that GCC doesn't take advantage of this
> guarantee in the memcpy case.
> 
> (The second strlen call in g is replaced with the result of the first in g 
> when
> memcpy is passed n0 + 1 as the size but I don't see why that should make a
> difference.)

I don't see the basis for the optimization with memcpy being safe without 
n0 + 1 as size.  If the size is n0, it's perfectly legitimate for d to 
point to the terminating NUL, as in that case the memcpy arguments are 
adjacent but nonoverlapping blocks of n0 bytes in memory.

[Bug ada/81328] error messages not in expected order

[porton at narod dot ru]

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

Victor Porton  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #3 from Victor Porton  ---
www.ads should be considered before www.adb in "source location", but GNAT
wrongly displays a www.adb error before www.ads. Reopening.

[Bug libstdc++/81338] stringstream remains empty after being moved into multiple times

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-06
 Ever confirmed|0   |1
  Known to fail||6.3.0, 7.1.0, 8.0

[Bug c++/81338] New: stringstream remains empty after being moved into multiple times

[zxy19980101 at sina dot cn]

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

Bug ID: 81338
   Summary: stringstream remains empty after being moved into
multiple times
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zxy19980101 at sina dot cn
  Target Milestone: ---

Given the code below:

#include 
#include 

int main() {
std::stringstream ss;
while (true) {
for (int i = rand() % 10 + 10; i > 0; --i) {
ss << static_cast(rand() % 26 + 'a');
}
std::cout << ss.str() << "\n";
ss = std::stringstream();
}
return 0;
}

The output become blank lines after the first few. The code works on visual
studio 2017.

My g++ version is:

g++.exe (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 6.3.0
Copyright (C) 2016 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.

[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||oivulf at gmail dot com

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

[Bug fortran/79492] LHS reallocation, intrinsic function RHS, and -fcheck=all

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of pr52162.

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

[Bug target/71112] [6 Regression] ICE with -fpie on aarch64 ILP32 big-endian

[hs.naveen2u at gmail dot com]

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

--- Comment #11 from hs.naveen2u at gmail dot com ---
Committed to gcc-6-branch as
https://gcc.gnu.org/viewcvs/gcc?view=revision=250014

[Bug target/71112] [6 Regression] ICE with -fpie on aarch64 ILP32 big-endian

[hs.naveen2u at gmail dot com]

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

--- Comment #10 from hs.naveen2u at gmail dot com ---
Committed to gcc-6-branch as
https://gcc.gnu.org/viewcvs/gcc?view=revision=250014

[Bug c++/81337] New: g++.dg/gcov/pr16855.C etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 81337
   Summary: g++.dg/gcov/pr16855.C etc. FAIL
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jason at gcc dot gnu.org, marxin at gcc dot gnu.org,
nathan at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.12, *-*-darwin*, *-*-freebsd*

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

g++.dg/gcov/pr16855.C and it's companion g++.dg/gcov/pr16855-priority.C for 
targets with constructor priority support have been FAILing on Solaris 12 only
(it does work on Solaris 10 and 11) since they were first added:

FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++11  gcov: 1 failures in line
counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate
format
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++11  line 22: is #:should be
1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++14  gcov: 1 failures in line
counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate
format
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++14  line 22: is #:should be
1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  gcov: 1 failures in line
counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate
format
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 22: is #:should be
1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  gcov: 1 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  gcov: 1 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 21: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  gcov: 1 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 21: is #:should be 1

I've finally managed to investigate what's going on and the result may point to
an issue with destructor handling beyond just this testcase.

I've managed to produce a reduced testcase that shows the underlying issue:

$ g++ -c prio2.C
$ gcc -o prio2 prio2.o -lsupc++

(I'm linking with gcc and libsupc++ to avoid having to deal with the libstdc++
destructors during investigation.)

On Solaris 12, the testcase produces

In dtor
In Test::~Test

while on Linux (and on Solaris 11 which lacks __cxa_atexit or Solaris 12 with
-fno-use-cxa-atexit) you get

In Test::~Test
In dtor

On Solaris 12 with -fuse-cxa-atexit (the default):

* Test::~Test() is registered via

  .init_array
  -> _GLOBAL__sub_I_T1
  -> __static_initialization_and_destruction_0(1, 65535)
  -> __cxa_atexit(Test::~Test(), , &__dso_handle);

* dtor() is called from

  .fini_array

Init/Fini Array Section:  .init_array
  index  value derived-address  name
[0]  0x80552e0   0x80552e0  frame_dummy
[1]  0x8055348   0x8055348  _GLOBAL__sub_I_T1
[2]  0x8056b60   0x8056b60  _GLOBAL__sub_I_eh_alloc.cc

Init/Fini Array Section:  .fini_array
  index  value derived-address  name
[0]  0x80552b0   0x80552b0  __do_global_dtors_aux
[1]  0x80552f7   0x80552f7  _ZL4dtorv [dtor()]

  During execution, here are the relevant atexit and __cxa_atexit calls:

  __cxa_atexit(_ZN4TestD2Ev)

#0  0xfe1bd348 in __cxa_atexit () from /lib/libc.so.1
#1  0x08055342 in __static_initialization_and_destruction_0(int, int) ()
#2  0x0805535d in _GLOBAL__sub_I_T1 ()
#3  0xfe6b046b in call_array () from /usr/lib/ld.so.1
#4  0xfe6b0636 in call_init () from /usr/lib/ld.so.1

  atexit(atexit_fini)

#0  0xfe1bd327 in atexit () from /lib/libc.so.1
#1  0x080551a3 in __start_crt ()
#2  0x0805514c in _start ()

  Here's the order and call stack of both destructors:

  dtor() called:

#0  0x080552fd in dtor() ()
#1  0xfe6b046b in call_array () from /usr/lib/ld.so.1
#2  0xfe6b082e in call_fini () from /usr/lib/ld.so.1
#3  0xfe6b0a32 in atexit_fini () from /usr/lib/ld.so.1
#4  0xfe1bd4e5 in _exithandle () from /lib/libc.so.1
#5  0xfe1aefa2 in exit () from /lib/libc.so.1
#6  0x08055171 in _start ()

  Test::~Test() called:

#0  0x08055368 in Test::~Test() ()
#1  0xfe1bd4dd in _exithandle () from /lib/libc.so.1
#2  0xfe1aefa2 in exit () from /lib/libc.so.1
#3  0x08055171 in _start ()

  So we have this registration order:

  __cxa_atexit(Test::~Test())  
  atexit(atexit_fini)

  ... and as expected the reverse call order:

  atexit_fini
  dtor()
  Test::~Test()

* On Solaris 11 or Solaris 12 with -fno-use-cxa-atexit:

** Test::~Test() is called like this:

   .fini_array
   -> 

[Bug libgomp/81336] New: OpenMP crash if -fno-underscoring is used in gfortran

[bburgerm at googlemail dot com]

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

Bug ID: 81336
   Summary: OpenMP crash if -fno-underscoring is used in gfortran
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bburgerm at googlemail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41692=edit
Test executable to show the bug

If I use OpenMP nested locks in Fortran code which is compiled with the
"-fno-underscoring" option invalid memory is accessed which leads to incorrect
results or crashes.

The attached program shows the problem at least on linux (32 and 64 bits). If
compiled with "-fopenmp -fno-underscoring" the second element of the array is
modified during omp_init_nest_lock. If "-fno-underscoring" is omitted the
result is OK. Same bug is visible with gfortran 4.9.2.

I have read the warning about usage of -fno-underscoring, but it talks about
possible incompatibilities with system libraries. At least libraries shipped
with gfortran should work correctly in this case.

I could track down the problem to the OpenMP library which has a different
interface for C and Fortran:
- C uses the symbol "omp_init_nest_lock" is used and expects as argument a
pointer to a 16 byte structure.
- Fortran uses with default options "omp_init_nest_lock_" which expects a
pointer to a 8 byte integer which is used as a pointer to the 16 byte
structure.
If -fno-underscoring is used Fortran uses incorrectly the C version with a
different interface.

As workaround I used explicit iso_c_binding interfaces as this is currently the
only method to tell gfortran the symbol name to use independent of program
options:

  use iso_c_binding, only : c_int64_t

  integer, parameter :: omp_nest_lock_kind = c_int64_t

  interface
 subroutine omp_init_nest_lock(nvar)
 +  bind(C,name='omp_init_nest_lock_')
 import omp_nest_lock_kind
 integer(omp_nest_lock_kind), intent(  out) :: nvar
 end subroutine omp_init_nest_lock
  end interface
  ... for omp_destroy_nest_lock, set and unset

A possible solution would be to use this interface in omp_lib.f90 (but
unfortunately not in omp_lib.h because of strict C interoperability checks of
gfortran)

[Bug ada/81328] error messages not in expected order

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Arnaud Charlet  ---
GNAT always orders messages by source location, so this will simply not happen,
closing.

[Bug bootstrap/81335] New: [gcc8] missing stage3 dependency for insn-modes-inline.h

[dimhen at gmail dot com]

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

Bug ID: 81335
   Summary: [gcc8] missing stage3 dependency for
insn-modes-inline.h
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

with r249967 and make -j5 and 4-core CPU

I receive

coretypes.h:367:10: fatal error: insn-modes-inline.h: No such file or directory

after restart, `make' works w/o errors.

Sounds like missing dependence in stage3/Makefile?


mv tmp2-tm.texi tmp-tm.texi
/bin/sh /home/dimhen/src/r249967_gcc/gcc/../move-if-change tmp-tm.texi tm.texi
build/genmodes -h > tmp-modes.h
/bin/sh /home/dimhen/src/r249967_gcc/gcc/../move-if-change tmp-modes.h
insn-modes.h
echo timestamp > s-modes-h
build/genmodes -i > tmp-modes-inline.h
/bin/sh /home/dimhen/src/r249967_gcc/gcc/../move-if-change tmp-modes-inline.h \
  insn-modes-inline.h
/home/dimhen/build/r249967_gcc/./prev-gcc/xg++
-B/home/dimhen/build/r249967_gcc/./prev-gcc/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/dimhen/build/r249967_gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/dimhen/build/r249967_gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/dimhen/build/r249967_gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/home/dimhen/build/r249967_gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/dimhen/src/r249967_gcc/libstdc++-v3/libsupc++
-L/home/dimhen/build/r249967_gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/dimhen/build/r249967_gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I.
-Ibuild -I/home/dimhen/src/r249967_gcc/gcc
-I/home/dimhen/src/r249967_gcc/gcc/build
-I/home/dimhen/src/r249967_gcc/gcc/../include 
-I/home/dimhen/src/r249967_gcc/gcc/../libcpp/include  \
-o build/min-insn-modes.o min-insn-modes.c
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --split-size=500
--no-split -I . -I /home/dimhen/src/r249967_gcc/gcc/doc \
-I /home/dimhen/src/r249967_gcc/gcc/doc/include -o
doc/gccint.info /home/dimhen/src/r249967_gcc/gcc/doc/gccint.texi; \
fi
echo timestamp > s-modes-inline-h
In file included from min-insn-modes.c:6:0:
/home/dimhen/src/r249967_gcc/gcc/coretypes.h:367:10: fatal error:
insn-modes-inline.h: No such file or directory
 #include "insn-modes-inline.h"
  ^
compilation terminated.
make[3]: *** [Makefile:2611: build/min-insn-modes.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-tool.pod
gcov-dump.pod
make[3]: Leaving directory '/home/dimhen/build/r249967_gcc/gcc'
make[2]: *** [Makefile:4727: all-stage3-gcc] Error 2
make[2]: Leaving directory '/home/dimhen/build/r249967_gcc'
make[1]: *** [Makefile:27611: stage3-bubble] Error 2
make[1]: Leaving directory '/home/dimhen/build/r249967_gcc'
make: *** [Makefile:956: all] Error 2


gcc build was configured as

/home/dimhen/src/r249967_gcc/configure --prefix=/usr/local/gcc_current
--enable-checking=release --enable-languages=c,c++,lto --disable-multilib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic

[Bug ada/81328] error messages not in expected order

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-06
 CC||ebotcazou at gcc dot gnu.org
Summary|Wrong order of error|error messages not in
   |messages|expected order
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Botcazou  ---
> GNAT provides an error list for my erroneous input in wrong order.

No, it's not "wrong", it's just the natural order of the source code, which is
perfectly reasonable.

> I sent a minimized code where this is not a problem, but I got this GNAT
> behavior in real code, what lead me to try to first fix the first error
> (which in reality was caused by the second error), but it was unexpected
> that to fix the first error I first need to fix the second error.

And you didn't manage to fix your code in the end?

> The output order of compilation errors should be such that the programmer
> would be able to fix the errors in the order of compiler output, rather than
> to make the programmer to guess that he needs first look into the next error.

This sounds interesting, albeit probably a lot of work so will never happen.