[Bug preprocessor/80231] Error missing binary operator before token "("

[sbansal at ciena dot com]

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

--- Comment #2 from Sumit  ---
(In reply to Andrew Pinski from comment #1)
> Looks like a dup of bug 36453.

Hi Andrew,

yes I did check that and modified the code like below :

#elif (LINUX || ME_BSD_LIKE) && defined(KERNEL_VERSION) &&
(LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0))


but no help. Am I doing something wrong here?

[Bug testsuite/80220] relative line numbers don't work when put between braces

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01423.html

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Good news, I have this sorted out and working now with Janus patch for the
namelist write portion.

We were calling the child procedure too early in nml_get_obj_data when we
should have called it in nml_read_obj, after nml_get_obj_data has parsed '='
and other variable qualifiers as with any other namelist.

I will post the patch to list after Janus commits the other portion.

[Bug preprocessor/80231] Error missing binary operator before token "("

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Looks like a dup of bug 36453.

[Bug preprocessor/80231] New: Error missing binary operator before token "("

[sbansal at ciena dot com]

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

Bug ID: 80231
   Summary: Error missing binary operator before token "("
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

My product is being migrating from GCC 4.4.1 to 4.8.1 and while compiling the
existing code with newer tool chain, I am seeing below error :

In file included from
/vobs/optnet_comms/comms_applications/3rdparty/appweb/current/src/mpr/mprLib.c:5:0:
/vobs/optnet_comms/comms_applications/3rdparty/appweb/current/src/mpr/mpr.h:207:74:
error: missing binary operator before token "("
 #elif (LINUX || ME_BSD_LIKE) && (LINUX_VERSION_CODE >=
KERNEL_VERSION(2,6,0))

[Bug tree-optimization/80216] [7 Regression] Memory hog w/ -O1

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: law
Date: Tue Mar 28 03:22:25 2017
New Revision: 246517

URL: https://gcc.gnu.org/viewcvs?rev=246517&root=gcc&view=rev
Log:
PR tree-optimization/80162
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): Fix typo in
function name.  Limit recursion depth.
(record_temporary_equivalences): Corresponding changes.

PR tree-optimization/80162
* gcc.c-torture/compile/pr80216.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr80216.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug libfortran/78793] list_read.c: 7 * possible unintended fallthrough ?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
Closing, fixed by:

Done as revision r246507.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #16 from Jerry DeLisle  ---
(In reply to Rainer Orth from comment #15)

Can you change line:

if (imsg.ne."End of record") call abort

to:

if (imsg.ne."End of record") print *, imsg

and lets see what its saying.

My guess is I may need to initialize something before calling the child I/O
procedure.

[Bug tree-optimization/78496] [7 Regression] Missed opportunities for jump threading

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0

--- Comment #7 from Jeffrey A. Law  ---
While I've got changes which I think will address the problems in this BZ;
given how late we are in stage4, I'm going to defer to gcc-8.

[Bug tree-optimization/80216] [7 Regression] Memory hog w/ -O1

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/80162] [5/6 Regression] ICE on invalid code (address of register variable)

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 28 03:22:25 2017
New Revision: 246517

URL: https://gcc.gnu.org/viewcvs?rev=246517&root=gcc&view=rev
Log:
PR tree-optimization/80162
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): Fix typo in
function name.  Limit recursion depth.
(record_temporary_equivalences): Corresponding changes.

PR tree-optimization/80162
* gcc.c-torture/compile/pr80216.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr80216.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug c++/80230] error accessing struct member, error says it's size_t, but it is int

[jmichae3 at yahoo dot com]

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

--- Comment #2 from Jim Michaels  ---
how did I misunderstand the error message? it's pretty clear. the compiler says
the type is size_t when it really should be saying int, and size_t is for x32
an unsigned int and for x64 it's unsigned long long but it's /not/ a signed
int.

I really don't think there is any confusion here.

[Bug c++/80230] error accessing struct member, error says it's size_t, but it is int

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
You are misunderstanding the error message.
What it is trying to say the type of vecstruct[vecstructfromi(A)] is size_t and
not the struct type you think it is.

[Bug c++/80230] New: error accessing struct member, error says it's size_t, but it is int

[jmichae3 at yahoo dot com]

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

Bug ID: 80230
   Summary: error accessing struct member, error says it's size_t,
but it is int
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmichae3 at yahoo dot com
  Target Milestone: ---

atoi64.cpp:1398:84: error: request for member 'i' in
'vecstruct[vecstructfromi(5ll)]', which is of non-class type 'size_t {aka long
long unsigned int}'
enum{A=5};
...
   } else if
(!foundMode&&static_cast(vecstruct[vecstructfromi(A)].i)==static_cast(A))
{

i is of type int, not size_t. struct looks like:
struct {int i;intmax_t v;}

[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-28
  Known to work||6.3.1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The _M_enable_shared_from_this parameters are only const to save needing to use
remove_const<_Yp>::type to get the non-const type, so not needed. I have a
patch.

[Bug libstdc++/80229] New: [7 Regression] shared_ptr gives an error when is_function is true

[redi at gcc dot gnu.org]

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

Bug ID: 80229
   Summary: [7 Regression] shared_ptr gives an error when
is_function is true
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct Foo {};
using FooFn = Foo ();
using FooFnPtr = Foo (*)();
using FooDel = void (*)(FooFnPtr);
static_assert(std::is_same::value, "");

void del(FooFnPtr) {}
Foo fun() { return {}; }

int main() {
std::shared_ptr(&fun, &del);
}

This compiled with previous versions, but since the enable_shared_from_this
refactoring on trunk it results in an error. I don't see anything in the
standard that says it shouldn't work.

The _M_enable_shared_from_this overloads both take const _Yp* and when _Yp is a
function type there's no conversion from _Yp* to const _Yp*.

In file included from
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr.h:52:0,
 from /home/jwakely/gcc/7/include/c++/7.0.1/memory:81,
 from sp.cc:1:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h: In instantiation
of ‘std::__shared_ptr<_Tp, _Lp>::__shared_ptr(_Yp*, _Deleter) [with _Yp =
Foo(); _Deleter = void (*)(Foo (*)());  = void; _Tp =
Foo(); __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2]’:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr.h:147:37:   required from
‘std::shared_ptr<_Tp>::shared_ptr(_Yp*, _Deleter) [with _Yp = Foo(); _Deleter =
void (*)(Foo (*)());  = void; _Tp = Foo()]’
sp.cc:13:38:   required from here
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1090:35: error: no
matching function for call to ‘std::__shared_ptr::_M_enable_shared_from_this_with(Foo (*&)())’
_M_enable_shared_from_this_with(__p);
~~~^
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1368:2: note:
candidate: template typename std::enable_if::__has_esft_base<_Yp>::value>::type std::__shared_ptr<_Tp,
_Lp>::_M_enable_shared_from_this_with(const _Yp*) [with _Yp = _Yp; _Tp = Foo();
__gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2]
  _M_enable_shared_from_this_with(const _Yp* __p) noexcept
  ^~~
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1368:2: note:  
template argument deduction/substitution failed:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1090:35: note:  
types ‘const _Yp’ and ‘Foo()’ have incompatible cv-qualifiers
_M_enable_shared_from_this_with(__p);
~~~^
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1376:2: note:
candidate: template typename std::enable_if<(!
std::__shared_ptr<_Tp, _Lp>::__has_esft_base<_Yp>::value)>::type
std::__shared_ptr<_Tp, _Lp>::_M_enable_shared_from_this_with(const _Yp*) [with
_Yp = _Yp; _Tp = Foo(); __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2]
  _M_enable_shared_from_this_with(const _Yp*) noexcept
  ^~~
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1376:2: note:  
template argument deduction/substitution failed:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1090:35: note:  
types ‘const _Yp’ and ‘Foo()’ have incompatible cv-qualifiers
_M_enable_shared_from_this_with(__p);
~~~^

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
A more robust solution that wouldn't have to subject to a limit would be to add
an annotation to dg-{error,message,warning} to indicate that the next
dg-{bogus,error,message,warning} directive is meant to be applied to the same
line as the current one.  For instance, something like this:

  foobar;
  /* { dg-warning "warning for foobar" continue }
 { dg-warning "another warning for foobar" continue }
 { dg-error "error for foobar" } */

(For brevity I omitted the comment and the { target ... } parts of the
directives above.  It would also be nice to be able to do away with those when
they're not necessary.)

[Bug c++/80228] inconsistent handling of ctor initialization of flexible array members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||rejects-valid
 Blocks||69698

--- Comment #1 from Martin Sebor  ---
This is either accepts-invalid or rejects-valid depending on one's perspective.

The diagnostic to reject the NSDMI was actually introduced to fix pr79363
(pr72775 just extended it to another, similar case).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
[Bug 69698] [meta-bug] flexible array members

[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.

[tobias.netzel at googlemail dot com]

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

Tobias Netzel  changed:

   What|Removed |Added

 CC||tobias.netzel at googlemail 
dot co
   ||m

--- Comment #6 from Tobias Netzel  ---
This fix seems to have had an unwanted sideeffect:
When not compiling with -fno-PIC or -mdynamic-no-pic the compiler for any
compiled function unconditionally saves and restores R31 from/to the stack even
when it's not touched at all.

I've verified that gcc 4.2 (Apple's version), gcc 4.9 and 5.4 don't do that.
But while gcc 4.9 and 5.4 do unconditionally save and restore R31 when -pg is
passed, Apple's gcc 4.2 doesn't even do it then.

Appearantly the interpretation of what Apple meant with the sentence "This
cannot happen with -fPIC because the PIC register (R31) is always "used" in the
sense checked by the consistency check." might need to be revised.

[Bug c++/80228] New: inconsistent handling of ctor initialization of flexible array members

[msebor at gcc dot gnu.org]

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

Bug ID: 80228
   Summary: inconsistent handling of ctor initialization of
flexible array members
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ is inconsistent in diagnosing equivalent forms of initialization of
flexible array members.  The following test case shows that of the four kinds
of initialization it only rejects one.  The other three are accepted.  Of those
three, only two initializers are diagnosed with -Wpedantic.  The one in struct
D, i.e., the initialization of D::a3, is accepted without a warning.  As
discussed in bug 69338, GCC also emits incorrect code for the initializers.

GCC should treat equivalent forms of initialization consistently: either it
should accept them all (possibly diagnosing them with a warning, ideally one
distinct from -Wpedantic), or it should reject them all.

$ cat z.C && gcc -S -Wall -Wextra -Wpedantic z.C
struct A { int n, a[]; };

struct B
{
  int n = 3;
  int a1[] = { 2, 1, 0 };  // rejected (see pr72775)
} b;

struct C
{
  A a2 = { 3, { 2, 1, 0 } };   // accepted
} c;

struct D
{
  int n, a3[];

  D ():
n (3),
a3 {2, 1, 0} { }   // silently accepted
} d;

struct E
{
  A a4;

  E ():
a4 {3, { 2, 1, 0 } } { }   // accepted
} e;
z.C:1:21: warning: ISO C++ forbids flexible array member ‘a’ [-Wpedantic]
 struct A { int n, a[]; };
 ^
z.C:6:24: warning: ISO C++ forbids flexible array member ‘a1’ [-Wpedantic]
   int a1[] = { 2, 1, 0 };  // rejected (see pr 72775)
^
z.C:6:24: error: initializer for flexible array member ‘int B::a1 []’
z.C:11:27: warning: invalid use of ‘struct A’ with a flexible array member in
‘struct C’ [-Wpedantic]
   A a2 = { 3, { 2, 1, 0 } };   // accepted
   ^
z.C:1:21: note: array member ‘int A::a []’ declared here
 struct A { int n, a[]; };
 ^
z.C:11:27: warning: initialization of a flexible array member [-Wpedantic]
   A a2 = { 3, { 2, 1, 0 } };   // accepted
   ^
z.C:16:13: warning: ISO C++ forbids flexible array member ‘a3’ [-Wpedantic]
   int n, a3[];
 ^
z.C:25:5: warning: invalid use of ‘struct A’ with a flexible array member in
‘struct E’ [-Wpedantic]
   A a4;
 ^~
z.C:1:21: note: array member ‘int A::a []’ declared here
 struct A { int n, a[]; };
 ^
z.C: In constructor ‘E::E()’:
z.C:28:24: warning: initialization of a flexible array member [-Wpedantic]
 a4 {3, { 2, 1, 0 } } { }   // accepted
^

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[mikestump at comcast dot net]

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

--- Comment #6 from Mike Stump  ---
Comment on attachment 41059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41059
Result from running script

The . and .-1, .+1, .-2 forms are fine.  The .-62 forms are as problematic as
the original I suspect.  I think we should exclude any number greater than some
small int, say, 9.  So, .-9 .. .+9 in the new form only.  If outside that
range, I think I'd rather punt.  The idea is that the absolute number at least
has a line number that in an editor you can go directly to, and it corresponds
with the number in the error messages directly, aiding understanding which one
is referred to without having to ungoop the relative number first.

Let's see if anyone else has any comments.  If not, I'd pre-approve the change
with the range reduced.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> Created attachment 41058 [details]
> tested patch

tested in combination with fix for PR80220.

[Bug testsuite/80220] relative line numbers don't work when put between braces

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #41056|0   |1
is obsolete||

--- Comment #2 from Tom de Vries  ---
Created attachment 41060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41060&action=edit
tested patch

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #15 from Rainer Orth  ---
The new testcase FAILs on 64-bit Solaris/SPARC:

+FAIL: gfortran.dg/dtio_26.f03   -O0  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O1  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O2  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O3 -g  execution test
+FAIL: gfortran.dg/dtio_26.f03   -Os  execution test

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
(gdb) where
#0  0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
#1  0x7f02949c in raise () from /lib/64/libc.so.1
#2  0x7eff8174 in abort () from /lib/64/libc.so.1
#3  0x2d039dc4 in _gfortrani_sys_abort ()
at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180
#4  0x2d11840c in _gfortran_abort ()
at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:32
#5  0x0001236c in p ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
#6  0x000124d8 in main (argc=1, argv=0x784c)
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:46
#7  0x000114ac in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

#5  0x0001236c in p ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
64if (imsg.ne."End of record") call abort
(gdb) p imsg
$1 = ' ' 

  Rainer

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 41059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41059&action=edit
Result from running script

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #41057|0   |1
is obsolete||

--- Comment #3 from Tom de Vries  ---
Created attachment 41058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41058&action=edit
tested patch

[Bug c++/80227] New: [4.6/5/6/7 Regression] SFINAE ambiguity with a pointer to array argument

[msebor at gcc dot gnu.org]

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

Bug ID: 80227
   Summary: [4.6/5/6/7 Regression] SFINAE ambiguity with a pointer
to array argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to version 4.6, GCC accepted the well-formed program below.  Since
r166453 GCC rejects it because it fails to eliminate the second overload of the
foo template from the overload list.  The second overload isn't viable because
substituting int for T results in the second argument to the function having an
invalid type (pointer to an array of excessive size).

$ cat y.C && gcc -S -Wall -Wextra -Wpedantic y.C
template 
int foo (T);

template 
int foo (T, U* = 0);

int i = foo (123);
y.C:7:17: error: call of overloaded ‘foo(int)’ is ambiguous
 int i = foo (123);
 ^
y.C:2:5: note: candidate: int foo(T) [with T = int]
 int foo (T);
 ^~~
y.C:5:5: note: candidate: int foo(T, U*) [with T = int; U = int [-1]]
 int foo (T, U* = 0);
 ^~~


Conversely, while prior to r166453 GCC would reject the following invalid
program

template 
int foo (T, int (*)[sizeof (T) - 5] = 0);

int i = foo (123);

with

t.C:4:17: error: no matching function for call to ‘foo(int)’
t.C:2:40: note: candidate is: template int foo(T, int (*)[(sizeof (T)
- 5)])

GCC 4.6 and later accept it.

[Bug target/68028] [5/6/7 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|powerpc-pc-linux|powerpc-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-27
 CC||ebotcazou at gcc dot gnu.org
  Known to work||4.9.3
Summary|Compilation error "lto1:|[5/6/7 regression]
   |error: target attribute or  |Compilation error "lto1:
   |pragma changes single   |error: target attribute or
   |precision floating point",  |pragma changes single
   |with "-flto" on different   |precision floating point"
   |variant of powerpc like |with LTO on PowerPC
   |-mcpu=e6500, 8540, 8548,|
   |e500mc, e500mc64, e5500.|
   |With gcc-5.2.0 while with   |
   |4.9.3 it is working fine.   |
 Ever confirmed|0   |1
  Known to fail||5.2.0, 6.3.1
  Build|x86_64-pc-linux |

--- Comment #7 from Eric Botcazou  ---
We have it too.

[Bug target/80162] [5/6 Regression] ICE on invalid code (address of register variable)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |invalid code (address of|invalid code (address of
   |register variable)  |register variable)

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.  Not sure if this isn't too risky for backporting.

[Bug target/80102] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/80162] [5/6/7 Regression] ICE on invalid code (address of register variable)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 27 21:07:21 2017
New Revision: 246512

URL: https://gcc.gnu.org/viewcvs?rev=246512&root=gcc&view=rev
Log:
PR middle-end/80162
c-family/
* c-common.c (c_common_mark_addressable_vec): Don't set
TREE_ADDRESSABLE on DECL_HARD_REGISTER.
c/
* c-tree.h (c_mark_addressable): Add array_ref_p argument.
* c-typeck.c (c_mark_addressable): Likewise.  Look through
VIEW_CONVERT_EXPR unless array_ref_p and VCE is from VECTOR_TYPE
to ARRAY_TYPE.
(build_array_ref): Pass true as array_ref_p to c_mark_addressable.
cp/
* cp-tree.h (cxx_mark_addressable): Add array_ref_p argument.
* typeck.c (cxx_mark_addressable): Likewise.  Look through
VIEW_CONVERT_EXPR unless array_ref_p and VCE is from VECTOR_TYPE
to ARRAY_TYPE.
(cp_build_array_ref): Pass true as array_ref_p to cxx_mark_addressable.
testsuite/
* c-c++-common/pr80162-1.c: New test.
* c-c++-common/pr80162-2.c: New test.
* c-c++-common/pr80162-3.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr80162-1.c
trunk/gcc/testsuite/c-c++-common/pr80162-2.c
trunk/gcc/testsuite/c-c++-common/pr80162-3.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80102] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 27 21:00:35 2017
New Revision: 246511

URL: https://gcc.gnu.org/viewcvs?rev=246511&root=gcc&view=rev
Log:
PR target/80102
* reg-notes.def (REG_CFA_NOTE): Define.  Use it for CFA related
notes.
* cfgcleanup.c (reg_note_cfa_p): New array.
(insns_have_identical_cfa_notes): New function.
(old_insns_match_p): Don't cross-jump in between /f
and non-/f instructions.  If both i1 and i2 are frame related,
verify all CFA notes, their order and content.

* g++.dg/opt/pr80102.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr80102.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/reg-notes.def
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/80224] gcov -i crashes with two arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-27
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug c++/80191] diagnostic placeholder "new initializer" must be marked for translation

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
No, not if I'm right that it's referring to new-initializer. The C++ standard
defines a new-expression and a new-initializer, and those are related to the
'new' keyword, but they are not keywords.

[Bug c++/80191] diagnostic placeholder "new initializer" must be marked for translation

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #4)
> At the very least, "new" shouldn't be translated, because it refers to the
> C++ keyword, which is always spelled "new" and not "neu" or "nouveau" or
> anything else. It's an initializer for a new-expression, not an initializer
> that is newer than some other initializer.

Then, it should be "% initializer". Keywords should always be quoted:
https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting

[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 #4 from Jakub Jelinek  ---
So far I have:
--- gcc/config/i386/sse.md.jj   2017-03-16 17:18:42.0 +0100
+++ gcc/config/i386/sse.md  2017-03-27 21:26:23.570172997 +0200
@@ -7135,19 +7135,22 @@ (define_expand "_vextract<
 {
   int mask;
   mask = INTVAL (operands[2]);
+  rtx dest = operands[0];

-  if (MEM_P (operands[0]) && GET_CODE (operands[3]) == CONST_VECTOR)
-operands[0] = force_reg (mode, operands[0]);
+  if (MEM_P (operands[0]) && !rtx_equal_p (operands[0], operands[3]))
+dest = force_reg (mode, dest);

   if (mode == V16SImode || mode == V16SFmode)
-emit_insn (gen_avx512f_vextract32x4_1_mask (operands[0],
+emit_insn (gen_avx512f_vextract32x4_1_mask (dest,
 operands[1], GEN_INT (mask * 4), GEN_INT (mask * 4 + 1),
GEN_INT (mask * 4 + 2), GEN_INT (mask * 4 + 3), operands[3],
operands[4]));
   else
-emit_insn (gen_avx512dq_vextract64x2_1_mask (operands[0],
+emit_insn (gen_avx512dq_vextract64x2_1_mask (dest,
 operands[1], GEN_INT (mask * 2), GEN_INT (mask * 2 + 1), operands[3],
operands[4]));
+  if (dest != operands[0])
+emit_move_insn (operands[0], dest);
   DONE;
 })

@@ -7161,8 +7164,8 @@ (define_insn "avx512dq_vextract 4 "memory_operand" "0")
  (match_operand:QI 5 "register_operand" "Yk")))]
   "TARGET_AVX512DQ
-   && (INTVAL (operands[2]) % 2 == 0)
-   && (INTVAL (operands[2]) == INTVAL (operands[3]) - 1)
+   && INTVAL (operands[2]) % 2 == 0
+   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
&& rtx_equal_p (operands[4], operands[0])"
 {
   operands[2] = GEN_INT ((INTVAL (operands[2])) >> 1);
@@ -7187,13 +7190,13 @@ (define_insn "avx512f_vextract 6 "memory_operand" "0")
  (match_operand:QI 7 "register_operand" "Yk")))]
   "TARGET_AVX512F
-   && ((INTVAL (operands[2]) % 4 == 0)
-   && INTVAL (operands[2]) == (INTVAL (operands[3]) - 1)
-   && INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
-   && INTVAL (operands[4]) == (INTVAL (operands[5]) - 1))
+   && INTVAL (operands[2]) % 4 == 0
+   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
+   && INTVAL (operands[3]) == INTVAL (operands[4]) - 1
+   && INTVAL (operands[4]) == INTVAL (operands[5]) - 1
&& rtx_equal_p (operands[6], operands[0])"
 {
-  operands[2] = GEN_INT ((INTVAL (operands[2])) >> 2);
+  operands[2] = GEN_INT (INTVAL (operands[2]) >> 2);
   return "vextract32x4\t{%2, %1, %0%{%7%}|%0%{%7%}, %1, %2}";
 }
   [(set_attr "type" "sselog")
@@ -7209,9 +7212,11 @@ (define_insn "avx512dq_vex
  (match_operand:V8FI 1 "register_operand" "v")
  (parallel [(match_operand 2  "const_0_to_7_operand")
 (match_operand 3  "const_0_to_7_operand")])))]
-  "TARGET_AVX512DQ && (INTVAL (operands[2]) == INTVAL (operands[3]) - 1)"
+  "TARGET_AVX512DQ
+   && INTVAL (operands[2]) % 2 == 0
+   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1"
 {
-  operands[2] = GEN_INT ((INTVAL (operands[2])) >> 1);
+  operands[2] = GEN_INT (INTVAL (operands[2]) >> 1);
   return "vextract64x2\t{%2, %1,
%0|%0, %1, %2}";
 }
   [(set_attr "type" "sselog1")
@@ -7229,11 +7234,12 @@ (define_insn "avx512f_vext
 (match_operand 4  "const_0_to_15_operand")
 (match_operand 5  "const_0_to_15_operand")])))]
   "TARGET_AVX512F
-   && (INTVAL (operands[2]) == (INTVAL (operands[3]) - 1)
-   && INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
-   && INTVAL (operands[4]) == (INTVAL (operands[5]) - 1))"
+   && INTVAL (operands[2]) % 4 == 0
+   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
+   && INTVAL (operands[3]) == INTVAL (operands[4]) - 1
+   && INTVAL (operands[4]) == INTVAL (operands[5]) - 1"
 {
-  operands[2] = GEN_INT ((INTVAL (operands[2])) >> 2);
+  operands[2] = GEN_INT (INTVAL (operands[2]) >> 2);
   return "vextract32x4\t{%2, %1,
%0|%0, %1, %2}";
 }
   [(set_attr "type" "sselog1")
@@ -7260,9 +7266,10 @@ (define_expand "_vextrac
   "TARGET_AVX512F"
 {
   rtx (*insn)(rtx, rtx, rtx, rtx);
+  rtx dest = operands[0];

-  if (MEM_P (operands[0]) && GET_CODE (operands[3]) == CONST_VECTOR)
-operands[0] = force_reg (mode, operands[0]);
+  if (MEM_P (dest) && !rtx_equal_p (dest, operands[3]))
+dest = force_reg (mode, dest);

   switch (INTVAL (operands[2]))
 {
@@ -7276,7 +7283,9 @@ (define_expand "_vextrac
   gcc_unreachable ();
 }

-  emit_insn (insn (operands[0], operands[1], operands[3], operands[4]));
+  emit_insn (insn (dest, operands[1], operands[3], operands[4]));
+  if (dest != operands[0])
+emit_move_insn (operands[0], dest);
   DONE;
 })

@@ -7317,7 +7326,7 @@ (define_insn "vec_extract_lo_ || !(MEM_P (operands[0]) && MEM_P
(operands[1])))"
 {
   if ( || !TARGET_AVX512VL)
 return "vextract64x4\t{$0x0, %1,
%0|%0, %1, 0x0}";


but there is more to do.

[Bug c++/69697] incorrect initialization of static flexible array members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-27
 Ever confirmed|0   |1
  Known to fail||5.3.1, 6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirming.  To make things worse, the program output changes between -O0 and
-O1:

$ (for o in 0 1 2 3; do gcc  -O$o -Wall -Wextra y.C && ./a.out; done)
i = 0, j = 3, a = { 2, { 3, 4, } }
i = 3, j = 0, a = { 2, { 3, 4, } }
i = 3, j = 0, a = { 2, { 3, 4, } }
i = 3, j = 0, a = { 2, { 3, 4, } }

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #72 from Jason Merrill  ---
(In reply to rguent...@suse.de from comment #69)
> As I noted elsewhere union members in C++ seem to be pure convenience and a
> union contains implicit members of all types (well, somehow factor in
> alignment).  Of course Jason argues char[] is special and introduces this
> but I can't find text anywhere to support that or require char[] and not,
> say int[].

This is clarified somewhat in C++17, by

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html

Note that this wording makes only unsigned char[] special, not signed or plain
char[].

[Bug go/80226] ICE gimple-expr.c:474 on Go function returning multiple empty struct/array values

[thanm at google dot com]

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

--- Comment #1 from Than McIntosh  ---

This seems to do the trick:

diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index ed6fc2c6105..62baa91fab8 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -2081,7 +2081,8 @@ Gcc_backend::return_statement(Bfunction* bfunction,
   // If the result size is zero bytes, we have set the function type
   // to have a result type of void, so don't return anything.
   // See the function_type method.
-  if (int_size_in_bytes(TREE_TYPE(result)) == 0)
+  tree res_type = TREE_TYPE(result);
+  if (res_type == void_type_node || int_size_in_bytes(res_type) == 0)
 {
   tree stmt_list = NULL_TREE;
   for (std::vector::const_iterator p = vals.begin();

[Bug go/80226] New: ICE gimple-expr.c:474 on Go function returning multiple empty struct/array values

[thanm at google dot com]

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

Bug ID: 80226
   Summary: ICE gimple-expr.c:474 on Go function returning
multiple empty struct/array values
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: thanm at google dot com
CC: cmang at google dot com
  Target Milestone: ---

Compiling the attached test case with gccgo results in an ICE. Example:

$ go build -compiler gccgo repro.go
# command-line-arguments
In function ‘repro.Test36’:
go1: internal compiler error: in create_tmp_var, at gimple-expr.c:474
0xc2ace4 create_tmp_var(tree_node*, char const*)
../../gcc-trunk/gcc/gimple-expr.c:474
0x8f5f37 Gcc_backend::return_statement(Bfunction*, std::vector > const&, Location)
../../gcc-trunk/gcc/go/go-gcc.cc:2135
0x96f3b9 Return_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:2838
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x96c772 Block_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:1850
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x96ff8e If_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:3178
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x96c772 Block_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:1850
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x9198ef Function::build(Gogo*, Named_object*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:5629
0x91ebf0 Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:7411
0x90cad1 Gogo::write_globals()
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:1322
0x90679e go_write_globals()
../../gcc-trunk/gcc/go/gofrontend/go.cc:174
0x8fd2e1 go_langhook_parse_file
../../gcc-trunk/gcc/go/go-lang.c:318
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This is with trunk gccgo:

$ gccgo --version
gccgo (GCC) 7.0.1 20170322 (experimental)
$

Excerpt from the function:

func Test36(p0 uint64, p1 StructF36S0, p2 uint8, p3 int32, p4 StructF36S1) (r0
StructF36S2, r1 ArrayF36S0E0, r2 ArrayF36S1E0) {
rc0 := StructF36S2{}
rc1 := ArrayF36S0E0{}
rc2 := ArrayF36S1E0{}
if p0 == 0 {
return rc0, rc1, rc2
}

where r0/r1/r2 are all zero-sized arrays or empty structures.

I spent a little while poking around -- from what I can tell there is code
already in Gcc_backend::return_statement designed to catch this case (returning
empty-sized stuff), however it doesn't appear to be working correctly. Line is

  if (int_size_in_bytes(TREE_TYPE(result)) == 0)

however this call is returning -1 in this case (since TREE_TYPE(result) is the
void type).

I will work on a fix.

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #24 from Michael Meissner  ---
Fixed in the trunk subversion id 246508, and on the GCC 6.x branch in
subversion id 246509.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

--- Comment #71 from Jonathan Wakely  ---
(In reply to Michael Matz from comment #68)
> (In reply to Jonathan Wakely from comment #65)
> > It accesses b, but it doesn't access the object stored in b's char[N] member
> > via placement new.
> 
> Okay, let's go with this.  So the copying of the union is then defined
> (as a memcpy equivalent).  Then there's still the question if the following
> sequences are valid:
> 
> // assume T1 and T2 are some types and new is trivial placement new
> union U {T1 a; char b[sizeof T2];} x,y;
> new (x.b) T2();  // 1
> y = x;   // 2
> T2 t;
> memcpy(&t, y.b, sizeof T2);  // 3
> t;   // 4
> y.a; // 5
> 
> We have said that (2) is valid, obviously (3) in isolation is valid as well,

N.B. (3) is not valid if T2 isn't trivially copyable. But for the cases we care
about, it is (the code takes a completely different path otherwise).

> but it influences the validity of (4).  (5) is invalid as it's not the
> active member of the union y (which is instead b).
> 
> (4) is valid if y.b contained a T2, which is only the case if (2) transferred
> the dynamic type from x.b _and_ (1) was valid to start with and dynamically
> typed x.b to be of type T2.
> 
> So, it all boils down to if (1) is valid and types x.b to T2, even though it
> has a different declared type.

I don't think it changes the type of x.b, but it does begin the lifetime of an
object of type T2 at that location. 

As I see it, the question is whether copying the object representation of that
object to another location means we have another object at the second location.
We all seem to agree that copying the object representation using memcpy *does*
do that. We don't agree whether copying the object representation via an
implicit union copy does that.

I don't see a distinction between copying the object representation via memcpy
or the union copy.

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #23 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 27 19:35:35 2017
New Revision: 246509

URL: https://gcc.gnu.org/viewcvs?rev=246509&root=gcc&view=rev
Log:
[gcc]
2017-03-27  Michael Meissner  

Back port from trunk
2017-03-27  Michael Meissner  

PR target/78543
* config/rs6000/rs6000.md (bswaphi2_extenddi): Combine bswap
HImode and SImode with zero extend to DImode to one insn.
(bswap2_extenddi): Likewise.
(bswapsi2_extenddi): Likewise.
(bswaphi2_extendsi): Likewise.
(bswaphi2): Combine bswap HImode and SImode into one insn.
Separate memory insns from swapping register.
(bswapsi2): Likewise.
(bswap2): Likewise.
(bswaphi2_internal): Delete, no longer used.
(bswapsi2_internal): Likewise.
(bswap2_load): Split bswap HImode/SImode into separate load,
store, and gpr<-gpr swap insns.
(bswap2_store): Likewise.
(bswaphi2_reg): Register only splitter, combine with the splitter.
(bswaphi2 splitter): Likewise.
(bswapsi2_reg): Likewise.
(bswapsi2 splitter): Likewise.
(bswapdi2): If we have the LDBRX and STDBRX instructions, split
the insns into load, store, and register/register insns.
(bswapdi2_ldbrx): Likewise.
(bswapdi2_load): Likewise.
(bswapdi2_store): Likewise.
(bswapdi2_reg): Likewise.

[gcc/testsuite]
2017-03-27  Michael Meissner  

Back port from trunk
2017-03-27  Michael Meissner  

PR target/78543
* gcc.target/powerpc/pr78543.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr78543.c
  - copied unchanged from r246508,
trunk/gcc/testsuite/gcc.target/powerpc/pr78543.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
(In reply to janus from comment #5)
> (In reply to Jerry DeLisle from comment #4)
> > Janus, the fix for this bug depends on your patch for pr78661. I would like
> > to incorporate yours into the solution to this PR if ok with you.
> 
> Sure, go ahead. If you think the last version is ok, I can also commit it,
> so that you have it out of your back ...

yes, OK to commit it if you can adjust the test case appropriately.  I will
then be working on adjusting the namelist read things to make make it work.

Please send a note to gfortran list that you have committed per my approval.

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #22 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 27 19:19:00 2017
New Revision: 246508

URL: https://gcc.gnu.org/viewcvs?rev=246508&root=gcc&view=rev
Log:
[gcc]
2017-03-27  Michael Meissner  

PR target/78543
* config/rs6000/rs6000.md (bswaphi2_extenddi): Combine bswap
HImode and SImode with zero extend to DImode to one insn.
(bswap2_extenddi): Likewise.
(bswapsi2_extenddi): Likewise.
(bswaphi2_extendsi): Likewise.
(bswaphi2): Combine bswap HImode and SImode into one insn.
Separate memory insns from swapping register.
(bswapsi2): Likewise.
(bswap2): Likewise.
(bswaphi2_internal): Delete, no longer used.
(bswapsi2_internal): Likewise.
(bswap2_load): Split bswap HImode/SImode into separate load,
store, and gpr<-gpr swap insns.
(bswap2_store): Likewise.
(bswaphi2_reg): Register only splitter, combine with the splitter.
(bswaphi2 splitter): Likewise.
(bswapsi2_reg): Likewise.
(bswapsi2 splitter): Likewise.
(bswapdi2): If we have the LDBRX and STDBRX instructions, split
the insns into load, store, and register/register insns.
(bswapdi2_ldbrx): Likewise.
(bswapdi2_load): Likewise.
(bswapdi2_store): Likewise.
(bswapdi2_reg): Likewise.

[gcc/testsuite]
2017-03-27  Michael Meissner  

PR target/78543
* gcc.target/powerpc/pr78543.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr78543.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> Janus, the fix for this bug depends on your patch for pr78661. I would like
> to incorporate yours into the solution to this PR if ok with you.

Sure, go ahead. If you think the last version is ok, I can also commit it, so
that you have it out of your back ...

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[matz at gcc dot gnu.org]

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

--- Comment #70 from Michael Matz  ---
(In reply to rguent...@suse.de from comment #69)
> As I noted elsewhere union members in C++ seem to be pure convenience and a
> union contains implicit members of all types (well, somehow factor in
> alignment).

Well, the whole introduction of "object representation" is clearly a very bad
idea if you want to avoid the above, but let's assume that the above is really
not intended.  So let's wait for answers to the questions and not see darkness
wherever we go :)

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

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

--- Comment #69 from rguenther at suse dot de  ---
On March 27, 2017 8:11:10 PM GMT+02:00, "matz at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>
>--- Comment #68 from Michael Matz  ---
>(In reply to Jonathan Wakely from comment #65)
>> It accesses b, but it doesn't access the object stored in b's char[N]
>member
>> via placement new.
>
>Okay, let's go with this.  So the copying of the union is then defined
>(as a memcpy equivalent).  Then there's still the question if the
>following
>sequences are valid:
>
>// assume T1 and T2 are some types and new is trivial placement new
>union U {T1 a; char b[sizeof T2];} x,y;
>new (x.b) T2();  // 1
>y = x;   // 2
>T2 t;
>memcpy(&t, y.b, sizeof T2);  // 3
>t;   // 4
>y.a; // 5
>
>We have said that (2) is valid, obviously (3) in isolation is valid as
>well,
>but it influences the validity of (4).  (5) is invalid as it's not the
>active member of the union y (which is instead b).
>
>(4) is valid if y.b contained a T2, which is only the case if (2)
>transferred
>the dynamic type from x.b _and_ (1) was valid to start with and
>dynamically
>typed x.b to be of type T2.
>
>So, it all boils down to if (1) is valid and types x.b to T2, even
>though it
>has a different declared type.  For C we say it's not, because char[]
>is
>asymmetric: you can access all types via a char*, but you can't change
>the
>dynamic type of a declared char array to contain arbitrary other things
>(well,
>the ME memory model does cater for this and makes it valid, even though
>it's
>invalid in C).
>
>I guess you're arguing that (1) is valid in C++ and that then due to
>3.9/3
>and 12.8/29 also (2) and (4) are.  I guess it can be defined to be so,
>but
>I wonder what the type of 'x' is after (1)?  It can't be T2, because
>clearly
>x.b is valid even if T2 doesn't contain a member 'b'.  So it must stay
>a union,
>but in order to transfer the type T2 in (2) it must also contain T2, so
>is it
>the type 'union {T1 a; char b[sizeof T2]; T2 ;}' then
>(conceptually)?
>Messy :)

As I noted elsewhere union members in C++ seem to be pure convenience and a
union contains implicit members of all types (well, somehow factor in
alignment).  Of course Jason argues char[] is special and introduces this but I
can't find text anywhere to support that or require char[] and not, say int[].

Richard.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[matz at gcc dot gnu.org]

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

--- Comment #68 from Michael Matz  ---
(In reply to Jonathan Wakely from comment #65)
> It accesses b, but it doesn't access the object stored in b's char[N] member
> via placement new.

Okay, let's go with this.  So the copying of the union is then defined
(as a memcpy equivalent).  Then there's still the question if the following
sequences are valid:

// assume T1 and T2 are some types and new is trivial placement new
union U {T1 a; char b[sizeof T2];} x,y;
new (x.b) T2();  // 1
y = x;   // 2
T2 t;
memcpy(&t, y.b, sizeof T2);  // 3
t;   // 4
y.a; // 5

We have said that (2) is valid, obviously (3) in isolation is valid as well,
but it influences the validity of (4).  (5) is invalid as it's not the
active member of the union y (which is instead b).

(4) is valid if y.b contained a T2, which is only the case if (2) transferred
the dynamic type from x.b _and_ (1) was valid to start with and dynamically
typed x.b to be of type T2.

So, it all boils down to if (1) is valid and types x.b to T2, even though it
has a different declared type.  For C we say it's not, because char[] is
asymmetric: you can access all types via a char*, but you can't change the
dynamic type of a declared char array to contain arbitrary other things (well,
the ME memory model does cater for this and makes it valid, even though it's
invalid in C).

I guess you're arguing that (1) is valid in C++ and that then due to 3.9/3
and 12.8/29 also (2) and (4) are.  I guess it can be defined to be so, but
I wonder what the type of 'x' is after (1)?  It can't be T2, because clearly
x.b is valid even if T2 doesn't contain a member 'b'.  So it must stay a union,
but in order to transfer the type T2 in (2) it must also contain T2, so is it
the type 'union {T1 a; char b[sizeof T2]; T2 ;}' then (conceptually)?
Messy :)

[Bug middle-end/80208] DJGPP max object file alignment regression

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
The patch submission was 
.  The rationale 
there stands, both that as a standard requirement this must be an error or 
a pedwarn not a plain warning, and that the alternative to an error would 
be generating wrong code (code that does not achieve the alignment 
required by the user's program), which is not appropriate.  (There's no 
way of declaring "alignment preferred but not required", which would be a 
case where no error is needed.)

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[matz at gcc dot gnu.org]

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

--- Comment #67 from Michael Matz  ---
(In reply to Jason Merrill from comment #66)
> The operator semantics described in clause 5 [expr] apply to the built-in
> operators, not any overloaded operators.  Assignment of classes is always
> done by way of an assignment operator function, even if it happens to be
> trivial and therefore open-coded as a block copy, so the above doesn't apply
> to classes.

I think that's at least slippery.  If none of 5.18 would apply to class types
at all there would be no need for 5.18/3 (if non-class type) 5.18/4 (if
class-type) 5.18/5 (class objects are special), or 5.18/9.2 (braced-inits for
class objects).  So if /2 would have been conditional on "non-class type" as
well, like /3, it wouldn't matter, but so ...

(This is of course only a side-track, I used clause 5 merely because like you
I have difficulties to find a real definition of what constitutes an access
to the value of an object :) )

[Bug target/80103] ICE in output_1144, at config/rs6000/vsx.md:2298

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon Mar 27 17:04:07 2017
New Revision: 246505

URL: https://gcc.gnu.org/viewcvs?rev=246505&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2017-03-27  Kelvin Nilsen  

PR target/80103
* gcc.target/powerpc/pr80103-1.c: New test.

gcc/ChangeLog:

2017-03-27  Kelvin Nilsen  

PR target/80103
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Edit and
add comments.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
special handling for target option conflicts between dform
options (-mpower9-dform, -mpower9-dform-vector,
-mpower9-dform-scalar) and -mno-direct-move.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80103-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/54063] [5/6/7 regression] on powerpc64 gcc 4.9/5/6/7 generates larger code for global variable accesses than gcc 4.7

[law at redhat dot com]

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

--- Comment #16 from Jeffrey A. Law  ---
That's why I changed the target milestone to gcc-8 :-)

[Bug target/54063] [5/6/7 regression] on powerpc64 gcc 4.9/5/6/7 generates larger code for global variable accesses than gcc 4.7

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #15 from Segher Boessenkool  ---
Well, it would be nice to generate better code for this case again,
there is no reason to resolve this as WONTFIX, there are various ways
this could be done.  But it's not going to happen for GCC 7, sure.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #66 from Jason Merrill  ---
(In reply to Michael Matz from comment #64)
> I would find it extremely surprising if in
> 
>   a = b;
> 
> the RHS doesn't constitute an access to the value of object 'b' (even
> depending on the type of b).  Are you really saying this Jason? (just trying
> to make extra sure)

Well, there's a kind of access involved in forming a reference to each of the
members of b.  I'm having trouble finding text pertaining to this; the closest
I'm coming up with is in 12.7 [class.cdtor]:

To form a pointer to (or access the value of) a direct non-static member of an
object obj, the construction of obj shall have started and its destruction
shall not have completed, otherwise the computation of the pointer value (or
accessing
the member value) results in undefined behavior.

> (e.g. 5.17/2 is saying about the assignment operator, before any
> differentiation between class and non-class types:
>   "In simple assignment (=), the value of the expression replaces that of the
>object referred to by the left operand."
> How could it talk about the value of the expression if the RHS doesn't
> constitute an access to the value of that expression?  While /4 specifies that
> the actual assignment is carried out by the copy/move assignment operator
> and hence via object representation for unions when implicit (12.8/29), we
> cannot simply ignore the above sentence, can we?)

The operator semantics described in clause 5 [expr] apply to the built-in
operators, not any overloaded operators.  Assignment of classes is always done
by way of an assignment operator function, even if it happens to be trivial and
therefore open-coded as a block copy, so the above doesn't apply to classes.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[mikestump at comcast dot net]

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

Mike Stump  changed:

   What|Removed |Added

 CC||mikestump at comcast dot net

--- Comment #2 from Mike Stump  ---
Look forward to incorporating the changes made by the script.

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

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
According to my analysis, this is mostly caused by different inlining decisions
with regards to inlining new_Random_seed into MonteCarlo_integrate.  Inlining
happens at profile-generate time, but does not happen at profile-use time. 
This appears to throw off edge probabilities, and also prevents the compiler
from seeing that R->haveRange accessed in Random_nextDouble (which is inlined)
is always 0.

Declaring new_Random_seed (which is called once) as 'inline
__attribute__((always_inline))' makes code generation sane again.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

--- Comment #65 from Jonathan Wakely  ---
(In reply to Michael Matz from comment #64)
> I would find it extremely surprising if in
> 
>   a = b;
> 
> the RHS doesn't constitute an access to the value of object 'b' (even
> depending on the type of b).  Are you really saying this Jason? (just trying
> to make extra
> sure)

It accesses b, but it doesn't access the object stored in b's char[N] member
via placement new.

[Bug inline-asm/80225] New: ICE when using =cc output operand incorrectly

[jwjagersma at gmail dot com]

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

Bug ID: 80225
   Summary: ICE when using =cc output operand incorrectly
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

Invalid code, but the error message is less than helpful. The following
triggers an ICE:

int main()
{
bool z;
int ar;
asm("lar %0, %1;" : "=@ccz"(z), "=r"(ar) : "rm"(0x1234));
if (!z) return -1;
return ar;
}

$ g++ -masm=intel asm_flags.cpp
asm_flags.cpp: In function 'int main()':
asm_flags.cpp:8:1: internal compiler error: in print_reg, at
config/i386/i386.c:16601
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Version info:
$ g++ -v
Using built-in specs.
COLLECT_GCC=D:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 6.3.0 (Rev2, Built by MSYS2 project)

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #64 from Michael Matz  ---
I would find it extremely surprising if in

  a = b;

the RHS doesn't constitute an access to the value of object 'b' (even depending
on the type of b).  Are you really saying this Jason? (just trying to make
extra
sure)

(e.g. 5.17/2 is saying about the assignment operator, before any
differentiation
between class and non-class types:
  "In simple assignment (=), the value of the expression replaces that of the
   object referred to by the left operand."
How could it talk about the value of the expression if the RHS doesn't
constitute an access to the value of that expression?  While /4 specifies that
the actual assignment is carried out by the copy/move assignment operator and
hence via object representation for unions when implicit (12.8/29), we cannot
simply ignore the above sentence, can we?)

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |7.0

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 7.

[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow

[acsawdey at gcc dot gnu.org]

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

--- Comment #6 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Mon Mar 27 15:40:20 2017
New Revision: 246504

URL: https://gcc.gnu.org/viewcvs?rev=246504&root=gcc&view=rev
Log:
2017-03-27  Aaron Sawdey  

Backport from trunk
PR target/79449
PR target/79170

* gcc.dg/strncmp-2.c: New.  Test strncmp and memcmp builtin expansion
for reading beyond a 4k boundary.
* config/rs6000/rs6000.c (expand_block_compare): Make sure runtime
boundary crossing check and subsequent code generation agree.
* gcc.dg/memcmp-1.c: Improved to catch failures seen in PR 79170.
* config/rs6000/altivec.md (*setb_internal): Rename to setb_signed.
(setb_unsigned) New pattern for setb with CCUNS.
* config/rs6000/rs6000.c (expand_block_compare): Use a different
subfc./subfe sequence to avoid overflow problems.  Generate a
shorter sequence with cmpld/setb for power9.
* config/rs6000/rs6000.md (subf3_carry_dot2): Add a new pattern
for generating subfc. instruction.
(cmpstrsi): Add TARGET_POPCNTD predicate as the generate sequence
now uses this instruction.
* config/rs6000/rs6000-protos.h (expand_strn_compare): Add arg.
* config/rs6000/rs6000.c (expand_strn_compare): Add ability to expand
strcmp. Fix bug where comparison didn't stop with zero byte. Fix
case where N arg is SIZE_MAX.
* config/rs6000/rs6000.md (cmpstrnsi): Args to expand_strn_compare.
(cmpstrsi): Add pattern.
* gcc.dg/memcmp-1.c: New.
* gcc.dg/strncmp-1.c: New.
* config/rs6000/rs6000-protos.h (expand_strn_compare): Declare.
* config/rs6000/rs6000.md (UNSPEC_CMPB): New unspec.
(cmpb3): pattern for generating cmpb.
(cmpstrnsi): pattern to expand strncmp ().
* config/rs6000/rs6000.opt (mstring-compare-inline-limit): Add a new
target option for controlling how much code inline expansion of
strncmp() will be allowed to generate.
* config/rs6000/rs6000.c (expand_strncmp_align_check): generate code
for runtime page crossing check of strncmp () args.
(expand_strn_compare): Function to do builtin expansion of strncmp ().
* config/i386/i386.md (cmpstrnsi): New test to bail out if neither
string input is a string constant.
* builtins.c (expand_builtin_strncmp): Attempt expansion of strncmp
via cmpstrnsi even if neither string is constant.



Modified:
branches/ibm/gcc-6-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-6-branch/gcc/builtins.c
branches/ibm/gcc-6-branch/gcc/config/i386/i386.md
branches/ibm/gcc-6-branch/gcc/config/rs6000/altivec.md
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.opt

[Bug target/79449] ppc builtin expansion of strncmp can cross page (4k) boundary where it should not

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Mon Mar 27 15:40:20 2017
New Revision: 246504

URL: https://gcc.gnu.org/viewcvs?rev=246504&root=gcc&view=rev
Log:
2017-03-27  Aaron Sawdey  

Backport from trunk
PR target/79449
PR target/79170

* gcc.dg/strncmp-2.c: New.  Test strncmp and memcmp builtin expansion
for reading beyond a 4k boundary.
* config/rs6000/rs6000.c (expand_block_compare): Make sure runtime
boundary crossing check and subsequent code generation agree.
* gcc.dg/memcmp-1.c: Improved to catch failures seen in PR 79170.
* config/rs6000/altivec.md (*setb_internal): Rename to setb_signed.
(setb_unsigned) New pattern for setb with CCUNS.
* config/rs6000/rs6000.c (expand_block_compare): Use a different
subfc./subfe sequence to avoid overflow problems.  Generate a
shorter sequence with cmpld/setb for power9.
* config/rs6000/rs6000.md (subf3_carry_dot2): Add a new pattern
for generating subfc. instruction.
(cmpstrsi): Add TARGET_POPCNTD predicate as the generate sequence
now uses this instruction.
* config/rs6000/rs6000-protos.h (expand_strn_compare): Add arg.
* config/rs6000/rs6000.c (expand_strn_compare): Add ability to expand
strcmp. Fix bug where comparison didn't stop with zero byte. Fix
case where N arg is SIZE_MAX.
* config/rs6000/rs6000.md (cmpstrnsi): Args to expand_strn_compare.
(cmpstrsi): Add pattern.
* gcc.dg/memcmp-1.c: New.
* gcc.dg/strncmp-1.c: New.
* config/rs6000/rs6000-protos.h (expand_strn_compare): Declare.
* config/rs6000/rs6000.md (UNSPEC_CMPB): New unspec.
(cmpb3): pattern for generating cmpb.
(cmpstrnsi): pattern to expand strncmp ().
* config/rs6000/rs6000.opt (mstring-compare-inline-limit): Add a new
target option for controlling how much code inline expansion of
strncmp() will be allowed to generate.
* config/rs6000/rs6000.c (expand_strncmp_align_check): generate code
for runtime page crossing check of strncmp () args.
(expand_strn_compare): Function to do builtin expansion of strncmp ().
* config/i386/i386.md (cmpstrnsi): New test to bail out if neither
string input is a string constant.
* builtins.c (expand_builtin_strncmp): Attempt expansion of strncmp
via cmpstrnsi even if neither string is constant.



Modified:
branches/ibm/gcc-6-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-6-branch/gcc/builtins.c
branches/ibm/gcc-6-branch/gcc/config/i386/i386.md
branches/ibm/gcc-6-branch/gcc/config/rs6000/altivec.md
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.opt

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #63 from Jason Merrill  ---
(In reply to rguent...@suse.de from comment #54)
> > > > --- Comment #51 from Bernd Edlinger  
> > > > ---
> > > > Doesn't 3.10/10 explicitly say that it is undefined to use a union to
> > > > to move an object representation that is not a member of the union?

> But still the other clause says the storage representation is transfered
> and so you could read into that that no "access" happens and thus
> 3.10/10 doesn't apply.

Right, union copy copies the bytes of the object representation, i.e. memcpy.

(In reply to Richard Biener from comment #50)
> Note that what changed with GCC 7 is only that unions with char members
> no longer behave as alias-set zero but 12.8/16 talks about all unions,
> not just unions with char members.
> 
> Now I read comment#14 as that _only_ char[] members (of structs or unions)
> may ever "contain" different dynamic types.  Any pointer to a part of
> the standard that singles out char[] that way?

char is special that way because it can be used to access the stored value of
an object of any type (3.10/10.8).

Now that C++17 introduces std::byte for this sort of thing, I hope to
transition away from the permissive aliasing behavior of char.

[Bug tree-optimization/80213] [7 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug tree-optimization/80216] [7 Regression] Memory hog w/ -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r246187.

[Bug testsuite/80209] libgo test failure, dir gotest$$ not found

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |WORKSFORME

--- Comment #1 from Ian Lance Taylor  ---
Well, as you can see the code is doing

mkdir $DIR
cd $DIR

You didn't report any error message from mkdir, so presumably it succeeded. 
The script will be running in the TARGET/libgo directory in the build
directory, so the directory should be writable, the mkdir should succeed, and
of course the cd should succeed.  I don't know why the directory was removed
immediately after it was created, but I don't see any sign of an underlying
problem in the testsuite.

This is the first I have heard of this problem.

I'll close this as unreproducible, but please reopen if you disagree.

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
Author: vries
Date: Mon Mar 27 15:02:21 2017
New Revision: 246503

URL: https://gcc.gnu.org/viewcvs?rev=246503&root=gcc&view=rev
Log:
Backport "Require effective target global_constructor for two testcases"

2017-03-27  Tom de Vries  

backport from trunk:
2017-03-24  Tom de Vries  

PR testsuite/80092
* gcc.dg/tls/emutls-2.c:  Add dg-require-effective-target
global_constructor.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tls/emutls-2.c

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530
Bug 65530 depends on bug 80068, which changed state.

Bug 80068 Summary: [Intel MPX] "internal compiler error" on 483.xalancbmk in 
SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80068

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/80068] [Intel MPX] "internal compiler error" on 483.xalancbmk in SPEC CPU 2006

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Liška  ---
Good, thus closing as works for me.

[Bug target/80068] [Intel MPX] "internal compiler error" on 483.xalancbmk in SPEC CPU 2006

[dmitrii.kuvais...@tu-dresden.de]

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

--- Comment #2 from Dmitrii Kuvaiskii  ---
Thanks, Martin. This patch indeed solves it.

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

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #2)

> I think that if FDO says either the true or false edge is very likely
> then not if-converting the loop is best?  Or is a well-predicted
> conditional move as good as a well-predicted if?  10% missed branches
> would be more than

Please note that when if-conversion succeeded through noce_try_addcc, we don't
care about prediction anymore. The conversion converts:

ucomisd %xmm5, %xmm4
jb  .L17
.L16:
addl$1, %ebp
.L17:

to:

ucomisd %xmm0, %xmm3# 195   *cmpiudf/2  [length = 4]
sbbl$-1, %ebx   # 196   subsi3_carry/1  [length = 3]

IMO, this conversion should always be performed, as it is always a win.

[Bug gcov-profile/80224] New: gcov -i crashes with two arguments

[bernd.edlinger at hotmail dot de]

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

Bug ID: 80224
   Summary: gcov -i crashes with two arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

gcov -i test1.gcda test2.gcda
=> segfault.
Arguments must be given one by one,
documentation is unclear what to expect here.

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Not so easy though as profiling happens after inlining.

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug gcov-profile/80223] New: RFE: Exclude functions from profile instrumentation

[mpolacek at gcc dot gnu.org]

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

Bug ID: 80223
   Summary: RFE: Exclude functions from profile instrumentation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Similarly to no_instrument_function for -finstrument-functions, some users wish
that there be a function attribute to allow users to exclude a function from
being instrumented with -fprofile-generate.

[Bug c++/69549] Named Address Spaces does not compile in C++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-27
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Thiago Macieira from comment #0)
> It works in C:
> 
> $ cat test.c
> __seg_gs char * ptr;
> $ gcc -c test.c && echo Success
> Success

It's documenbted as being a feature in GNU C, and it doesn't say it's also
supported for C++.

> But not in C++:
> 
> $ gcc -xc++ -c test.c
> test.c:1:1: error: ‘__seg_gs’ does not name a type
> 
> Even though it's advertised as supported:
> 
> $ gcc -xc++ -dM -E /dev/null | grep SEG_GS   
> #define __SEG_GS 1

That seems persuasive. Either the macro shouldn't be defined or it should be
supported.

[Bug tree-optimization/80170] SLP vectorization creates aligned access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1

--- Comment #3 from Richard Biener  ---
Fixed on trunk (sofar).

[Bug ipa/79776] [7 Regression] ICE on valid code in insert_vi_for_tree, at tree-ssa-structalias.c:2807

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #62 from Bernd Edlinger  ---
(In reply to Jason Merrill from comment #44)
> Created attachment 41048 [details]
> trial patch
> 
> Does this fix the issue?  I don't have an ARM setup handy for testing.

Yes. I just tried, it and the crash is gone.

However if 3.10/10 does not apply here, then it would be
good to remove the special handling of the char type,
and just look for a union and/or maybe a may_alias
attribute.

[Bug tree-optimization/80218] [6/7 Regression] tree-call-cdce does not update block frequencies

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug tree-optimization/80216] [7 Regression] Memory hog w/ -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
*** Bug 80217 has been marked as a duplicate of this bug. ***

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

--- Comment #61 from Jonathan Wakely  ---
(In reply to rguent...@suse.de from comment #59)
> On Mon, 27 Mar 2017, redi at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> > 
> > --- Comment #58 from Jonathan Wakely  ---
> > But this seemingly equivalent code doesn't work:
> > 
> >   this->functor = static_cast(f.functor);
> 
> Is function_buffer may_alias?

Yes. Here's what I tested:


union function_buffer_members {
  void* p;
  void(*fp)();
};

union function_buffer {
  function_buffer_members members;
  char data[sizeof(function_buffer_members)];
} __attribute__((may_alias));

struct function_base {
  mutable function_buffer functor;
};

struct function : function_base {
  void func(const function& f) {
const function_buffer& aliasing_ref = f.functor;
this->functor = aliasing_ref;
  }
};

void blah(function& f1, function& f2)
{
  f1.func(f2);
}

The -fdump-tree-optimized dump is:


;; Function void blah(function&, function&) (_Z4blahR8functionS0_,
funcdef_no=1, decl_uid=2315, cgraph_uid=1, symbol_order=1)

void blah(function&, function&) (struct function & f1, struct function & f2)
{
   [100.00%]:
  # DEBUG this => f1_2(D)
  # DEBUG f => f2_3(D)
  # DEBUG D#1 => &MEM[(const struct function *)f2_3(D)].D.2297.functor
  # DEBUG aliasing_ref => D#1
  f1_2(D)->D.2297.functor = MEM[(const union function_buffer &
{ref-all})f2_3(D)];
  # DEBUG this => NULL
  # DEBUG f => NULL
  return;

}

This has {ref-all}.

If I use static_cast:

union function_buffer_members {
  void* p;
  void(*fp)();
};

union function_buffer {
  function_buffer_members members;
  char data[sizeof(function_buffer_members)];
} __attribute__((may_alias));

struct function_base {
  mutable function_buffer functor;
};

struct function : function_base {
  void func(const function& f) {
this->functor = static_cast(f.functor);
  }
};

void blah(function& f1, function& f2)
{
  f1.func(f2);
}

Then the dump doesn't have {ref-all}:


;; Function void blah(function&, function&) (_Z4blahR8functionS0_,
funcdef_no=1, decl_uid=2314, cgraph_uid=1, symbol_order=1)

void blah(function&, function&) (struct function & f1, struct function & f2)
{
   [100.00%]:
  # DEBUG this => f1_2(D)
  # DEBUG f => f2_3(D)
  f1_2(D)->D.2297.functor = MEM[(const struct function
*)f2_3(D)].D.2297.functor;
  # DEBUG this => NULL
  # DEBUG f => NULL
  return;

}

[Bug tree-optimization/80217] [7 Regression] ICE in set_ssa_name_value (deep recursion in derive_equivalencs_from_bit_ior)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |7.0

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

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

[Bug tree-optimization/80216] [7 Regression] Memory hog w/ -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-27
 CC||law at gcc dot gnu.org
  Component|middle-end  |tree-optimization
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
derive_equivalencs_from_bit_ior endlessly recurses.  Recent regression.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenth at gcc dot gnu.org]

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

--- Comment #60 from Richard Biener  ---
-> PR80222

[Bug middle-end/80222] may_alias folded away

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/80222] New: may_alias folded away

[rguenth at gcc dot gnu.org]

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

Bug ID: 80222
   Summary: may_alias folded away
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

struct C { int i; }__attribute__((may_alias)) ;

C a, b;

void foo()
{
  a = static_cast  (b);
}

is folded away via gimplification / gimple_fold_indirect_ref.

[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times

[john.salmon at deshaw dot com]

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

--- Comment #3 from John Salmon  ---
It's easy to overthink this.  0.0 is perfectly acceptable, as is any other
_RealType in the range [0, 1.).  But since rounding was, presumably, to-nearest
or up, it's slightly disconcerting that 0.0 is neither near nor up from the
"exact" value.

How about:


  if (__builtin_expect(__ret >= _RealType(1), 0))
{
#if _GLIBCXX_USE_C99_MATH_TR1
  __ret = std::nextafter(_RealType(1), _RealType(0));
#else
  __ret = _RealType(1) - std::numeric_limits<_RealType>::epsilon()/2.;
#endif
}

I.e., if there's no nextafter, then use numeric_limits::epsilon() to find the
value just below 1.0.

John Salmon

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

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

--- Comment #59 from rguenther at suse dot de  ---
On Mon, 27 Mar 2017, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> 
> --- Comment #58 from Jonathan Wakely  ---
> But this seemingly equivalent code doesn't work:
> 
>   this->functor = static_cast(f.functor);

Is function_buffer may_alias?  Then it should work unless the
FE messes up via folding.

struct C { int i; }__attribute__((may_alias)) ;

C a, b;

void foo()
{
  a = static_cast  (b);
}

in .original (correct):

<;

in .gimple (wrong-code):

void foo() ()
{
  a = b;
}

caused by gimple_fold_indirect_ref_rhs doing

tree
gimple_fold_indirect_ref (tree t)
{
  tree ptype = TREE_TYPE (t), type = TREE_TYPE (ptype);
  tree sub = t;
  tree subtype;

  STRIP_NOPS (sub);
  subtype = TREE_TYPE (sub);
  if (!POINTER_TYPE_P (subtype))
return NULL_TREE;

  if (TREE_CODE (sub) == ADDR_EXPR)
{
  tree op = TREE_OPERAND (sub, 0);
  tree optype = TREE_TYPE (op);
  /* *&p => p */
  if (useless_type_conversion_p (type, optype))
return op;

some of the transforms properly preserve ptype semantics but most don't

[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #19)
> (In reply to Gerald Pfeifer from comment #4)
> > Historically, on some systems one had to define _POSIX_C_SOURCE to get at
> > fileno(), which has been used by code generated by flex() and probably
> > others.
> 
> Yes, but you don't have to define it to 1. If you define _POSIX_C_SOURCE to
> 199506L or set _XOPEN_SOURCE to 500 then I think the functions we use are
> available, as well as fileno.

Correction: _POSIX_C_SOURCE=200112L or _XOPEN_SOURCE=600 should declare them.

[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Also, I assume this is only a problem for -std=c++98 or -std=gnu++98, because
if the system headers don't declare those functions for C++11 and later
dialects then that's a bug in those system headers.

[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0

--- Comment #19 from Jonathan Wakely  ---
(In reply to Gerald Pfeifer from comment #4)
> Historically, on some systems one had to define _POSIX_C_SOURCE to get at
> fileno(), which has been used by code generated by flex() and probably
> others.

Yes, but you don't have to define it to 1. If you define _POSIX_C_SOURCE to
199506L or set _XOPEN_SOURCE to 500 then I think the functions we use are
available, as well as fileno.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 41057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41057&action=edit
tentative patch

This script tries to rewrite all tests, but that's not entirely supported yet.

Known error causes:
- PR80219 relative line numbers only working if gcc_{error,warning}_prefix
  defined
- PR80220 relative line numbers don't work when put between braces

[Bug testsuite/80221] New: Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

Bug ID: 80221
   Summary: Contrib script to rewrite testcase from absolute to
relative line numbers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

It would be good to have a script that rewrites tests to use relative instead
of absolute line numbers in the dg-{warning,error,message,bogus} directives.

[Bug tree-optimization/80181] [7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:505

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 27 12:52:13 2017
New Revision: 246500

URL: https://gcc.gnu.org/viewcvs?rev=246500&root=gcc&view=rev
Log:
2017-03-27  Richard Biener  

PR tree-optimization/80181
* tree-ssa-ccp.c (likely_value): UNDEFINED ^ X is UNDEFINED.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80181.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/80181] [7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:505

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/80198] [6/7 Regression] does not vectorize generic inplace integer operation

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So this is another case where the conditional propagation happens so that

 if (a == b)
   {
  ... = deref a;
  ... = deref b;
   }

turns into

 if (a == b)
   {
  ... = deref b;
  ... = deref a;
   }

which is of course not sensible.  Having both a = b and b = a recorded
as copies breaks the lattices canonical value.

The original bug would need to have been fixed by recording equivalency
sets or by doing more expensive lookups and knowing a backmapping,
SSA value -> SSA name list.

[Bug tree-optimization/80198] [6/7 Regression] does not vectorize generic inplace integer operation

[jtaylor.debian at googlemail dot com]

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

--- Comment #5 from Julian Taylor  ---
I have been searching for a workaround as this has pretty bad performance
impact in my usecase. I found that putting this into the inplace conditional
#pragma GCC ivdep
allows it to be vectorized again with gcc 6 and 7. It should be fine as inplace
is no dependence in my case.

I'll adapt my code to use this, but it would still be great when the regression
could get fixed.

[Bug testsuite/80220] relative line numbers don't work when put between braces

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 41056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41056&action=edit
tentative patch