[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[ouster at cs dot stanford.edu]

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

John Ousterhout  changed:

   What|Removed |Added

 CC||ouster at cs dot stanford.edu

--- Comment #10 from John Ousterhout  ---
I accidentally posted this on issue 26461, so I'm reposting here; sorry for the
duplicate...

Kernel threads are great, and it may seem like there's no need for user-level
threads now that kernel threads are universally available. But layering
user-level threads on top of kernel threads can offer a speedup of at least 10x
for common operations. The fact that so many different people have responded on
this issue and issue 26461 is pretty good evidence that it can be useful to do
"context switching" on top of kernel threads. My research group has recently
run up against this same problem. Thread-local variables (i.e.
kernel-thread-locals) are still useful in this environment (for example, we use
one to keep track of the user thread that's loaded on the current kernel
thread).

One of the great things about gcc is that it has supported a huge variety of
applications and design styles; it would be a shame for gcc to preclude this
particular class of applications.

Is it unreasonably difficult to add a mechanism to force gcc to flush cached
thread-local addresses? Those of us using the mechanism would be happy to pay a
small performance penalty for it, but presumably that won't affect applications
that don't use the mechanism.

Please reconsider?

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[amodra at gmail dot com]

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

--- Comment #19 from Alan Modra  ---
Yes, r246294 powerpc64le-linux-gcc -O1 -misel ICEs on the last testcase.  An
earlier compiler I had laying around, 7.0.0 20160616, does not.

[Bug fortran/80257] Cygwin test fail: pointer_check_1.f90 output test

[nightstrike at gmail dot com]

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

--- Comment #3 from nightstrike  ---
$ ./test.exe

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x in ???
#1  0x in ???
#2  0x in ???
#3  0x in ???
#4  0x in ???
#5  0x in ???
#6  0x in ???
#7  0x in ???
#8  0x in ???
Segmentation fault (core dumped)

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-31
  Known to work||6.3.0
Summary|Compiling aborts when   |[7 Regression] Compiling
   |template/auto/lambda occur  |aborts when
   |in some way |template/auto/lambda occur
   ||in some way
 Ever confirmed|0   |1
  Known to fail||7.0

[Bug middle-end/26461] liveness of thread local references across function calls

[ouster at cs dot stanford.edu]

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

John Ousterhout  changed:

   What|Removed |Added

 CC||ouster at cs dot stanford.edu

--- Comment #13 from John Ousterhout  ---
Kernel threads are great, and it may seem like there's no need for user-level
threads now that kernel threads are universally available. But layering
user-level threads on top of kernel threads can offer a speedup of at least 10x
for common operations. The fact that so many different people have responded on
this issue and issue 26461 is pretty good evidence that it can be useful to do
"context switching" on top of kernel threads. My research group has recently
run up against this same problem. Thread-local variables (i.e.
kernel-thread-locals) are still useful in this environment (for example, we use
one to keep track of the user thread that's loaded on the current kernel
thread).

One of the great things about gcc is that it has supported a huge variety of
applications and design styles; it would be a shame for gcc to preclude this
particular class of applications.

Is it unreasonably difficult to add a mechanism to force gcc to flush cached
thread-local addresses? Those of us using the mechanism would be happy to pay a
small performance penalty for it, but presumably that won't affect applications
that don't use the mechanism.

Please reconsider?

[Bug c++/80268] New: [concepts] list of candidates for ambiguous call includes unconstrained function

[redi at gcc dot gnu.org]

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

Bug ID: 80268
   Summary: [concepts] list of candidates for ambiguous call
includes unconstrained function
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This rightly fails to compile with -fconcepts:

template
  inline constexpr bool is_int_sized = sizeof(T) == sizeof(int);

template
  inline constexpr bool is_signed = (T(-1) < T(0));

template void func(T) { }

template void func(T) requires is_int_sized { }

template void func(T) requires is_signed { }

int main()
{
  func(1);
}

ambig.cc: In function ‘int main()’:
ambig.cc:15:9: error: call of overloaded ‘func(int)’ is ambiguous
   func(1);
 ^
ambig.cc:7:27: note: candidate: void func(T) [with T = int]
 template void func(T) { }
   ^~~~
ambig.cc:9:27: note: candidate: void func(T) requires  is_int_sized [with T
= int]
 template void func(T) requires is_int_sized { }
   ^~~~
ambig.cc:11:27: note: candidate: void func(T) requires  is_signed [with T =
int]
 template void func(T) requires is_signed { }
   ^~~~

I think showing the first candidate in the error isn't very useful. The
ambiguity is between the 2nd and 3rd overloads, because neither is more
constrained than the other. But both are more constrained than the first, and
it would never be chosen as the best match if only one of the others was a
candidate (rather than both).

I know we'd show all candidates in an unconstrained case, but I wonder if we
should do things differently for constrained functions.

[Bug testsuite/43496] gcc.target/powerpc/gcse-1.c fails on powerpc-unknown-linux-gnu with -fpic/-fPIC

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed on trunk.  No backport planned, please reopen if you want one.

[Bug rtl-optimization/80134] powerpc: loop on p[i] and *p++ should give the same code

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Segher Boessenkool  ---
This is a duplicate of PR67288 (and many others).

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

[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
*** Bug 80134 has been marked as a duplicate of this bug. ***

[Bug target/80132] powerpc: irrelevant register move before operation

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Segher Boessenkool  ---
This works fine on trunk.  Closing this PR.  If you want whatever fixed
it backported, please identify what change fixed it.

[Bug testsuite/80056] gcc.dg/tree-prof/pr66295.c fails on powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Segher Boessenkool  ---
I fixed this in r246206 (wasn't aware of this PR).

[Bug target/17593] Over Aggressive Speculative Code Motion

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Segher Boessenkool  ---
Since at least 4.9 only two registers are stored on the frame, and
there is no frame at all for the early exits.  I don't see any weird
speculative movement either.  Let's close this bug.

[Bug c++/80267] New: Compiling aborts when template/auto/lambda occur in some way

[s-beyer at gmx dot net]

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

Bug ID: 80267
   Summary: Compiling aborts when template/auto/lambda occur in
some way
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s-beyer at gmx dot net
  Target Milestone: ---

Hi,

g++ 7.0.1 asks me for reporting a bug, so I do it.

I have the following minimal example:

$ cat gcc-bug.cpp 
#include 

struct Outer {
  struct Inner {
void func();
  };

  const Inner () const;
  Inner ();
};

void run(std::function func) { func(); }

template void test() {
  Outer ocm;
  auto  = ocm.inner();

  run([&]() {
inner.func();
run([&]() { inner.func(); });
  });
}

int main() { test(); };


And the following happens with g++ 7.0.1

$ g++-7 --version
g++-7 (Debian 7-20170302-1) 7.0.1 20170302 (experimental) [trunk revision
245832]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-7 -c gcc-bug.cpp && echo GOOD
gcc-bug.cpp: In instantiation of ‘test():::: [with T =
bool]’:
gcc-bug.cpp:20:11:   required from ‘struct test():: [with T =
bool]::’
gcc-bug.cpp:20:8:   required from ‘test():: [with T = bool]’
gcc-bug.cpp:18:9:   required from ‘struct test() [with T = bool]::’
gcc-bug.cpp:18:6:   required from ‘void test() [with T = bool]’
gcc-bug.cpp:24:25:   required from here
gcc-bug.cpp:20:17: internal compiler error: in tsubst_copy, at cp/pt.c:14589
 run([&]() { inner.func(); });
 ^
0x5e9c2c tsubst_copy
../../src/gcc/cp/pt.c:14587
0x5ed9fe tsubst_copy
../../src/gcc/cp/pt.c:14414
0x5ed9fe tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17727
0x5ed868 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16665
0x5ed8e1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17507
0x5ed49e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17128
0x5e6a27 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16446
0x5e5485 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15711
0x5e6853 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15923
0x5e6853 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15923
0x5e4ef6 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.c:22874
0x5fcfcd instantiate_class_template_1
../../src/gcc/cp/pt.c:10716
0x5fcfcd instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:10786
0x65f9d5 complete_type(tree_node*)
../../src/gcc/cp/typeck.c:133
0x5ecaa9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17859
0x5ee406 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17144
0x5e6a27 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16446
0x5e5485 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15711
0x5e6605 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15697
0x5e6853 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15923
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Whereas g++ 6.3 works:

$ g++ --version
g++ (Debian 6.3.0-8) 6.3.0 20170221
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.

$ g++ -c gcc-bug.cpp && echo GOOD
GOOD

Best
Stephan

[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Segher Boessenkool  ---
This has been fixed long ago.

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

--- Comment #9 from Tor Myklebust  ---
OK, I gather that the gcc developers, as a group, are against changing this
behaviour.  (I can speculate why; almost all code that uses TLS will see a
slowdown.)

In order to work around this behaviour, one needs a way to tell gcc that %fs:0
may have been modified.  I don't see a way to do this.  None of the following
hacks, if placed before and after the call to something(), produce a desirable
result:

 - asm volatile("":::"memory"); no change in output.
 - asm volatile("":::"fs"); unknown register name 'fs' in 'asm'.
 - asm volatile("":::"%fs"); unknown register name '%fs' in 'asm'.
 - __seg_fs uintptr_t *hack = 0;
   asm volatile("" : "+r"(hack) :: "memory"); no change in behaviour, though
the TLS region pointer at %fs:0 gets roundtripped through %rax.

[Bug target/20614] PowerPC - inefficient use of condition register

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Segher Boessenkool  ---
At least as far back as 4.9 GCC does no longer generate subfic; is uses
a mix of cntlzw/srwi, addic/subfe, and cmpw insns.  Using more than three
CR fields is a bad idea (you then need to save and restore CR, which is
expensive on any CPU).

No doubt we could generate better code for this, but the reported
problem is no longer there, so I'm closing this bug.

[Bug translation/80189] gimplify.c: check whether parallel/task/teams should be translated

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 30 20:31:40 2017
New Revision: 246599

URL: https://gcc.gnu.org/viewcvs?rev=246599=gcc=rev
Log:
PR translation/80189
* gimplify.c (omp_default_clause): Use %qs instead of %s in
diagnostic messages.
testsuite/
* g++.dg/gomp/predetermined-1.C: Adjust expected diagnostics.
* g++.dg/gomp/sharing-1.C: Likewise.
* gfortran.dg/gomp/pr44536.f90: Likewise.
* gfortran.dg/gomp/pr44036-1.f90: Likewise.
* gfortran.dg/gomp/sharing-3.f90: Likewise.
* gfortran.dg/gomp/crayptr3.f90: Likewise.
* gfortran.dg/gomp/pr33439.f90: Likewise.
* gfortran.dg/gomp/appendix-a/a.24.1.f90: Likewise.
* gfortran.dg/gomp/sharing-1.f90: Likewise.
* gfortran.dg/gomp/sharing-2.f90: Likewise.
* gcc.dg/gomp/appendix-a/a.24.1.c: Likewise.
* gcc.dg/gomp/sharing-1.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/gomp/predetermined-1.C
trunk/gcc/testsuite/g++.dg/gomp/sharing-1.C
trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.24.1.c
trunk/gcc/testsuite/gcc.dg/gomp/sharing-1.c
trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.24.1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/crayptr3.f90
trunk/gcc/testsuite/gfortran.dg/gomp/pr33439.f90
trunk/gcc/testsuite/gfortran.dg/gomp/pr44036-1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/pr44536.f90
trunk/gcc/testsuite/gfortran.dg/gomp/sharing-1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/sharing-2.f90
trunk/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Peter Bergner  ---
Closing as fixed.

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  ---
Fixed on trunk and the GCC 5 and 6 release branches.

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
Author: bergner
Date: Thu Mar 30 20:09:32 2017
New Revision: 246596

URL: https://gcc.gnu.org/viewcvs?rev=246596=gcc=rev
Log:
gcc/
Backport from mainline
2017-03-30  Peter Bergner  

PR target/80246
* config/rs6000/dfp.md (dfp_dxex_): Update mode of operand 0.
(dfp_diex_): Update mode of operand 1.
* doc/extend.texi (dxex, dxexq): Document change to return type.
(diex, diexq): Document change to argument type.

gcc/testsuite/
Backport from mainline
2017-03-30  Peter Bergner  

PR target/80246
* gcc.target/powerpc/dfp-builtin-1.c: Remove unneeded dg-skip-if for
Darwin and SPE.
(dxex, dxexq): Update return type.
(diex, diexq): Update argument type.
* gcc.target/powerpc/pr80246.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr80246.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/dfp.md
branches/gcc-5-branch/gcc/doc/extend.texi
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/dfp-builtin-1.c

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Author: bergner
Date: Thu Mar 30 20:06:06 2017
New Revision: 246595

URL: https://gcc.gnu.org/viewcvs?rev=246595=gcc=rev
Log:
gcc/
Backport from mainline
2017-03-30  Peter Bergner  

PR target/80246
* config/rs6000/dfp.md (dfp_dxex_): Update mode of operand 0.
(dfp_diex_): Update mode of operand 1.
* doc/extend.texi (dxex, dxexq): Document change to return type.
(diex, diexq): Document change to argument type.

gcc/testsuite/
Backport from mainline
2017-03-30  Peter Bergner  

PR target/80246
* gcc.target/powerpc/dfp-builtin-1.c: Remove unneeded dg-skip-if for
Darwin and SPE.
(dxex, dxexq): Update return type.
(diex, diexq): Update argument type.
* gcc.target/powerpc/pr80246.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80246.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/dfp.md
branches/gcc-6-branch/gcc/doc/extend.texi
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/dfp-builtin-1.c

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Author: bergner
Date: Thu Mar 30 19:57:20 2017
New Revision: 246594

URL: https://gcc.gnu.org/viewcvs?rev=246594=gcc=rev
Log:
gcc/
PR target/80246
* config/rs6000/dfp.md (dfp_dxex_): Update mode of operand 0.
(dfp_diex_): Update mode of operand 1.
* doc/extend.texi (dxex, dxexq): Document change to return type.
(diex, diexq): Document change to argument type.

gcc/testsuite/
PR target/80246
* gcc.target/powerpc/dfp-builtin-1.c: Remove unneeded dg-skip-if for
Darwin and SPE.
(dxex, dxexq): Update return type.
(diex, diexq): Update argument type.
* gcc.target/powerpc/pr80246.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80246.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/dfp.md
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/dfp-builtin-1.c

[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)

[law at redhat dot com]

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

--- Comment #26 from Jeffrey A. Law  ---
So I had hoped this old BZ would be fixed by the changes for 71437.  Sadly,
that is not the case.

*But* the WIP for for 78496 does happen to fix this BZ.  In fact, we only need
the hunks from 78496 which are inexpensive.  So I may carve those out and push
them forward as a fix for this BZ as well as an improvement for 78496.

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
I've slightly reduced the example to the following:

% cat gfcbug138c.f90
subroutine gfcbug138 (yerrmsg)
  character(kind=1,len=*) :: yerrmsg
  yerrmsg = 1_"bug: " // yerrmsg
end subroutine gfcbug138


The dump tree now reads:


gfcbug138 (character(kind=1)[1:_yerrmsg] & restrict yerrmsg, integer(kind=4)
_yerrmsg)
{
  bitsizetype D.3423;
  sizetype D.3424;

  D.3423 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <_yerrmsg> * 8;
  D.3424 = (sizetype) NON_LVALUE_EXPR <_yerrmsg>;
  {
character(kind=1)[1:] * pstr.0;
void * restrict D.3419;
integer(kind=4) D.3420;
integer(kind=4) D.3421;
integer(kind=4) D.3422;

D.3419 = (void * restrict) __builtin_malloc (MAX_EXPR <(character(kind=4))
(_yerrmsg + 5), 1>);
pstr.0 = (character(kind=1)[1:] *) D.3419;
_gfortran_concat_string (_yerrmsg + 5, pstr.0, 5, &"bug: "[1]{lb: 1 sz: 1},
_yerrmsg, yerrmsg);
D.3420 = _yerrmsg + 5;
D.3421 = _yerrmsg + 5;
D.3422 = _yerrmsg;
if (D.3422 != 0)
  {
__builtin_memmove ((void *) yerrmsg, (void *) pstr.0, MIN_EXPR
<(character(kind=4)) D.3422, (character(kind=4)) D.3421>);
if ((character(kind=4)) D.3421 < (character(kind=4)) D.3422)
  {
__builtin_memset ((void *) yerrmsg + (sizetype) D.3421, 32,
(character(kind=4)) D.3422 - (character(kind=4)) D.3421);
  }
  }
__builtin_free ((void *) pstr.0);
  }
}


- Why are there still occurrences of character(kind=4)?  Shouldn't there be
  always character(kind=1)?

- The optimizer gets confused by a potential overflow of the length of the
concatenated string (_yerrmsg + 5), which is the only way the memset can be
invoked, with a length of -5, which is less than 0 (assuming ordinary wrapping
integer arithmetic)

[Bug fortran/80046] [F03] Explicit interface required: pointer argument

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> I'm currently regtesting a draft patch ...

After regtesting completed successfully, it was posted for review here:

https://gcc.gnu.org/ml/fortran/2017-03/msg00146.html

[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #7 from James Greenhalgh  ---
I'm not sure there are any bugs here to fix, though I can still reproduce the
performance differences.

First up, basic block reordering causes an issue across all microarchitectures
on which I've looked at this. Basic block reordering is kicking in because the
static estimates of the execution profile make it look like a good idea. I'm
struggling to understand exactly what the execution profile of the testcase is
intended to be, as I'm finding both the source and the generated assembly/perf
reports hard to follow. Because I'm struggling to follow it, I can't tell if
the basic block reorganisation is sensible, but it doesn't look buggy.

Turning basic block reordering off (with -fno-reorder-blocks) removes the
performance difference for me, with that off both before and after r245151 have
similar performance on Cortex-A53 and Cortex-A72.

However, Cortex-A57 still shows a performance regression, which I believe is
related to an extra conditional branch in the code after r245151. I tried to
find which pass previously removed this branch and narrowed it down to jump2,
but I haven't figured out why there is such a change in jump2.

I'm on vacation now, so won't be able to look at this in the next week if
anyone else wants to dig.

[Bug c++/80241] [5/6/7 Regression] Broken error message + ICE with invalid attribute

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think I've got a patch.

[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Yeah exactly...  so I'm conflicted whether we need to backport this or not.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[redi at gcc dot gnu.org]

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

--- Comment #44 from Jonathan Wakely  ---
Or my view on what our tests should do have "evolved" (i.e. completely
contradicted my old view!)

If mingw says that isn't a valid program or simply can't support it for valid
reasons, then the right thing to do is mark the test xfail or patch it to not
define noreturn on mingw. Which is what we did for darwin. Presumably you are
able to run the testsuite on mingw (something I never managed to do) so if you
can test a patch and propose it that would be great.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[nightstrike at gmail dot com]

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

--- Comment #43 from nightstrike  ---
Jon,

I was referring to your Comment 9:

The failing test is only intended to check that libstdc++ is consistent about
using the uglified attributes. Anything outside libstdc++ can do whatever it
wants.


Apparently I misunderstood that.  In any event, the mingw headers use
__declspec, defined for instance here:
https://msdn.microsoft.com/en-us/library/dabb5z75.aspx  There is no
__noreturn__ version there.  I'll poke (the other) Jon about it, though.  Maybe
there's a way to make it work.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[redi at gcc dot gnu.org]

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

--- Comment #42 from Jonathan Wakely  ---
(In reply to nightstrike from comment #41)
> It seems to me that the test itself is a bit overzealous.  If the intent is
> to ensure just that libstdc++ sources don't use certain words, well that's
> not entirely what is happening.

No, the intent is to ensure that this valid code compiles:

#define noreturn 1 2 3
#include 
int main() { }

Not "compiles, except for the bits that aren't from libstdc++" just "compiles".

That's a valid program, and should compile. 

But obviously libstdc++ doesn't control everything that  includes,
and so it might fail for reasons outside libstdc++'s control. Those are still
bugs, but they should be reported to the upstream libc (not to libstdc++).

If mingw causes that valid program to fail, it's a bug in mingw. Please report
it. If mingw won't fix it, the libstdc++ test should be marked xfail for that
target, or we can not test for some attributes on mingw (at the risk of
libstdc++ starting to accidentally use that in mingw-specific code that doesn't
get tested on other targets).

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

 CC||jon_y at users dot 
sourceforge.net
   ||, nightstrike at gmail dot com

--- Comment #41 from nightstrike  ---
This fails on mingw targets as well, because the mingw stdlib.h has for
instance:

  void __cdecl __declspec(noreturn) abort(void);

and setjmp.h has for instance:

  __declspec(noreturn) __attribute__ ((__nothrow__)) void __cdecl
ms_longjmp(jmp_buf _Buf,int _Value)/* throw(...)*/;
  __declspec(noreturn) __attribute__ ((__nothrow__)) void __cdecl
longjmp(jmp_buf _Buf,int _Value);

There are other instances of this kind of thing, but you get the idea.

It seems to me that the test itself is a bit overzealous.  If the intent is to
ensure just that libstdc++ sources don't use certain words, well that's not
entirely what is happening.

[Bug fortran/80257] Cygwin test fail: pointer_check_1.f90 output test

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
What is the output of

subroutine ppTest(f)
  implicit none
  external f
  call f()
end subroutine ppTest

Program RunTimeCheck
  implicit none
  external :: ppTest
  procedure(), pointer :: pptr

  pptr => sub
  call ppTest(pptr)

contains
  subroutine sub()
print *, 'Hello World'
  end subroutine sub
end Program RunTimeCheck

?

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[palves at redhat dot com]

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

--- Comment #7 from Pedro Alves  ---
I filed a corresponding GDB bug here:

 Support DW_TAG_base_type with no name
 https://sourceware.org/bugzilla/show_bug.cgi?id=21335

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-30
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
It fails even if s1/s2/s are all const char [].
What cxx_eval_builtin_function_calls sees is after cxx_eval_constant_expression
as args[0] is
(const void *) 
and the middle-end obviously can't do anything with that.
While the var may have DECL_INITIAL, if it isn't const, we don't know if we can
use it, and the middle-end I think will not look at DECL_INITIAL anyway.
Furthermore, what about cases like:
constexpr int foo (char x, char y)
{
  char a[10] = "abcde";
  a[2] = x;
  a[4] = y;
  return __builtin_memcmp (a, "abAdB", 6);
}
etc.?  Guess we'd need to be able to convert a CONSTRUCTOR to STRING_CST on the
fly.  Furthermore, the generic folding will give us as return value say for
strstr or similar functions that return pointers into the arguments something
like STRING_CST + value, while we in the end need instead ADDR_EXPR of the
variable plus something.
So perhaps we need to handle these builtins in the C++ FE?
Jason, any thoughts on this?

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[palves at redhat dot com]

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

--- Comment #6 from Pedro Alves  ---
Yes, agreed.

I haven't investigated yet why it ends up with that "",
but it's likely that the hack was incomplete and that's a red herring.

Hopefully GDB won't have some hard-to-eliminate dependency on a lookup by name
somewhere related to these subrange types that would be broken by going
nameless.

I admit I don't fully understand why these types need to be distinct, and why
not emit the underlying type instead of "__unknown__".  Grepping the gcc tree
for SIZETYPE seems to be that it's always defined to SIZE_TYPE (nothing
overrides it), and then that looks like always defined to some C built-in type.

[Bug target/80266] New: ICE in store_pairsi condition with -mabi=ilp32

[sch...@linux-m68k.org]

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

Bug ID: 80266
   Summary: ICE in store_pairsi condition with -mabi=ilp32
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

$ ./gnat1 -I ../../gcc/gcc/testsuite/gnat.dg/ -I - -quiet -O2 -gnatez
"-fdiagnostics-color=never" -gnatea "-fRTS=../aarch64-suse-linux/ilp32/libada"
"-mabi=ilp32" -fno-diagnostics-show-caret -gnatez -mlittle-endian
../../gcc/gcc/testsuite/gnat.dg/lto21_pkg2.adb
+===GNAT BUG DETECTED==+
| 7.0.1 20170330 (experimental) (aarch64-suse-linux) GCC error:|
| in plus_constant, at explow.c:88 |
| Error detected around ../../gcc/gcc/testsuite/gnat.dg/lto21_pkg2.adb:28:7|

#0  fancy_abort (file=0x1ac4778 "../../gcc/gcc/explow.c", line=88, 
function=0x1ac4a48 <plus_constant(machine_mode, rtx_def*, long,
bool)::__FUNCTION__> "plus_constant") at ../../gcc/gcc/diagnostic.c:1460
#1  0x00d0248c in plus_constant (mode=DImode, x=0xb6f246a8, c=4, 
inplace=false) at ../../gcc/gcc/explow.c:88
#2  0x0173bb88 in recog_126 (x1=, insn=, 
pnum_clobbers=0x0) at ../../gcc/gcc/config/aarch64/aarch64.md:1329
#3  recog_128 (x1=, pnum_clobbers=0x0, insn=)
at ../../gcc/gcc/config/aarch64/aarch64.md:2504
#4  0x0102281c in recog_memoized (insn=0xb5956e40)
at ../../gcc/gcc/recog.h:168

(insn 9104 226 229 2 (parallel [
(set (mem/c:SI (plus:SI (reg:SI 19 x19 [4628])
(const_int 196 [0xc4])) [0  S4 A8])
(reg:SI 19 x19 [4628]))
(set (mem/c:SI (plus:SI (reg:SI 19 x19 [4628])
(const_int 200 [0xc8])) [0  S4 A8])
(reg/f:SI 0 x0 [1114]))
]) "../../gcc/gcc/testsuite/gnat.dg/lto21_pkg2.adb":9 -1
 (nil))

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/80265] New: __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[redi at gcc dot gnu.org]

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

Bug ID: 80265
   Summary: __builtin_{memcmp,memchr,strlen} are not usable in
constexpr functions
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We need these functions (and wmemcmp, wmemchr and wcslen) to be usable in
constexpr functions to implement
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0426r1.html for C++17.

We only need it for C++17, but the constexpr rules are the same as C++14, and
this doesn't compile in C++14 or C++17 mode:

constexpr bool compare() {
  char s1[] = "foo";
  char s2[] = "foo";
  if (__builtin_memcmp(s1, s2, 3))
return false;
  return true;
}

constexpr bool length() {
  char s[] = "foo";
  if (__builtin_strlen(s) != 3)
return false;
  return true;
}

constexpr bool find() {
  char s[] = "foo";
  if (__builtin_memchr(s, 'o', 3) != s+1)
return false;
  return true;
}

static_assert( compare(), "" );
static_assert( length(), "" );
static_assert( find(), "" );


ce.cc:23:1: error: non-constant condition for static assertion
 static_assert( compare(), "" );
 ^
ce.cc:23:23:   in constexpr expansion of ‘compare()’
ce.cc:4:23: error: ‘__builtin_memcmp(((const void*)(& s1)), ((const void*)(&
s2)), 3)’ is not a constant expression
   if (__builtin_memcmp(s1, s2, 3))
   ^~~
ce.cc:24:1: error: non-constant condition for static assertion
 static_assert( length(), "" );
 ^
ce.cc:24:22:   in constexpr expansion of ‘length()’
ce.cc:11:23: error: ‘__builtin_strlen(((const char*)(& s)))’ is not a constant
expression
   if (__builtin_strlen(s) != 3)
   ^~~
ce.cc:25:1: error: non-constant condition for static assertion
 static_assert( find(), "" );
 ^
ce.cc:25:20:   in constexpr expansion of ‘find()’
ce.cc:18:23: error: ‘__builtin_memchr(((const void*)(& s)), 111, 3)’ is not a
constant expression
   if (__builtin_memchr(s, 'o', 3) != s+1)
   ^~~

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
For GDB, guess you should not warn for DWARF >= 5.

[Bug c++/33661] template methods forget explicit local register asm vars

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gdelugre.gcc at subvert dot 
techno
   ||logy

--- Comment #14 from Andrew Pinski  ---
*** Bug 64951 has been marked as a duplicate of this bug. ***

[Bug c++/64951] g++ generates incorrect code when using a register variable within a template function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 33661.

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

[Bug c++/64951] g++ generates incorrect code when using a register variable within a template function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||blubban at gmail dot com

--- Comment #2 from Andrew Pinski  ---
*** Bug 80264 has been marked as a duplicate of this bug. ***

[Bug c++/80264] g++ ignores register assignments in template functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 64951.

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

[Bug c++/80264] New: g++ ignores register assignments in template functions

[blubban at gmail dot com]

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

Bug ID: 80264
   Summary: g++ ignores register assignments in template functions
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

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

Input (also attached):

template
void foo1()
{
register int bar asm("NOT-A-REGISTER");
}
template void foo1<0>();

template
void foo2()
{
register int edi asm("edi") = 42;
asm volatile("" :: "r"(edi));
}
template void foo2<0>();

void foo3()
{
register int edi asm("edi") = 42;
asm volatile("" :: "r"(edi));
}


Command line:

g++ -S template-inline-asm.cpp -o-

(the flags don't affect this issue)


Expected output:

First function: error: invalid register name for 'bar'
Second: movl $42, %edi (or equivalent)
Third: movl $42, %edi


Actual output:

First one: Compiler silently emits a blank function (other than an unused
variable warning)
Second: movl $42, %ebx (%eax on -O1 or higher)
Third: As expected


Tested versions:

g++ 7.0.1 20170330 x86_64-linux-gnu (Godbolt)
g++ 6.2.0-5ubuntu12 x86_64-linux-gnu (Lubuntu 16.10)
g++ 4.4.7-1ubuntu2 x86_64-linux-gnu (Godbolt)
clang++ 3.8.1-12ubuntu1 (acts as expected)


7.0.1 config:

Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-7-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20170330/configure --prefix /root/staging
--build=x86_64-linux-gnu --disable-multilibs --disable-bootstrap
--enable-clocale=gnu --enable-languages=c,c++ --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.0.1 20170330 (experimental) (GCC-Explorer-Build) 
COLLECT_GCC_OPTIONS='-g' '-o'
'/tmp/compiler-explorer-compiler117230-57-19womo8.vtf1hmpldi/output.s'
'-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'

/opt/compiler-explorer/gcc-trunk-20170330/bin/../libexec/gcc/x86_64-linux-gnu/7.0.1/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20170330/bin/../lib/gcc/x86_64-linux-gnu/7.0.1/
-D_GNU_SOURCE  -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip
/tmp/compiler-explorer-compiler117230-57-19womo8.vtf1hmpldi/output.s -g
-version -o
/tmp/compiler-explorer-compiler117230-57-19womo8.vtf1hmpldi/output.s
GNU C++14 (GCC-Explorer-Build) version 7.0.1 20170330 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Seems DWARF4 has:
"A base type entry has a DW_AT_name attribute whose value is a null-terminated
string containing the name of the base type as recognized by the programming
language of the compilation unit containing the base type entry."
on page 75, so it is only DWARF5+ that makes DW_AT_name optional on base types.
We have some code to emit __unknown__ as name instead, guess we should not do
that for -gdwarf-5 anymore and figure out why we emit it here.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  ---
Okay, this I can reproduce (no -fPIC needed, not even -m32).  Thanks!

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Seems libgomp has a bug that without {,G}OMP_STACKSIZE and with OMP_DISPLAY_ENV
it displays random (uninitialized) value for the stack size, so I need to test
something like:
2017-03-30  Jakub Jelinek  

* env.c (initialize_env): Initialize stacksize to 0.

--- libgomp/env.c.jj2017-01-01 12:45:52.0 +0100
+++ libgomp/env.c   2017-03-30 16:07:29.800247913 +0200
@@ -1187,7 +1187,7 @@ handle_omp_display_env (unsigned long st
 static void __attribute__((constructor))
 initialize_env (void)
 {
-  unsigned long thread_limit_var, stacksize;
+  unsigned long thread_limit_var, stacksize = 0;
   int wait_policy;

   /* Do a compile time check that mkomp_h.pl did good job.  */

If we figure out what Darwin versions have so insanely low defaults and agree
on some more reasonable one (1M or 2M?), then we could change this to something
like:
  stacksize = GOMP_DEFAULT_STACKSIZE;
and later on where it parse_stacksize add || stacksize to the condition last,
then define GOMP_DEFAULT_STACKSIZE 0 by default and let some config/darwin/
header override it.

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Of course, the testcase was not using libgomp at all and OMP_STACKSIZE is an
env var used by libgomp only.
So, this means whatever darwin libpthread are using is using extremely small
default for the pthread_create stack size (.5MB) unless overridden (i.e. when
pthread_create is called with NULL as attribute; maybe also when called with
pthread_attr_init created attr without pthread_attr_setstacksize - you could
test this by commenting out
  pthread_attr_setstacksize (, 2048 * 1024);
line, recompile/relink/rerun the testcase.
Can you try some other darwin versions if you have access to them?

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[palves at redhat dot com]

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

--- Comment #3 from Pedro Alves  ---
Possible solutions could be:

 #1 - emit the underlying type instead.
 #2 - emit no name.

#2 seems to be valid DWARF5, which says (page 103):

"A base type entry may have a DW_AT_name attribute whose value is a
null-terminated string containing the name of the base type as recognized by
the programming language of the compilation unit containing the base type
entry."

(Particularly, it says "may".)

GDB isn't fully prepared for that though.  In its read_base_type function, it
has:

  name = dwarf2_name (die, cu);
  if (!name)
{
  complaint (_complaints,
 _("DW_AT_name missing from DW_TAG_base_type"));
}

(That generates a warning when "set complaints" is enabled, which normally it
isn't.  I don't know the history behind that complaint.)

and a quick hack to NULL out the name when it is "sizetype" results in:

 (gdb) ptype sizetype
 type = 

[Bug ipa/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[jamborm at gcc dot gnu.org]

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

--- Comment #23 from Martin Jambor  ---
Fixed on trunk so far.  I will prepare & test backports.

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-30
Version|unknown |7.0.1
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Should set TYPE_NAMELESS on those I suppose.  Not sure for other common tree
nodes that get an INDENTIFIER name (and do not re-use other types).

[Bug ipa/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[jamborm at gcc dot gnu.org]

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

--- Comment #22 from Martin Jambor  ---
Author: jamborm
Date: Thu Mar 30 13:51:02 2017
New Revision: 246589

URL: https://gcc.gnu.org/viewcvs?rev=246589=gcc=rev
Log:
[PR 77333] Fixup fntypes of gimple calls of clones

2017-03-30  Martin Jambor  

PR ipa/77333
* cgraph.h (cgraph_build_function_type_skip_args): Declare.
* cgraph.c (redirect_call_stmt_to_callee): Set gimple fntype so that
it reflects the signature changes performed at the callee side.
* cgraphclones.c (build_function_type_skip_args): Make public, renamed
to cgraph_build_function_type_skip_args.
(build_function_decl_skip_args): Adjust call to the above function.

testsuite/
* g++.dg/ipa/pr77333.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr77333.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphclones.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
The consequence is that that internal type's name can mask out a user-defined
type with the same name.  For example:

$ cat sizetype2.c
char array[1];
typedef struct sizetype { char c; } sizetype;
sizetype sz;
int main () {}

$ /opt/gcc/bin/gcc sizetype2.c -o sizetype2 -g 
$ gdb ./sizetype2
(gdb) start
Temporary breakpoint 1, main () at sizetype2.c:4
4   int main () {}
(gdb) ptype sz
type = struct sizetype {
char c;
}
(gdb) ptype sizetype
type = sizetype
(gdb) 

The last "ptype" above should have printed out the structure type.  Instead, it
printed GCC's "sizetype" integer type.

[Bug debug/80263] New: gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[palves at redhat dot com]

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

Bug ID: 80263
   Summary: gcc's internal type "sizetype" leaks out as base type
name in the DWARF info
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

In the full example below, note:
~~
 <1><2d>: Abbrev Number: 4 (DW_TAG_base_type)
<2e>   DW_AT_byte_size   : 8
<2f>   DW_AT_encoding: 7(unsigned)
<30>   DW_AT_name: (indirect string, offset: 0x6): sizetype
~~

AFAICT, this "sizetype" is one of the internal types (sizetype, ssizetype,
bitsizetype and sbitsizetype) that GCC uses for expressions dealing with size. 

Full log:

$ cat sizetype.c
char array[1];

$ /opt/gcc/bin/gcc sizetype.c -o sizetype -g -c && readelf --debug-dump=info
sizetype   
Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0x4d (32-bit)
   Version:   4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x2a): GNU C11 7.0.1
20170321 (experimental) -mtune=generic -march=x86-64 -g
<10>   DW_AT_language: 12   (ANSI C99)
<11>   DW_AT_name: (indirect string, offset: 0xf): sizetype.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x1a): /home/pedro/tmp
<19>   DW_AT_stmt_list   : 0x0
 <1><1d>: Abbrev Number: 2 (DW_TAG_array_type)
<1e>   DW_AT_type: <0x34>
<22>   DW_AT_sibling : <0x2d>
 <2><26>: Abbrev Number: 3 (DW_TAG_subrange_type)
<27>   DW_AT_type: <0x2d>
<2b>   DW_AT_upper_bound : 0
 <2><2c>: Abbrev Number: 0
 <1><2d>: Abbrev Number: 4 (DW_TAG_base_type)
<2e>   DW_AT_byte_size   : 8
<2f>   DW_AT_encoding: 7(unsigned)
<30>   DW_AT_name: (indirect string, offset: 0x6): sizetype
 <1><34>: Abbrev Number: 4 (DW_TAG_base_type)
<35>   DW_AT_byte_size   : 1
<36>   DW_AT_encoding: 6(signed char)
<37>   DW_AT_name: (indirect string, offset: 0x70): char
 <1><3b>: Abbrev Number: 5 (DW_TAG_variable)
<3c>   DW_AT_name: (indirect string, offset: 0x0): array
<40>   DW_AT_decl_file   : 1
<41>   DW_AT_decl_line   : 1
<42>   DW_AT_type: <0x1d>
<46>   DW_AT_external: 1
<46>   DW_AT_location: 9 byte block: 3 1 0 0 0 0 0 0 0  (DW_OP_addr: 1)
 <1><50>: Abbrev Number: 0

$ /opt/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/pedro/src/gcc/src/configure --disable-bootstrap
--prefix=/opt/gcc CFLAGS='-g3 -O0' CXXFLAGS='-g3 -O0' --enable-checking=release
--enable-languages=c,c++,lto
Thread model: posix
gcc version 7.0.1 20170321 (experimental) (GCC)

[Bug target/80206] ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> and see what it prints?

RLIMIT_STACK cur 67104768 max 67104768
PTHREAD_STACK_MIN 8192
main thread pthread_get_stacksize_np 67104768
other thread pthread_get_stacksize_np 524288
other thread pthread_get_stacksize_np 2097152

and it does not depend on OMP_STACKSIZE.

[Bug target/80206] ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 30 13:29:28 2017
New Revision: 246588

URL: https://gcc.gnu.org/viewcvs?rev=246588=gcc=rev
Log:
PR target/80206
* config/i386/sse.md
(_vextract_mask): Use
register as dest whenever it is a MEM not rtx_equal_p to the
corresponding dup operand, and when forcing into reg move the
reg into the memory afterwards.
(_vextract_mask):
Likewise.  Use  instead of 
for the force_reg mode.
(avx512vl_vextractf128): Use register as dest either
always when a MEM, or when it is a MEM not rtx_equal_p to the
corresponding dup operand, or even not when it is a CONST_VECTOR
depending on the mode and lo vs. hi.
(avx512dq_vextract64x2_1_maskm): Remove extraneous
parens.
(avx512f_vextract32x4_1_maskm): Likewise.
(avx512dq_vextract64x2_1):
Likewise.  Require that operands[2] is even.
(avx512f_vextract32x4_1):
Remove extraneous parens.  Require that operands[2] is a multiple
of 4.
(vec_extract_lo_): Don't bother testing if
operands[0] is a MEM if , the predicates/constraints
disallow memory then.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr80206.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80173] [5/6/7 Regression] ICE in store_bit_field_1, at expmed.c:787

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 41091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41091=edit
gcc7-pr80173.patch

Untested fix.  If there are float/vector hard registers wider than word, we
shouldn't attempt to pick a word sized subreg out of them.

[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
It is probably latent there, there were major changes in the trap and
conditional trap handling in GCC 7, so we likely don't have a testcase right
now that would ICE in 6.

[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Is it fixed?  Can this not happen on GCC 6?

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

[vincenzo.innocente at cern dot ch]

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

--- Comment #5 from vincenzo Innocente  ---
I confirm that gather is almost twice as fast on 
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
w/r/t
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
(used a benchmark version of PR80248 example)
so on skylake, knl, (and hopefully on skylake-avx512) is profitable,
on Haswell and broardwell is not...

[Bug middle-end/80262] address space gets lost in memory access

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 30 Mar 2017, stefan at reservoir dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
> 
> --- Comment #4 from Stefan M Freudenberger  ---
> My original example involved a MEM with a constant offset, and yielded an ICE:
> 
> internal compiler error: tree check: expected integer_cst, have
> addr_space_convert_expr in decompose, at tree.h

I believe that one was fixed on trunk:

2017-02-22  Richard Biener  

PR tree-optimization/79673
* tree-ssa-pre.c (compute_avail): Use wide_int_to_tree to
convert the [TARGET_]MEM_REF offset INTEGER_CST, scrapping off
irrelevant address-space qualifiers and avoiding a
ADDR_SPACE_CONVERT_EXPR from fold_convert.


> Maybe I misinterpreted what type to expect for the operands of the MEM, and
> hence constructed a bad example. I'll try to come up with an example that 
> shows
> the ICE.
> 
>

[Bug middle-end/80262] address space gets lost in memory access

[stefan at reservoir dot com]

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

--- Comment #4 from Stefan M Freudenberger  ---
My original example involved a MEM with a constant offset, and yielded an ICE:

internal compiler error: tree check: expected integer_cst, have
addr_space_convert_expr in decompose, at tree.h

Maybe I misinterpreted what type to expect for the operands of the MEM, and
hence constructed a bad example. I'll try to come up with an example that shows
the ICE.

[Bug libstdc++/80251] Is the is_aggregate meta function missing?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 41090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41090=edit
gcc7-pr80251.patch

The compiler side (untested so far, except for make check-c++-all
RUNTESTFLAGS=dg.exp=is_aggr*).

[Bug c/80173] [5/6/7 Regression] ICE in store_bit_field_1, at expmed.c:787

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r190492.

[Bug c++/80135] [6/7 Regression] ICE in output_constructor_regular_field, at varasm.c:4968

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-30
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/35878] [LWG 2302] Useless NULL pointer check when constructing object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #13 from Ville Voutilainen  ---
I'll take this to remember to consider enabling it for other standard modes.

[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Ville Voutilainen  ---
It seems to me that the current semantics of inherited constructors cause the
base constructor that would take a tuple to not be inherited. clang+libc++
agree. I think this is thus invalid.

[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Mike from comment #4)
> (In reply to Richard Biener from comment #3)
> > Can you try to build in a separate object directory instead?
> And where to put the folder

https://gcc.gnu.org/wiki/FAQ#configure

[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'

[programmist.linuks at mail dot ru]

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

--- Comment #4 from Mike  ---
(In reply to Richard Biener from comment #3)
> So if comment #5 is correct then it seems we are building stage1 genmatch
> against the (not yet built) libstdc++ headers but linking
> (-static-libstdc++) against the host compilers library.
> 
> Unfortunately the provided log doesn't tell how build/genmatch.o was built.
> 
> Trying myself we do (correctly):
> 
> g++ -std=gnu++98 -c   -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
> -I/space/rguenther/src/svn/gcc-6-branch/gcc
> -I/space/rguenther/src/svn/gcc-6-branch/gcc/build
> -I/space/rguenther/src/svn/gcc-6-branch/gcc/../include 
> -I/space/rguenther/src/svn/gcc-6-branch/gcc/../libcpp/include  \
> -o build/genmatch.o
> /space/rguenther/src/svn/gcc-6-branch/gcc/genmatch.c
> 
> and in my experiments I can compile GCC 6.3 with 4.9.2 just fine so maybe
> Debian backported some changes in a wrong way.  I suggest to report this bug
> to Debian instead (CCing packager).
> 
> Note that you seem to do a build in-tree which isn't recommended.  Can you
> try to build in a separate object directory instead?

I tried to compile by your method and this is what happened:

<<< root@mx:/home/admin/sources/gcc-6.3.0# g++ -std=gnu++98 -c   -g -DIN_GCC   
 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE
-I. -Ibuild -I./gcc -I./gcc/build -I./gcc/../include  -I./gcc/../libcpp/include
 -o build/genmatch.o ./gcc/genmatch.c./gcc/genmatch.c:24:21: fatal
error: bconfig.h: No such file or directory
#include "bconfig.h"
 ^
compilation terminated.>>>

> Can you
try to build in a separate object directory instead?
And where to put the folder?

I started looking for configuration files:
<<< root@mx:/home/admin/sources/gcc-6.3.0# find . -iname bconfig.h
./host-x86_64-pc-linux-gnu/gcc/bconfig.h
./host-x86_64-pc-linux-gnu/prev-gcc/bconfig.h >>>

I added a new path for Include:
<<< root@mx:/home/admin/sources/gcc-6.3.0# g++ -std=gnu++98 -c   -g -DIN_GCC   
 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE
-I. -Ibuild -I./gcc -I./gcc/build -I./gcc/../include  -I./gcc/../libcpp/include
-I./host-x86_64-pc-linux-gnu/gcc  -o build-x86_64-linux-gnu/genmatch.o
./gcc/genmatch.c
root@mx:/home/admin/sources/gcc-6.3.0# ls build-x86_64-linux-gnu/
fixincludes  genmatch.o  libcpp  libiberty 
-rw-r--r-- 1 root root 1,2M мар 30 13:26 build-x86_64-linux-gnu/genmatch.o
>>>

Here is my old file!
<<< root@mx:/home/admin/sources/gcc-6.3.0# ls -lh
./host-x86_64-pc-linux-gnu/gcc/build/genmatch.o 
-rw-r--r-- 1 root root 298K мар 22 18:27
./host-x86_64-pc-linux-gnu/gcc/build/genmatch.o >>>

I went to the folder in which the compilation takes place:
<<< root@mx:/home/admin/sources/gcc-6.3.0# cd ./host-x86_64-pc-linux-gnu/gcc/
>>>

An error occurs after this command:
<<< root@mx:/home/admin/sources/gcc-6.3.0/host-x86_64-pc-linux-gnu/gcc# g++
-std=gnu++98   -g -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   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc  -fno-pie -o
build/genmatch \
> build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a 
> build/errors.o build/vec.o build/hash-table.o 
> ../../host-x86_64-pc-linux-gnu/libiberty/libiberty.a
build/vec.o: In function `vec_prefix::release_overhead(void*, unsigned long,
bool)':
vec.c:(.text+0x6c6): undefined reference to `operator delete(void*, unsigned
long)'
build/vec.o: In function `vec_prefix::register_overhead(void*, unsigned long,
unsigned long)':
vec.c:(.text+0x9a1): undefined reference to `operator delete(void*, unsigned
long)'
build/vec.o: In function
`mem_alloc_description::~mem_alloc_description()':
vec.c:(.text._ZN21mem_alloc_descriptionI9vec_usageED2Ev[_ZN21mem_alloc_descriptionI9vec_usageED5Ev]+0x62):
undefined reference to `operator delete(void*, unsigned long)'
vec.c:(.text._ZN21mem_alloc_descriptionI9vec_usageED2Ev[_ZN21mem_alloc_descriptionI9vec_usageED5Ev]+0x70):
undefined reference to `operator delete(void*, unsigned long)'

[Bug translation/80189] gimplify.c: check whether parallel/task/teams should be translated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug middle-end/80262] address space gets lost in memory access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Hmm.  That can't be the real problem as the address-space is not taken from the
alias pointer type when expanding to RTL.

Note that there have been various fixes for address-spaces on the trunk.

The SRA dump looks correct in that _4 has the correct type.

[Bug middle-end/80262] address space gets lost in memory access

[stefan at reservoir dot com]

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

--- Comment #2 from Stefan M Freudenberger  ---
Created attachment 41088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41088=edit
Output from -fdump-tree-esra

[Bug middle-end/80262] address space gets lost in memory access

[stefan at reservoir dot com]

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

--- Comment #1 from Stefan M Freudenberger  ---
Created attachment 41087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41087=edit
Output from -fdump-tree-forwprop1

[Bug middle-end/80262] New: address space gets lost in memory access

[stefan at reservoir dot com]

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

Bug ID: 80262
   Summary: address space gets lost in memory access
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at reservoir dot com
  Target Milestone: ---

Created attachment 41086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41086=edit
The source program

For an out-of-tree target that supports address spaces the address space is
lost during early sra in the following example when compiled with -O3:

 cut 
typedef int v4si __attribute__ (( __vector_size__ (16) ));

typedef struct {
  v4si v;
} S1;
S1 clearS1() { S1 s1 = { 0 }; return s1; }

typedef struct {
  S1 s2[4];
} S2;
void initS2(__ea S2* p, int i) {
  p->s2[i] = clearS1();
}
 cut 

At the end of forwprop1, in initS2 there still is the reference to p->s2[i],
but when esra creates a replacement for the result value of the inlined
clearS1, the memory reference is rewritten dropping the address space (see the
attached dumps).

Of course, I may have introduced this bug with my changes, maybe someone with a
target that supports address spaces can confirm this problem?

The problem appears to be due to the type returned by reference_alias_ptr_type
in this case: it builds a pointer to the TYPE_MAIN_VARIANT, thus dropping the
address space qualifier. The following patch may solve this problem:

 cut 
--- orig_gcc-6.3.0/gcc/alias.c  2016-12-07 22:47:48.0 +
+++ gcc/gcc/alias.c 2017-03-29 13:42:15.192688629 +
@@ -784,7 +784,13 @@
   || TREE_CODE (t) == TARGET_MEM_REF)
 return TREE_TYPE (TREE_OPERAND (t, 1));
   else
-return build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (t)));
+{
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (t));
+  tree tem = TYPE_MAIN_VARIANT (TREE_TYPE (t));
+  if (!ADDR_SPACE_GENERIC_P (as))
+   tem = build_qualified_type (tem, ENCODE_QUAL_ADDR_SPACE (as));
+  return build_pointer_type (tem);
+}
 }

 /* Return whether the pointer-types T1 and T2 used to determine
 cut 

[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
So if comment #5 is correct then it seems we are building stage1 genmatch
against the (not yet built) libstdc++ headers but linking (-static-libstdc++)
against the host compilers library.

Unfortunately the provided log doesn't tell how build/genmatch.o was built.

Trying myself we do (correctly):

g++ -std=gnu++98 -c   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I/space/rguenther/src/svn/gcc-6-branch/gcc
-I/space/rguenther/src/svn/gcc-6-branch/gcc/build
-I/space/rguenther/src/svn/gcc-6-branch/gcc/../include 
-I/space/rguenther/src/svn/gcc-6-branch/gcc/../libcpp/include  \
-o build/genmatch.o
/space/rguenther/src/svn/gcc-6-branch/gcc/genmatch.c

and in my experiments I can compile GCC 6.3 with 4.9.2 just fine so maybe
Debian backported some changes in a wrong way.  I suggest to report this bug to
Debian instead (CCing packager).

Note that you seem to do a build in-tree which isn't recommended.  Can you
try to build in a separate object directory instead?

[Bug fortran/80260] [7 Regression] ICE with polymorphic array section actual argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |7.0

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Richard Biener  ---
Thus invalid.

[Bug c++/80259] [5/6/7 Regression] ICE deleting friend function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Dominique d'Humieres from comment #9)
> > I have read people complaining about very low OMP stack sizes
> > on OSX.
> 
> What is setting the limit?

Probably OSX thread library?

Can you try something like:
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

static void *
tf (void *arg)
{
#ifdef __APPLE__
  fprintf (stderr, "other thread pthread_get_stacksize_np %lld\n",
   pthread_get_stacksize_np (pthread_self ()));
#else
  pthread_attr_t at;
  pthread_getattr_np (pthread_self (), );
  size_t sz;
  pthread_attr_getstacksize (, );
  fprintf (stderr, "other thread pthread_getattr_np + "
   "pthread_attr_getstacksize %zd\n", sz);
  pthread_attr_destroy ();
#endif
  return NULL;
}

int
main ()
{
  struct rlimit rl;
  if (getrlimit (RLIMIT_STACK, ))
fprintf (stderr, "err1\n");
  else
fprintf (stderr, "RLIMIT_STACK cur %lld max %lld\n",
 (long long) rl.rlim_cur, (long long) rl.rlim_max);
  fprintf (stderr, "PTHREAD_STACK_MIN %lld\n", (long long) PTHREAD_STACK_MIN);
#ifdef __APPLE__
  fprintf (stderr, "main thread pthread_get_stacksize_np %lld\n",
   pthread_get_stacksize_np (pthread_self ()));
#else
  pthread_attr_t at;
  pthread_getattr_np (pthread_self (), );
  size_t sz;
  pthread_attr_getstacksize (, );
  fprintf (stderr, "main thread pthread_getattr_np + "
   "pthread_attr_getstacksize %zd\n", sz);
  pthread_attr_destroy ();
#endif
  pthread_t th;
  pthread_create (, NULL, tf, NULL);
  pthread_join (th, NULL);
  pthread_attr_t at2;
  pthread_attr_init ();
  pthread_attr_setstacksize (, 2048 * 1024);
  pthread_create (, , tf, NULL);
  pthread_join (th, NULL);
  pthread_attr_destroy ();
  return 0;
}

and see what it prints?

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Andreas Krebbel  ---
The only solution we found caused other regressions.

[Bug libstdc++/80251] Is the is_aggregate meta function missing?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It's only existed for less than a month,. and it requires a new intrinsic from
the compiler which doesn't exist yet.

[Bug fortran/80260] [7 Regression] ICE with polymorphic array section actual argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-30
 CC||marxin at gcc dot gnu.org,
   ||vehre at gmx dot de
  Known to work||5.4.0, 6.3.0
 Ever confirmed|0   |1
  Known to fail||7.0

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

[Bug rtl-optimization/80261] New: Worse code generated compared to clang with modulo operation

[maksqwe1 at ukr dot net]

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

Bug ID: 80261
   Summary: Worse code generated compared to clang with modulo
operation
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maksqwe1 at ukr dot net
  Target Milestone: ---


#include 
#include 

typedef unsigned int uint;

uintptr_t g_array[131];
uintptr_t foo1(void *ptr)
{
constexpr size_t size = sizeof(g_array) / sizeof(uintptr_t);
return g_array[uint(uintptr_t(ptr)) % size];
}

uintptr_t foo2(void *ptr)
{
constexpr size_t size = sizeof(g_array) / sizeof(uintptr_t);
return g_array[uintptr_t(ptr) % size];
}

This code produce more worse assembly code for foo2() compared to clang.

--- x86-64 GCC 6.3(-O2 -std=c++11) ---
foo1(void*):
mov eax, edi
mov edx, -98358029
mul edx
shr edx, 7
imuledx, edx, 131
sub edi, edx
mov rax, QWORD PTR g_array[0+rdi*8]
ret
foo2(void*):
mov rax, rdi
movabs  rdx, 281629680514649643
mul rdx
shr rdx
mov rax, rdx
sal rax, 6
add rax, rdx
lea rax, [rdx+rax*2]
sub rdi, rax
mov rax, QWORD PTR g_array[0+rdi*8]
ret
g_array:
.zero   1048

--

--- x86-64 CLang 3.9(-O2 -std=c++11) -
foo1(void*):  # @foo1(void*)
mov ecx, edi
movabs  rdx, 281629680514649643
mov rax, rcx
mul rdx
shr rdx
imulrax, rdx, 131
sub rcx, rax
mov rax, qword ptr [8*rcx + g_array]
ret

foo2(void*):  # @foo2(void*)
movabs  rcx, 281629680514649643
mov rax, rdi
mul rcx
shr rdx
imulrax, rdx, 131
sub rdi, rax
mov rax, qword ptr [8*rdi + g_array]
ret

g_array:
.zero   1048
--

https://godbolt.org/g/PEyju2

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
This is not a bug, that is how TLS is designed.  You shouldn't change threads
in the middle of a function.  If you do, you shouldn't use TLS, but something
different; basically you are implementing your own threading library then and
you are responsible for arranging that it works.

[Bug c++/80259] [5/6/7 Regression] ICE deleting friend function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
With untested:
--- gcc/decl2.c.jj  2017-02-21 18:59:36.0 +0100
+++ gcc/decl2.c 2017-03-30 10:16:03.972113673 +0200
@@ -888,9 +888,18 @@ grokfield (const cp_declarator *declarat
{
  if (init == ridpointers[(int)RID_DELETE])
{
- DECL_DELETED_FN (value) = 1;
- DECL_DECLARED_INLINE_P (value) = 1;
- DECL_INITIAL (value) = error_mark_node;
+ if (friendp && decl_defined_p (value))
+   {
+ error ("redefinition of %q#D", value);
+ inform (DECL_SOURCE_LOCATION (value),
+ "%q#D previously defined here", value);
+   }
+ else
+   {
+ DECL_DELETED_FN (value) = 1;
+ DECL_DECLARED_INLINE_P (value) = 1;
+ DECL_INITIAL (value) = error_mark_node;
+   }
}
  else if (init == ridpointers[(int)RID_DEFAULT])
{
I get:
pr80259.C:5:23: error: redefinition of ‘void foo()’
   friend void foo() = delete;
   ^~
pr80259.C:1:6: note: ‘void foo()’ previously defined here
 void foo() {}
  ^~~
but no idea if you don't want to resolve it differently.

[Bug c++/80259] [5/6/7 Regression] ICE deleting friend function

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
duplicate_decls is called with the DECL_INITIAL is still being NULL on the
newdecl (and olddecl has it a BLOCK).
#0  duplicate_decls (newdecl=,
olddecl=, newdecl_is_friend=true)
at ../../gcc/cp/decl.c:1401
#1  0x00a2420c in pushdecl_maybe_friend_1 (x=, is_friend=true) at ../../gcc/cp/name-lookup.c:835
#2  0x00a27940 in pushdecl_maybe_friend (x=, is_friend=true) at ../../gcc/cp/name-lookup.c:1352
#3  0x00a2aaff in pushdecl_with_scope_1 (x=, level=0x7fffefade000, is_friend=true)
at ../../gcc/cp/name-lookup.c:2349
#4  0x00a2aba2 in pushdecl_with_scope (x=, level=0x7fffefade000, is_friend=true)
at ../../gcc/cp/name-lookup.c:2363
#5  0x00a30b81 in pushdecl_namespace_level (x=, is_friend=true) at ../../gcc/cp/name-lookup.c:3978
#6  0x0097cf07 in do_friend (ctype=,
declarator=, decl=, 
attrlist=, flags=NO_SPECIAL, funcdef_flag=false) at
../../gcc/cp/friend.c:640
#7  0x007c9f6a in grokdeclarator (declarator=0x2ad2a00,
declspecs=0x7fffd830, decl_context=FIELD, initialized=1, 
attrlist=0x7fffd770) at ../../gcc/cp/decl.c:12060
#8  0x008b879f in grokfield (declarator=0x2ad2a60,
declspecs=0x7fffd830, init=, 
init_const_expr_p=true, asmspec_tree=, attrlist=) at
../../gcc/cp/decl2.c:806
And only afterwards grokfield reaches:
889   if (init == ridpointers[(int)RID_DELETE])
890 {
891   DECL_DELETED_FN (value) = 1;
892   DECL_DECLARED_INLINE_P (value) = 1;
893   DECL_INITIAL (value) = error_mark_node;
894 }
At this point I think we can't call redeclaration_error_message, because we
don't have the new decl anymore, only the merged (old one).  Perhaps custom
error message here if value is a friend and it has non-NULL (or non-NULL and
non-error_mark_node?) DECL_INITIAL and use there location_t for the new decl
from declarator->id_loc (that would be the foo) or input_location (that would
be the deleted) or something similar?

[Bug c++/80259] [5/6/7 Regression] ICE deleting friend function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-30
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r213974.
Before that we've rejected it with:
pr80259.C:5:23: error: can’t initialize friend function ‘foo’
   friend void foo() = delete;
   ^
clang++ gives:
pr80259.C:5:15: error: inline declaration of 'foo' follows non-inline
definition
  friend void foo() = delete;
  ^
pr80259.C:1:6: note: previous definition is here
void foo() {}
 ^

So, what diagnostics would be best here?  What about:
void foo();
struct A
{
  friend void foo() = delete;
};
void foo() {}
?  With/without the first declaration we emit:
pr80259-2.C: In function ‘void foo()’:
pr80259-2.C:6:6: error: redefinition of ‘void foo()’
 void foo() {}
  ^~~
pr80259-2.C:4:15: note: ‘void foo()’ previously defined here
   friend void foo() = delete;
   ^~~
which looks fine to me.  So is the #c0 testcase a redefinition of the function
that should be diagnosed the same way?
For
void foo() {}
inline void foo () {}
we emit:
pr80259-3.C: In function ‘void foo()’:
pr80259-3.C:2:13: error: redefinition of ‘void foo()’
 inline void foo () {}
 ^~~
pr80259-3.C:1:6: note: ‘void foo()’ previously defined here
 void foo() {}
  ^~~
while clang++ emits:
pr80259-3.C:2:13: error: inline declaration of 'foo' follows non-inline
definition
inline void foo () {}
^
pr80259-3.C:1:6: note: previous definition is here
void foo() {}
 ^
so at least for now I'd say we should just emit a normal redefinition message.

[Bug rtl-optimization/80197] pgo dramatically pessimizes scimark2 MonteCarlo benchmark

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Wed, 29 Mar 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
> 
> --- Comment #7 from Alexander Monakov  ---
> No, with fixed-up inlining -ftracer sees reasonable edge probabilities. The
> reason tracer makes things worse here, is that it clones the path leading to a
> 50%/50% conditional branch (and correctly stops at that branch), making the
> tiny BB under that branch ineligible(?) for if-conversion. We go from
> 
> 
> if (!cond) goto 
>   
>   var = VAL;   // this can eventually become a cmov
> 
> 
> to
> 
> 
> if (!cond) goto 
> goto 
> 
> ...
> 
> 
> if (!cond) goto 
>   
>   var = VAL;  // this doesn't become a cmov
> 
> 
> 
> I think in principle if-conversion could still do its job here by duplicating
> the conditional var=VAL assignment under BB0_1.
> 
> Here's a silly compile-only sample where -O2 -ftracer is worse than -O2 due to
> this effect:
> 
> void f(long n, signed char *x)
> {
>   for (; n; n--) {
> long a=x[n], b;
> if (!a)
>   a = 42;
> b = x[a];
> if (b < 0)
>   b += a;
> x[b] = 0;
>   }
> }

It's hard for tracer to predict followup optimization opportunities
in the isolated path and weight that against missed if-conversion
opportunities.

Of course the fact that late phiopt runs after tracer / split-paths
doesn't help, nor that phiopt doesn't catch this kind of
if-conversion (the idea was that the RTL pass can do _much_ better
in assessing if-conversion const/benefit).

Tracer doesn't have a very sophisticated cost model either.

[Bug fortran/80260] New: [7 Regression] ICE with polymorphic array section actual argument

[damian at sourceryinstitute dot org]

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

Bug ID: 80260
   Summary: [7 Regression] ICE with polymorphic array section
actual argument
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

The code below causes an internal compiler error with gfortran 7.0.1, but
compiles and executes cleanly with gfortran 6.3.0

$ cat foobar.f90 
type foo
end type foo
type, extends(foo) :: bar
end type
contains
subroutine f(x)
  class(foo) x(:,:)
  select type(x)
class is (bar)
  call g(x(1,:))
  end select
end subroutine
subroutine g(y)
  class(bar) y(:)
end subroutine
end

$ gfortran --version
GNU Fortran (GCC) 7.0.1 20170326 (experimental)
-- snip --

$ gfortran foobar.f90 
foobar.f90:10:0:

   call g(x(1,:))

internal compiler error: Segmentation fault
0xbe60ff crash_signal
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/toplev.c:337
0x6c70d9 gfc_conv_scalarized_array_ref
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-array.c:3229
0x6c8344 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-array.c:3397
0x701ffd gfc_conv_variable
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:2680
0x6fdcda gfc_conv_expr(gfc_se*, gfc_expr*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:7805
0x6d7796 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-array.c:7184
0x6fa627 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:5319
0x7443ba gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:406
0x6bc658 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1891
0x748b88 gfc_trans_block_construct(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1821
0x6bc407 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1919
0x7403f3 gfc_trans_if_1
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1321
0x74859a gfc_trans_if(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1352
0x6bc477 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1911
0x74b282 gfc_trans_select_type_cases
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:2419
0x74b282 gfc_trans_select_type(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:3130
0x6bc377 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1939
0x748b88 gfc_trans_block_construct(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1821
0x6bc407 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1919
0x6ee028 gfc_generate_function_code(gfc_namespace*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-decl.c:6332
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-30
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
IMO your patch is OK and it is not worth wasting more time on this test.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/69517] SEGV on a VLA with excess initializer elements

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> 
> The bug here is in G++ accepting a VLA initializer with more elements than
> there is room for in the VLA, and then trashing the stack at runtime with
> the extra elements.  It is a regression with respect to GCC 4.9.3 which
> implements C++ VLAs as specified in n3639
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html).  This
> is documented in GCC 4.9 changes (https://gcc.gnu.org/gcc-4.9/changes.html)
> which highlights the feature using the following example:
> 
>   void f(int n) {
> int a[n] = { 1, 2, 3 }; // throws std::bad_array_length if n < 3
> ...
> 
> VLAs were subsequently removed from C++, and also partially (but not
> completely) removed from G++, which causes C++ programs developed and tested
> with G++ 4.9 to break when ported to a later version.
> 
> C++ VLAs will be safer to use with the patch referenced in comment #9.  It
> patch had to be reverted from GCC 6.0 because it caused problems in Java. 
> Java has been removed and I plan/hope to resubmit the patch for GCC 8.  (I
> wanted to do it for GCC 7 but didn't get to it.)

I don't see why it would be a bug.  There is no standard covering VLAs in C++,
it is all extensions, it is defined however we want.  UB when storing something
larger into something smaller is perfectly fine, users can put their own checks
if they want to avoid it.  You want to slow all the code down by doing the
checks mandatory.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 30 07:15:39 2017
New Revision: 246583

URL: https://gcc.gnu.org/viewcvs?rev=246583=gcc=rev
Log:
2017-03-30  Richard Biener  

PR tree-optimization/77498
* tree-ssa-pre.c (phi_translate_1): Do not allow simplifications
to non-constants over backedges.

* gfortran.dg/pr77498.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77498.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug fortran/80257] Cygwin test fail: pointer_check_1.f90 output test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
If you compile the test with -fcheck=pointer, you should see at run time
something such as

 Hello World
 Hello World
At line 53 of file
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/pointer_check_1.f90
Fortran runtime error: Allocatable actual argument 'alloc2' is not allocated

Error termination. Backtrace:
#0  0x10b369bbc
#1  0x10b36a8c5
#2  0x10b36ac6a
#3  0x10b362494
#4  0x10b362666

Am I understanding correctly comment 0 that you don't see the "Hello World"?

Did you test pointer_check_2.f90 and pointer_check_3.f90? They should behave as
pointer_check_1.f90.

[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Markus Trippelsdorf  ---
Fixed by Segher's commit.