[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  ---
I forgot to mention that this is likely a regression since gcc-4.7-era, but I
haven't proved that elsewhere than on the original target (not x86_64-linux /
sse2).

[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson  ---
Created attachment 43836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43836=edit
case 4

[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson  ---
Created attachment 43835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43835=edit
case 3

[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  ---
Created attachment 43834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43834=edit
case 2

[Bug tree-optimization/85186] New: ifcvt can peel iterations affecting code form, and causing vectorization not to happen

[hp at gcc dot gnu.org]

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

Bug ID: 85186
   Summary: ifcvt can peel iterations affecting code form, and
causing vectorization not to happen
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43833=edit
original non-vectorizing case: 1

In a build for x86_64-linux (likely also other targets; this originates
elsewhere) at r258635, drop in attached four test-cases into the dg/vect
subdir.

Observe, when running vect.exp:
Running x/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/prX-1.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/prX-1.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1

I.e. prX-1.c does not vectorize, while -2..4 does.

Partial analysis: On inspection using gdb and dumps, this appears to be because
the initialization appears to affect ifcvt (just as a catalyst) causing it to
sort-of peel the first iteration of the to-be-vectorized loop, or something to
that effect, anyway changing the form of the code such that it is not be
recognizable for the loop vectorizer pass that comes next.

1: original (derived from some other gcc test long ago)
2: candidate loop with non-conditional contents: vectorizes.
3: arrays in candidate loop are moved global (i.e. aren't initialized right
before the loop): vectorizes.
4: asm("" : : : "memory") inserted after initialization: vectorizes.

All-in-all this PR isn't important (with the test-cases being artificial), but
when revisiting if-conversion and/or investigates ifcvt vs. loop-vectorization
issues, this PR may provide simplified test-cases of an underlying bug.

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

[zev+gccbug at bewilderbeest dot net]

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

--- Comment #2 from Zev Weiss  ---
I was wondering if I might be unwittingly violating some subtle rule like that;
are the details of this documented?  I don't see anything  obvious in section
6.45.2.5 ("Input Operands") of the GCC manual, but perhaps I'm missing
something or not looking in the right place.

Also, would the undefinedness you describe extend to the remaining 32 bits
above that as well?  (I'm a bit unclear on why/how 32-bit values would enter
the picture if the underlying variable is 16 bits and the hardware register is
64 -- is integer promotion applied to inline asm operands? If so, the selection
of %ax on x86-64 seems odd.)

[Bug c++/84943] [8 Regression] internal compiler error: in build_call_a, at cp/call.c:374

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Fixed

[Bug c++/84943] [8 Regression] internal compiler error: in build_call_a, at cp/call.c:374

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Apr  4 03:40:29 2018
New Revision: 259067

URL: https://gcc.gnu.org/viewcvs?rev=259067=gcc=rev
Log:
[PR c++/84943] mark function as used when taking its address

fn[0]() ICEd because we would fold the INDIRECT_REF used for the
array indexing while building the address for the call, after not
finding the decl hiding there at first.  But the decl would be exposed
by the folding, and then lower layers would complain we had the decl,
after all, but it wasn't one of the artificial or special functions
that could be called without being marked as used.

This patch arranges for a FUNCTION_DECL to be marked as used when
taking its address, just like we already did when taking the address
of a static function to call it as a member function (i.e. using the
obj.fn() notation).  However, we shouldn't mark functions as used when
just performing overload resolution, lest we might instantiate
templates we shouldn't, as in g++.dg/overload/template1.C, so we
adjust mark_used to return early when testing conversions.


for  gcc/cp/ChangeLog

PR c++/84943
* typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as
used.
* decl2.c (mark_used): Return without effects if tf_conv.

for  gcc/testsuite/ChangeLog

PR c++/84943
* g++.dg/pr84943.C: New.
* g++.dg/pr84943-2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/pr84943-2.C
trunk/gcc/testsuite/g++.dg/pr84943.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/85165] gcc (and g++) not complaining about few unknown file extensions like *.CC, *.Cc, *.cC

[kiran0802 at gmail dot com]

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

Kiran Alladi  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Kiran Alladi  ---
@Andrew: 
Yes, your observation is right. This difference in behavior is due to windows
and unix case sensitive nature. Hence resolving this issue.
Thanks for your inputs.

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think the upper 16bits are considered as undefined when using inline-asm like
this.

[Bug inline-asm/85185] New: Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

[zev+gccbug at bewilderbeest dot net]

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

Bug ID: 85185
   Summary: Wider-than-expected load for struct member used as
operand of inline-asm with memory clobber at -Og
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zev+gccbug at bewilderbeest dot net
  Target Milestone: ---

Created attachment 43832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43832=edit
Minimized reproducer

In the attached test case, compiling with -Og generates a wider memory access
than expected (4 bytes instead of 2, on the LP64 targets I'm dealing with) to
load sub.a on line 12.

--
$ nl -ba min.c
 1  struct sub {
 2short a, b;
 3  };
 4
 5  struct {
 6int i;
 7struct sub P;
 8  } S;
 9
10  static inline void inner(struct sub sub)
11  {
12asm("magic %0" :: "r" (sub.a) : "memory");
13  }
14
15  void outer(void)
16  {
17inner(S.P);
18  }
$ gcc -S -o - -Og min.c
.file   "min.c"
.text
.globl  outer
.type   outer, @function
outer:
.LFB1:
.cfi_startproc
movl4+S(%rip), %eax
#APP
# 12 "min.c" 1
magic %ax
# 0 "" 2
#NO_APP
ret
.cfi_endproc
.LFE1:
.size   outer, .-outer
.comm   S,8,8
.ident  "GCC: (GNU) 7.3.0"
.section.note.GNU-stack,"",@progbits
--

On x86-64 it ends up being relatively harmless because it uses a 16-bit
register (%ax) as the actual operand used in the instruction, but on targets
that only have full-width registers (riscv64 being the one at hand for me) this
results in the instruction receiving a very different operand than desired
(containing additional bytes from the neighboring struct member):

--
$ riscv64-unknown-elf-gcc -S -o - -Og min.c
.file   "min.c"
.option nopic
.text
.align  2
.globl  outer
.type   outer, @function
outer:
addisp,sp,-16
lui a5,%hi(S)
addia5,a5,%lo(S)
lw  a5,4(a5)
sw  a5,8(sp)
 #APP
# 17 "min.c" 1
magic a5
# 0 "" 2
 #NO_APP
addisp,sp,16
jr  ra
.size   outer, .-outer
.comm   S,8,8
.ident  "GCC: (GNU) 7.2.0"
--

This only occurs when compiling with -Og; -O0, -O1, -O2, and -O3 all generate
the expected two-byte load (movzwl instead of movl on x86-64, lh or lhu instead
of lw on riscv64).  I've also found via a bit of haphazard guess-based
experimentation that adding -ftree-sra to -Og produces a two-byte load as well.

I've observed these same patterns (4-byte load at -Og, 2-byte load at all other
-O levels or with -ftree-sra) on a number of different GCCs:

 - x86-64: 4.8.2 (Red Hat), 5.1.0 (source), 5.4.0 (Ubuntu), 7.2.0 (source),
7.3.0 (Void)
 - riscv64: 6.1.0 and 7.2.0 (both from source; I realize the former predates
official upstream riscv support but is perhaps illustrative nonetheless)

I've filed this on release 7.2.0 because that's the version where this is
actually biting me -- and as mentioned above, is only actually causing problems
on riscv, but the very similar code generation on x86 makes me suspect the
underlying problem is target-independent (and has apparently existed for a
while).

[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
In general, sizing buffers for the minimum/maximum value of each directive's
argument and choosing the appropriate length modifiers (e.g., %hhi for char or
%hi for short) avoids these problems.

The thinking behind the current behavior at level 1 is that an expression in
some known range is a sign that the programmer may have made an effort to
constrain the value, while an expression for which we have no range information
may have been constrained and we just don't see it.  When the known range
doesn't constrain the value sufficiently, the warning triggers.  An unknown
range doesn't.  The "fix" for a warning in the former case should in most cases
be to simply constrain the variable either by using an appropriate length
modifier in the directive or just before the call (e.g., via some form of an
assertion or an equivalent of '((x < min || x > max) ? __builtin_unreachable ()
: (void)0).   This works quite well except when the buffer is just big enough
and when the warning exposes weaknesses in optimizations and/or unforeseen
interactions with other transformations (usually jump-threading or the
sanitizers).  Rather than weakening the warnings our approach to these problems
has been to improve the optimizers.  I'm hoping this case can be dealt with the
same way but I'm not familiar enough with the EVRP machinery yet to tell if
that will be possible.

As for -Wformat-overflow=2, an expression in an unknown range is treated as if
it had the maximum range of its type.

(I suppose we should also have level 3 where ranges are ignored and buffers are
expected to be sized only according to argument type.  I realize it's not what
you're looking for but it would make it straightforward to write safe,
warning-free code regardless of optimizations.)

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[proski at gnu dot org]

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

--- Comment #7 from Pavel Roskin  ---
I confirm that the issue has been fixed in the project I'm working on. Thank
you!

[Bug c/85182] _Static_assert is less than useful in a static inline

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
The GCC feature that comes close to what you're looking for from _Static_assert
are attributes error and warning.  The difference is that the attributes are
considered very late during translation while _Static_assert is evaluated very
early, during parsing.

Here's an example of how to set it up:

$ cat static-assert.[hc] && gcc -O2 -S -Wall static-assert.c
#include "static-assert.h"

void f (void) { bar (1); }
void g (void) { bar (0); }
void h (int i) { bar (i); }

void __attribute__ ((error ("my static assertion failed")))
my_static_assert_fail (void);

void __attribute__ ((warning ("my static assertion unable to evaluate
expression")))
my_static_assert_nonconst (void);

static void inline __attribute__ ((always_inline))
my_static_assert (int expr)
{
  if (!__builtin_constant_p (expr))
{
  my_static_assert_nonconst ();
  return;
}

  if (expr)
return;

  my_static_assert_fail ();
}

static inline void bar (int i)
{
  my_static_assert (i);
}
In file included from static-assert.c:1:
In function ‘my_static_assert’,
inlined from ‘g’ at static-assert.h:24:3:
static-assert.h:19:3: error: call to ‘my_static_assert_fail’ declared with
attribute error: my static assertion failed
   my_static_assert_fail ();
   ^~~~
In function ‘my_static_assert’,
inlined from ‘h’ at static-assert.h:24:3:
static-assert.h:12:7: warning: call to ‘my_static_assert_nonconst’ declared
with attribute warning: my static assertion unable to evaluate expression
   my_static_assert_nonconst ();
   ^~~~

[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed - thanks!

[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr  3 23:03:07 2018
New Revision: 259059

URL: https://gcc.gnu.org/viewcvs?rev=259059=gcc=rev
Log:
PR libstdc++/85183 fix std::variant move-assignment

PR libstdc++/85183
* include/std/variant (_Move_assign_base::operator=): Fix incorrect
value categories.
* testsuite/20_util/variant/85183.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/variant/85183.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||7.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.0
  Known to fail||8.0.1

[Bug libstdc++/83625] std::experimental::filesystem::remove lstat()'s before remove() instead of checking errno

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #1 from Jonathan Wakely  ---
(In reply to Andrew Gunnerson from comment #0)
> This could cause the function to report an error if the path is deleted
> between the stat() and remove() instead of returning false. Would it make
> sense to always attempt remove() and return false if errno == ENOENT instead?

This was done as part of PR 83626

[Bug libstdc++/85184] New: Remove __glibcxx_assert uses from std::variant

[redi at gcc dot gnu.org]

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

Bug ID: 85184
   Summary: Remove __glibcxx_assert uses from std::variant
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

These assertions are being used to verify that the implementation works
correctly, i.e. to catch logic errors. Users should not be paying for those
checks at runtime.

The assertions should be removed before we declare our C++17 support
non-experimental.

[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets

[alexandre.nunes at gmail dot com]

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

Alexandre Pereira Nunes  changed:

   What|Removed |Added

 CC||alexandre.nunes at gmail dot 
com

--- Comment #1 from Alexandre Pereira Nunes  
---
I can confirm that on gcc 7.3.0 / i686-mingw64.

[Bug libstdc++/85183] New: [8 Regression] std::variant move assignment mishandles move-only types

[rs2740 at gmail dot com]

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

Bug ID: 85183
   Summary: [8 Regression] std::variant move assignment mishandles
move-only types
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:
#include 

struct moveonly {
moveonly() noexcept { }
moveonly(moveonly&&) noexcept { }
moveonly& operator=(moveonly&&) noexcept { return *this; } 
~moveonly() { }
};


void test() {
std::variant m1, m2;
m1 = std::move(m2);
}

Compiles with 7. Breaks with 8:

In file included from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.1/variant: In instantiation of 'void
std::__detail::__variant::__erased_assign(void*, void*) [with _Lhs = moveonly&;
_Rhs = const moveonly&]':
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:607:27:   required from
'std::__detail::__variant::_Move_assign_base<, _Types>&
std::__detail::__variant::_Move_assign_base<,
_Types>::operator=(std::__detail::__variant::_Move_assign_base<,
_Types>&&) [with bool  = false; _Types = {moveonly}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:648:12:   required from here
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:258:42: error: use of deleted
function 'constexpr moveonly& moveonly::operator=(const moveonly&)'
   __variant::__ref_cast<_Lhs>(__lhs) = __variant::__ref_cast<_Rhs>(__rhs);
   ~~~^~~~
prog.cc:3:8: note: 'constexpr moveonly& moveonly::operator=(const moveonly&)'
is implicitly declared as deleted because 'moveonly' declares a move
constructor or move assignment operator
 struct moveonly {
^~~~
In file included from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.1/variant: In instantiation of 'void
std::__detail::__variant::__erased_ctor(void*, void*) [with _Lhs = moveonly&;
_Rhs = const moveonly&]':
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:468:30:   required from
'std::__detail::__variant::_Copy_ctor_base<,
_Types>::_Copy_ctor_base(const
std::__detail::__variant::_Copy_ctor_base<, _Types>&) [with bool
 = false; _Types = {moveonly}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:509:7:   required from
'std::__detail::__variant::_Move_assign_base<, _Types>&
std::__detail::__variant::_Move_assign_base<,
_Types>::operator=(std::__detail::__variant::_Move_assign_base<,
_Types>&&) [with bool  = false; _Types = {moveonly}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:648:12:   required from here
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:246:7: error: use of deleted
function 'constexpr moveonly::moveonly(const moveonly&)'
   ::new (__lhs) _Type(__variant::__ref_cast<_Rhs>(__rhs));
   ^~~
prog.cc:3:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
 struct moveonly {


There are two bugs in the move assignment operator of _Move_assign_base primary
template, presumably caused by copy-paste:
* in the matching index case, it uses __erased_assign<_Types&, const _Types&>
when it should be using __erased_assign<_Types&, _Types&&>.
* in the mismatched index case, it copies __rhs to create __tmp
(`_Move_assign_base __tmp(__rhs);`) when it should have moved from it.

[Bug c/85182] _Static_assert is less than useful in a static inline

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
The call to the function is not needed to get the static assert to happen.

[Bug c/85182] _Static_assert is less than useful in a static inline

[ajax at redhat dot com]

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

Adam Jackson  changed:

   What|Removed |Added

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

--- Comment #3 from Adam Jackson  ---
(In reply to jos...@codesourcery.com from comment #1)
> This is how static assertions are defined in C11, not a bug in GCC: it's a 
> constraint violation if the constant expression compares equal to 0, 
> regardless of the context in which the declaration appears (thus, a 
> constraint violation in a function that is never called, for example).

You missed my point. The diagnostic points me to the site of the declaration of
the static inline, not of the call site. Let's make this more explicit:

---
desoxy:~/git/junkdrawer% cat -n static-assert.h
 1  static inline void bar(void)
 2  {
 3  const int y = 0;
 4  _Static_assert(y, "called bar()");
 5  }
desoxy:~/git/junkdrawer% cat -n static-assert.c
 1  #include "static-assert.h"
 2  void foo(void) { bar(); }
desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c
In file included from static-assert.c:1:
static-assert.h: In function ‘bar’:
static-assert.h:4:5: error: static assertion failed: "called bar()"
 _Static_assert(y, "called bar()");
 ^~
---

Don't tell me "in file A included from this spot in B, you hit a static
assert". Tell me "At this spot in A, this function defined in B hit a static
assert". Because otherwise, with a less trivial assertion, I am going to have
_no idea_ where the constraint was violated.

[Bug c/85182] _Static_assert is less than useful in a static inline

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Invalid as explained.  There is some GCC extensions to support what you want to
do.

[Bug tree-optimization/85156] [8 Regression] ICE with -O1 -g: gimplification failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/85167] [6/7 Regression] shrink-wrap.c:333:15: runtime error with UBSAN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression]
   |shrink-wrap.c:333:15:   |shrink-wrap.c:333:15:
   |runtime error with UBSAN|runtime error with UBSAN

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/85167] [6/7/8 Regression] shrink-wrap.c:333:15: runtime error with UBSAN

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  3 21:45:52 2018
New Revision: 259058

URL: https://gcc.gnu.org/viewcvs?rev=259058=gcc=rev
Log:
PR rtl-optimization/85167
* shrink-wrap.c (move_insn_for_shrink_wrap): Don't set bb_uses and
bb_defs if *split_p, instead preinitialize it to NULL.

* gcc.dg/pr85167.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr85167.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/shrink-wrap.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85156] [8 Regression] ICE with -O1 -g: gimplification failed

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  3 21:42:51 2018
New Revision: 259057

URL: https://gcc.gnu.org/viewcvs?rev=259057=gcc=rev
Log:
PR tree-optimization/85156
* builtins.c (fold_builtin_expect): Use save_expr on arg1 to avoid
evaluating the argument multiple times.

* c-c++-common/pr85156.c: New test.
* gcc.c-torture/execute/pr85156.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr85156.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr85156.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85182] _Static_assert is less than useful in a static inline

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
This is how static assertions are defined in C11, not a bug in GCC: it's a 
constraint violation if the constant expression compares equal to 0, 
regardless of the context in which the declaration appears (thus, a 
constraint violation in a function that is never called, for example).

[Bug c/85182] New: _Static_assert is less than useful in a static inline

[ajax at redhat dot com]

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

Bug ID: 85182
   Summary: _Static_assert is less than useful in a static inline
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajax at redhat dot com
  Target Milestone: ---

Consider:

---
desoxy:~/git/junkdrawer% cat -n static-assert.h
 1  static inline void bar(void)
 2  {
 3  _Static_assert(0, "called bar()");
 4  }
desoxy:~/git/junkdrawer% cat -n static-assert.c
 1  #include "static-assert.h"
 2  void foo(void) { bar(); }
desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c 
In file included from static-assert.c:1:
static-assert.h: In function ‘bar’:
static-assert.h:3:5: error: static assertion failed: "called bar()"
 _Static_assert(0, "called bar()");
 ^~
desoxy:~/git/junkdrawer% gcc --version | head -1
gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)
---

Note that the report locates the definition, not the call site. Effectively I'm
being punished for avoiding the preprocessor, which seems wrong:

---
desoxy:~/git/junkdrawer% cat -n static-assert.h
 1  #define bar() do { \
 2  _Static_assert(0, "called bar()"); \
 3  } while (0)
desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c
In file included from static-assert.c:1:
static-assert.c: In function ‘foo’:
static-assert.h:2:9: error: static assertion failed: "called bar()"
 _Static_assert(0, "called bar()"); \
 ^~
static-assert.c:2:18: note: in expansion of macro ‘bar’
 void foo(void) { bar(); }
  ^~~
---

[Bug target/85166] [nvptx, libgfortran] Libgomp fortran tests using stop in offloaded fns fail to compile

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Does this fix the problem?

Index: minimal.c
===
--- minimal.c   (Revision 259055)
+++ minimal.c   (Arbeitskopie)
@@ -187,3 +187,17 @@ sys_abort (void)

   abort();
 }
+
+/* A numeric STOP statement.  */
+
+extern _Noreturn void stop_numeric (int, bool);
+export_proto(stop_numeric);
+
+void
+stop_numeric (int code, bool quiet)
+{
+  if (!quiet)
+printf ("STOP %d\n", code);
+
+  exit (code);
+}

[Bug c++/85135] [7/8 Regression] ICE with invalid late-specified return type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/85166] [nvptx, libgfortran] Libgomp fortran tests using stop in offloaded fns fail to compile

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
The easiest solution would be to add the symbol to the minmal libgfortran.

Is there any reason why this would not work?

[Bug c++/85133] [7/8 Regression] [concepts] ICE with invalid concept used in variadic template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #6 from David Binderman  ---
I wonder if changing type of static array full_costs from int to long would
help solve the problem.

Adding vmakarov, who seems to be the author of most of this section
of code.

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #5 from David Binderman  ---
Still seems to be present in gcc trunk revision 259004.

[Bug c++/85141] [6/7/8 Regression] ICE with pointer arithmetic of static member function address

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/85148] [6/7/8 Regression] ICE with NSDMI and this pointer

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

Bug 85092 Summary: [8 Regression] ICE under -std=gnu++1z in build_over_call 
under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092

   What|Removed |Added

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

[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Apr  3 19:14:03 2018
New Revision: 259053

URL: https://gcc.gnu.org/viewcvs?rev=259053=gcc=rev
Log:
PR c++/85113 - ICE with constexpr and __builtin_constant_p.

* constexpr.c (cxx_eval_builtin_function_call): Only defer
__builtin_constant_p if ctx->quiet.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/builtin12.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Apr  3 19:13:42 2018
New Revision: 259052

URL: https://gcc.gnu.org/viewcvs?rev=259052=gcc=rev
Log:
PR c++/85092 - C++17 ICE with unused list constructor.

* call.c (conv_binds_ref_to_prvalue): Also count ck_identity
from a TARGET_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist99.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr  3 19:13:36 2018
New Revision: 259051

URL: https://gcc.gnu.org/viewcvs?rev=259051=gcc=rev
Log:
PR c++/85113 - ICE with constexpr and __builtin_constant_p.

* constexpr.c (cxx_eval_builtin_function_call): Only defer
__builtin_constant_p if ctx->quiet.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin12.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Martin Sebor from comment #2)

> So with the change above GCC is doing a better but imperfect job of
> determining the range.  Changing the variable to unsigned constrains the
> lower bound to zero and eliminates the warning even at -Os.

Ok, so this is actually the same thing I saw with seven other files in the
kernel (out of several hundred randconfig kernel builds on three
architectures). In each case, we now have a signed integer range that appears
to be constrained on one side after r257857, e.g. [-2147483647, 68] or [1,
2147483647] based on a partial range check, but the warning is still a false
positive in the end.

The one such warning we gained in the kernel that makes sense was this one (not
sent yet):

commit c18e88d296264d76f1a242ae95a43681cf198078
Author: Arnd Bergmann 
Date:   Tue Apr 3 09:45:35 2018 +0200

bluetooth: fix hci name overflow

gcc-8 warns that the index of the hci device could overflow the eight
character array:

net/bluetooth/hci_core.c: In function 'hci_register_dev':
net/bluetooth/hci_core.c:3093:26: error: '%d' directive writing between 1
and 10 bytes into a region of size 5 [-Werror=format-overflow=]
  sprintf(hdev->name, "hci%d", id);
  ^~
net/bluetooth/hci_core.c:3093:22: note: directive argument in the range [0,
2147483647]
  sprintf(hdev->name, "hci%d", id);
  ^~~
net/bluetooth/hci_core.c:3093:2: note: 'sprintf' output between 5 and 14
bytes into a destination of size 8
  sprintf(hdev->name, "hci%d", id);

This uses snprintf() to enforce a valid string, and limits the range of
the integer to 0... In practice this should not matter as we would
not be able connect more than  bluetooth hci's simultaneously.

Signed-off-by: Arnd Bergmann 

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 40d260f2bea5..9e2ad444d799 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3075,13 +3075,14 @@ int hci_register_dev(struct hci_dev *hdev)

/* Do not allow HCI_AMP devices to register at index 0,
 * so the index can be used as the AMP controller ID.
+* Ensure the name fits into eight characters id < 1.
 */
switch (hdev->dev_type) {
case HCI_PRIMARY:
-   id = ida_simple_get(_index_ida, 0, 0, GFP_KERNEL);
+   id = ida_simple_get(_index_ida, 0, 1, GFP_KERNEL);
break;
case HCI_AMP:
-   id = ida_simple_get(_index_ida, 1, 0, GFP_KERNEL);
+   id = ida_simple_get(_index_ida, 1, 1, GFP_KERNEL);
break;
default:
return -EINVAL;
@@ -3090,7 +3091,7 @@ int hci_register_dev(struct hci_dev *hdev)
if (id < 0)
return id;

-   sprintf(hdev->name, "hci%d", id);
+   snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
hdev->id = id;

BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);

The other new warnings are either the same kind as this one (the compiler
should be able to figure it out), or the sort where the compiler is technically
right about the string overflow based on the types, but we can easily prove
that the range is more limited like in the ida_simple_get() case with correct
limits (this is an extern function that returns an unused number within a
strict range).

Would it be sensible to only warn with -Wformat-overflow=1 on a signed integer
if the overflow happens with an actual known limit, but not if the limit is
euqal to the minimum/maximum representable numbers? The documentation for
-Wformat-overflow=2 isn't completely clear on what behavior was intended here
for the =1 and =2 case if the range is only bounded on one side.

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
... and it's only a substitution failure anyway, not an error.

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
*** Bug 85101 has been marked as a duplicate of this bug. ***

[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jason Merrill  ---
Yes, dup.

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

[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[munroesj at gcc dot gnu.org]

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

--- Comment #5 from Steven Munroe  ---
You need to look at the generated asm code. And see what the compiler is doing.

Basically it should be generating a vspltisw vr,si for vec_splat_s32.

But if the immediate signed int (si) is greater than 15, should failure with:

error: argument 1 must be a 5-bit signed literal

The vec_splats should work for any value as it will load a const vector from
storage.

Perhaps the compiler is generating bad code and not reporting it.

Or the compiler is too smart and converting the vec_splat_s32 to the more
general vec_splats under the covers.

Look at the source Paul!

[Bug c++/84768] [7 Regression] ICE with failed class template argument deduction because of invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |failed class template   |failed class template
   |argument deduction because  |argument deduction because
   |of invalid template |of invalid template
   |parameter   |parameter

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||6.4.0, 7.3.0, 8.0.1

--- Comment #5 from Jonathan Wakely  ---
GCC 5, Clang and EDG all compile it.

GCC 6 onwards fail with:

85118.C: In instantiation of 'main():: [with auto:1 =
{volatile char}]':
85118.C:114:51:   required by substitution of 'template
main()::::operator decltype (((const
main()::*)((const main()::*
const)0u))->operator()(static_cast(main::__lambda0::_FUN::)
...)) (*)(auto:1&& ...)() const [with auto:1 = {volatile char}]'
85118.C:79:56:   required by substitution of 'template _Result std::_Bind<_Functor, _Bound_args>::operator()(_Args&&)
volatile [with _Args = char; _Result = ]'
85118.C:121:12:   required from here
85118.C:116:23: error: no matching function for call to 'isOneOf(volatile
char)'
 return isOneOf(std::forward(params)...);
~~~^~~
85118.C:101:6: note: candidate: bool isOneOf(const T&) [with T = volatile char]

 bool isOneOf(const T& )
  ^~~
85118.C:101:6: note:   conversion of argument 1 would be ill-formed:
85118.C:116:23: error: invalid initialization of non-const reference of type
'const volatile char&' from an rvalue of type 'volatile char'
 return isOneOf(std::forward(params)...);
~~~^~~
85118.C:107:6: note: candidate: template bool isOneOf(const T&, const FirstType&, const Tail& ...)
 bool isOneOf(const T& t, const FirstType& firstValue, const Tail&... tail)
  ^~~
85118.C:107:6: note:   template argument deduction/substitution failed:
85118.C:116:23: note:   candidate expects at least 2 arguments, 1 provided
 return isOneOf(std::forward(params)...);
~~~^~~
85118.C:76:10: warning: '_Result std::_Bind<_Functor,
_Bound_args>::operator()(_Args&&) [with _Args = char; _Result = bool; _Functor
= const main()::; _Bound_args = char]' used but never
defined
  operator()(_Args&& __args);
  ^~~~


The error says "invalid initialization of non-const reference of type 'const
volatile char&' from an rvalue of type 'volatile char'" which is bogus, because
const volatile char& is not a non-const reference.

[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84768] [7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Apr  3 17:53:05 2018
New Revision: 259049

URL: https://gcc.gnu.org/viewcvs?rev=259049=gcc=rev
Log:
/cp
2018-04-03  Paolo Carlini  

PR c++/84768
* pt.c (rewrite_template_parm): If the first argument is
error_mark_node return it immediately.
(build_deduction_guide): Check the return value of the
latter for error_mark_node.
(do_class_deduction): Check the return value of the latter.

/testsuite
2018-04-03  Paolo Carlini  

PR c++/84768
* g++.dg/cpp1z/class-deduction52.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction52.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #43794|0   |1
is obsolete||

--- Comment #4 from Jonathan Wakely  ---
Created attachment 43831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43831=edit
reduced testcase

[Bug target/85181] New: Loading wrong source/dest registers for xviexpdp instruction with -O2 optimization

[carll at gcc dot gnu.org]

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

Bug ID: 85181
   Summary: Loading wrong source/dest registers for xviexpdp
instruction with -O2 optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carll at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43830=edit
test case for xviexpdp instruction

With -O2 optimization, we load the data into the wrong VR registers.  With -O0
we load and use the same VSR registers.  The results of the test case is wrong
with -O2 optimization but the correct expected result was obtained with -O0.

The compiler used is GCC 8 mainline Revision: 258857

The attached test code was extracted from the Valgrind test_isa_3_0.c. 

When the test code was compiled on 4/2/2018 on a Power 9 system with the
mainline GCC 8.0, Revision: 258857 with optimization -O0 I got the code:

gcc -g -O0 -o test_xviexpdp  test_xviexpdp.c
objdump -S -d test_xviexpdp > test_xviexpdp.dump

I get the following generated code.

15d4:   50 81 22 39 addir9,r2,-32432
15d8:   98 4e 00 7c lxvd2x  vs0,0,r9
15dc:   50 02 80 f1 xxswapd vs12,vs0
15e0:   00 00 00 60 nop 
15e4:   60 81 22 39 addir9,r2,-32416
15e8:   98 4e 00 7c lxvd2x  vs0,0,r9
15ec:   50 02 60 f1 xxswapd vs11,vs0
15f0:   00 00 00 60 nop 
15f4:   80 81 22 39 addir9,r2,-32384
15f8:   98 4e 00 7c lxvd2x  vs0,0,r9
15fc:   50 02 00 f0 xxswapd vs0,vs0 
1600:   c0 5f 0c f0 xviexpdp vs0,vs12,vs11

The results of running the code was correct. The data was loaded into vs12 and
vs11 and these are the registers used in the xviexpdp instruction. 

I verified in gdb that vs12 and vs11 have the expected values and vs0
is correct after the instruction.

With -O2 we have

14f8:   ce e8 1f 7c lvx v0,r31,r29  
14fc:   ce f8 a0 7d lvx v13,0,r31   
1500:   ce f0 3f 7c lvx v1,r31,r30  
1504:   c0 0f 0d f0 xviexpdp vs0,vs13,vs1

Note, we are loading v13 and v1, then use vs13 and vs1.  I verified
that v13 and v1 have the correct values.  So, we appear to be loading
the wrong register set.  Not sure why the optimized code loads the wrong
registers.  I don't see any issues with the inline assembly.

Note, same compiler compiled the next day, on 4/3/2018, on the same machine
with -O0 I get slightly different unoptimized code that doesn't work.  What
changed overnight I don't know but it is really annoying I can't exactly
reproduce things.

15d0:   00 00 00 60 nop 
15d4:   50 81 22 39 addir9,r2,-32432
15d8:   98 4e 00 7c lxvd2x  vs0,0,r9
15dc:   51 02 20 f0 xxswapd vs33,vs0Now using vs33 not vs12 
15e0:   00 00 00 60 nop 
15e4:   60 81 22 39 addir9,r2,-32416
15e8:   98 4e 00 7c lxvd2x  vs0,0,r9
15ec:   51 02 a0 f1 xxswapd vs45,vs0Now using vs45 not vs11 
15f0:   00 00 00 60 nop 
15f4:   80 81 22 39 addir9,r2,-32384
15f8:   98 4e 00 7c lxvd2x  vs0,0,r9
15fc:   50 02 00 f0 xxswapd vs0,vs0 
1600:   91 04 00 f0 xxlor   vs32,vs0,vs0Now using vs32 not vs0  
1604:   c0 6f 01 f0 xviexpdp vs0,vs1,vs13 

Note, we load VS register indexes that are 32 more then what is used in the
xviexpdp instruction.  I get all zeros for the result today, that is not the
correct result.  Don't know why things are compiling differently today, but the
test case result is wrong.

The test does generate the same wrong code when compiled with -O2 as it did
yesterday.  

NOTE, this may not be the only instruction where this issue is occurring. 
Still investigating.

[Bug c++/85149] [8 Regression] False branch of if constexpr instantiated in generic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Tue Apr  3 17:46:35 2018
New Revision: 259047

URL: https://gcc.gnu.org/viewcvs?rev=259047=gcc=rev
Log:
PR c++/64095 - auto... parameter pack.

* parser.c (cp_parser_parameter_declaration): Handle turning autos
into packs here.
(cp_parser_parameter_declaration_list): Not here.

Added:
   
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic16.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/parser.c
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-mangle-1.C

[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Apr  3 17:46:30 2018
New Revision: 259046

URL: https://gcc.gnu.org/viewcvs?rev=259046=gcc=rev
Log:
PR c++/85060 - wrong-code with call to base member in template.

* search.c (any_dependent_bases_p): Check uses_template_parms
rather than processing_template_decl.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/template/dependent-base3.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/search.c

[Bug c++/85149] [8 Regression] False branch of if constexpr instantiated in generic lambda

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr  3 17:41:12 2018
New Revision: 259043

URL: https://gcc.gnu.org/viewcvs?rev=259043=gcc=rev
Log:
PR c++/85149 - generic lambda and constexpr if.

* pt.c (build_extra_args, add_extra_args): Split from
tsubst_pack_expansion.
(tsubst_expr) [IF_STMT]: Use them.
* cp-tree.h (IF_STMT_EXTRA_ARGS): New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The warning appeared with r257857:

r257857 | law | 2018-02-20 13:59:22 -0500 (Tue, 20 Feb 2018) | 8 lines

PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (format_integer): Query EVRP range analyzer
for range data rather than using global data.

The difference in the dump between the revision prior to it and r257857 is:

  Directive 2 at offset 2: "%d"
Result: 1, 1, 11, 11 (3, 3, 13, 13)

and

  Directive 2 at offset 2: "%d"
Result: 1, 11, 11, 11 (3, 13, 13, 13)

I.e., GCC now thinks the likely output of the %d directive is 11 bytes (the
second number on the Result: line).  Prior to r257857 the range type of the
argument was VR_VARYING for which the warning doesn't trigger.  With r257857
the range is  [-2147483647, 3] of which the warning uses the larger bound to
trigger.

So with the change above GCC is doing a better but imperfect job of determining
the range.  Changing the variable to unsigned constrains the lower bound to
zero and eliminates the warning even at -Os.

[Bug c++/85140] [6/7 Regression] ICE with invalid use of alignas

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |invalid use of alignas  |invalid use of alignas

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/85147] [6/7 Regression] ICE with invalid variadic template-template parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |invalid variadic|invalid variadic
   |template-template parameter |template-template parameter

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/85134] [8 Regression] ICE with invalid constexpr in 'shared' OpenMP clause

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

[Bug driver/85165] gcc (and g++) not complaining about few unknown file extensions like *.CC, *.Cc, *.cC

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I suspect this is a difference between windows and linux and due to case
insensitivity rather than a difference in newer versions of GCC.

[Bug other/85161] [8 regression] Test case failures in libbacktrace on powerpc64 BE starting with r253456

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #2 from Bill Seurer  ---
I tried that patch and it looks like it works.  All those failures I saw are
gone and no new ones.

[Bug gcov-profile/85179] [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug gcov-profile/85178] [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/85147] [6/7/8 Regression] ICE with invalid variadic template-template parameter

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  3 16:22:05 2018
New Revision: 259040

URL: https://gcc.gnu.org/viewcvs?rev=259040=gcc=rev
Log:
PR c++/85147
* pt.c (fixed_parameter_pack_p_1): Punt if parm is error_mark_node.

* g++.dg/cpp0x/pr85147.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr85147.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/83678] [GCOV] a pointer assignment before a break statment lead to incorrect coverage in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-03
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug gcov-profile/85178] [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug gcov-profile/85179] [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/85140] [6/7/8 Regression] ICE with invalid use of alignas

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  3 16:21:02 2018
New Revision: 259039

URL: https://gcc.gnu.org/viewcvs?rev=259039=gcc=rev
Log:
PR c++/85140
* name-lookup.c (handle_namespace_attrs): Return early if attributes
is error_mark_node.

* g++.dg/cpp0x/gen-attrs-64.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[pc at us dot ibm.com]

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

--- Comment #4 from Paul Clarke  ---
Created attachment 43829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43829=edit
unhelpful testcase

$ gcc --version
gcc (GCC) 8.0.1 20180402 (experimental)
Copyright (C) 2018 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.

$ gcc -o 83402 83402.c -DNO_WARN_X86_INTRINSICS -Wall -O3 -mcpu=power8
$ gcc -o 83402 83402.c -DNO_WARN_X86_INTRINSICS -Wall -mcpu=power8
$

[Bug c++/85134] [8 Regression] ICE with invalid constexpr in 'shared' OpenMP clause

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  3 16:20:02 2018
New Revision: 259038

URL: https://gcc.gnu.org/viewcvs?rev=259038=gcc=rev
Log:
PR c++/85134
* decl.c (cp_finish_decl): If ensure_literal_type_for_constexpr_object
fails, after clearing DECL_DECLARED_CONSTEXPR_P don't return early,
instead for static data members clear init and set DECL_EXTERNAL.

* g++.dg/gomp/pr85134.C: New test.
* g++.dg/cpp0x/constexpr-ice19.C: Expect one further error.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr85134.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[pc at us dot ibm.com]

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

--- Comment #3 from Paul Clarke  ---
(In reply to Steven Munroe from comment #0)
> The rs6000/emmintrin.h implementation of _mm_slli_epi32 reports:
>   error: argument 1 must be a 5-bit signed literal
> 
> For constant shift values > 15.

I thought this would be trivial to reproduce, but not able to provoke it.  Do
you have a testcase?  I will attach the one I tried.

[Bug target/85169] [8 Regression] wrong code with vector member insert

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/79854] diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #4)

> Would not it be better to use
> 
> gcc_unreachable ();
> 
> as it is done in numerous places?

Sounds like a good idea to me. Dominique, do you
want to prepare a patch along these lines?

[Bug middle-end/84514] powerpc sub optimal condition register reuse with extended inline asm

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-03
  Component|target  |middle-end
 Ever confirmed|0   |1

[Bug target/85169] [8 Regression] wrong code with vector member insert

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  3 16:06:19 2018
New Revision: 259037

URL: https://gcc.gnu.org/viewcvs?rev=259037=gcc=rev
Log:
PR target/85169
* config/i386/i386.c (ix86_expand_vector_set): Use
HOST_WIDE_INT_1U << elt instead of 1 << elt.  Formatting fix.

* gcc.c-torture/execute/pr85169.c: New test.
* gcc.target/i386/avx512f-pr85169.c: New test.
* gcc.target/i386/avx512bw-pr85169.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85169.c
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85169.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85169.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85180] New: Infinite (?) loop in RTL DSE optimizer

[uweigand at gcc dot gnu.org]

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

Bug ID: 85180
   Summary: Infinite (?) loop in RTL DSE optimizer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uweigand at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
Target: s390x-ibm-linux

Created attachment 43828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43828=edit
Test case - run with "cc1plus -O"

When attempting to compile the attached testcase simply with "cc1plus -O" on a
s390x-ibm-linux target, the compilation process never terminates.  The problem
appear to originate in the dse.c pass; building with -fno-dse makes the problem
go away.

I'm not completely sure that this is really an infinite loop, strictly
speaking, or just some exponential time behavior somewhere.  In any case, at
the time the compiler hangs, it sits in a long chain of find_base_term calls
ultimately originating at the canon_output_dependence in dse.c:1593
(record_store).

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Started to be rejected with r233719

PR c++/69842
* method.c (forward_parm): Handle parameter packs.
* lambda.c (maybe_add_lambda_conv_op): Use it for them.

Still reducing it.

[Bug target/85126] [8 regression] gcc.target/powerpc/pr69946.c fails on powerpc64 BE starting with r254213

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Fixed.

[Bug target/85126] [8 regression] gcc.target/powerpc/pr69946.c fails on powerpc64 BE starting with r254213

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Author: segher
Date: Tue Apr  3 15:38:43 2018
New Revision: 259036

URL: https://gcc.gnu.org/viewcvs?rev=259036=gcc=rev
Log:
rs6000: Fix pr69946.c testcase (PR85126)

After middle-end changes combine now gets fed different input, from
which it makes different (but just as efficient) code.  So remove the
test for particular asm output.


gcc/testsuite/
PR target/85126
* gcc.target/powerpc/pr69946: Adjust comment.  Remove
scan-assembler-times clause.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr69946.c

[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value

[maryse.levavasseur at stormshield dot eu]

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

--- Comment #4 from Maryse LEVAVASSEUR  ---
Hi Andreas,
No problem for the delay, thanks for all !

[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug gcov-profile/85179] New: [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85179
   Summary: [GCOV] A label followed with a blank statement is
wrongly marked as not executed in Gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
int a = 1;
void main() {
  if (a)
goto b;
b:;
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov 
  File 'small.c'
Lines executed:80.00% of 5
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a = 1;
1:2:void main() {
1:3:  if (a)
1:4:goto b;
#:5:b:;
1:6:}

Line #5 is wrongly marked as not executed.

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #19 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #11)
> (In reply to comment #10)
> > However, with so many lines of legacy code out there using bit-filed that 
> > have
> > been proven to work, it doesn't make sense to revisit/modify them.  Would it
> > be possible for gcc to provide a -Wbitfield-conversion flag in new releases
> > and make 39170 an enhancement (preferably high priority)?
> 
> Seriously, I am not the "maintainer" of GCC diagnostics

That's David Malcolm; adding him on cc

[Bug gcov-profile/85178] New: [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85178
   Summary: [GCOV] for(;;) statement is wrongly marked as not
executed when there is a int array in its body in Gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
int a = 0;
int b() {
  for (;;) {
int c[1];
for (; 0;)
  return 0;
for (; a <= 1;)
  return 0;
  }
}
void main() { b(); }

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:85.71% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a = 0;
1:2:int b() {
#:3:  for (;;) {
-:4:int c[1];
1:5:for (; 0;)
1:6:  return 0;
1:7:for (; a <= 1;)
1:8:  return 0;
-:9:  }
-:   10:}
1:   11:void main() { b(); }


Two marks are incorrect.  
Line #3 is wrongly marked as not executed and Line #6 is wrongly marked as
executed.
While Line #4 is removed, the result is correct.

[Bug middle-end/85139] [8 Regression] Spurious format truncation warning

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
To avoid the warning, cast the argument of the %04X directive to unsigned
short:

  snprintf(s, sizeof(s), "usb:v%04Xp%04X*", (unsigned short)vn, (unsigned
short)pn);

(Note that even though casting an int to signed short will most likely work, it
isn't strictly correct.)

[Bug debug/85176] ICE in force_decl_die, at dwarf2out.c:25910

[v_lichevsky at tut dot by]

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

v_lichevsky at tut dot by changed:

   What|Removed |Added

Summary|ICE in force_decl_die, at   |ICE in force_decl_die, at
   |dwarf2out.c:25922   |dwarf2out.c:25910

--- Comment #1 from v_lichevsky at tut dot by ---
Reproduced this bug with gcc built from upstream sources, same revision as
Debian package (r259004) and adjusted line number in the title:

% ./pr85176/bin/x86_64-linux-gnu-g++-8 -O1 -flto -g1 test.cpp
lto1: internal compiler error: in force_decl_die, at dwarf2out.c:25910
0x6d4f23 force_decl_die
../.././gcc/dwarf2out.c:25910
0x6d59ab flush_limbo_die_list
../.././gcc/dwarf2out.c:30951
0x6e0f55 dwarf2out_finish
../.././gcc/dwarf2out.c:30991

[Bug c++/85128] Local scope type(def) falsely assumed to change meaning of outer scope type(def)

[steffen at sdaoden dot eu]

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

--- Comment #12 from Steffen Nurpmeso  ---
  Or you could compile with -std=c++98

Yes, thanks for the opportunity.  I would rather not, the fix was simple and
only affected this class and its specializations (of 383, 315 public
interface).

  > (we had override, as a macro that expanded to virtual)

  Yuck.

But still thinking that is better than what has been standardized, since the
"const" suffix (i call it that way..) has to be given at the definition or you
have an error, doing the same for the other one is an error by itself!


#?0[steffen@essex tmp]$ cat t.cc
#include 
class A{
char const *m_cp;
public:
A(void):m_cp(NULL){}
virtual ~A(void){}
virtual char const *msg(void) const {return m_cp;}
};
class B : A{
public:
char const *msg(void) const override;
};
char const *B::msg(void) const override {return "why-o-why";}
int
main(void){
A o1;
B o2;
printf("o1=%s o2=%s\n", o1.msg(), o2.msg());
return 0;
}
#?0[steffen@essex tmp]$ g++ -W -Wall -pedantic -o zt t.cc
t.cc:13:32: error: virt-specifiers in 'msg' not allowed outside a class
definition
 char const *B::msg(void) const override {return "why-o-why";}
^~~~

Really, really yuck.  Imho.
Being explicit and not using tags or fully blown IDEs seems obsolete it seems,
i for one like documentation free sources and then

  _pub _ove TextWriter::~TextWriter(void){..

says this is public and overrides a virtual at glance.  Changes more for the
humans than the machines i would appreciate more.  (All imho, of course.)
Ciao.  Sorry for the noise, anyway, bug was on my side.

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
In the before case, it appears that later optimization is able to remove the
i_12 add by adjusting the loop counter.  After ivopts:

  i_12 = i_5 + 4;
  ivtmp.10_17 = ivtmp.10_18 + 32;

Before SMS:

  r174 = (SI)r164 + 32
  r164 = zext(r174)

So in effect we have added the shift into the loop to remove an add that we are
able to later remove anyway.  The two adds are related but the add and the
shift are not.

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
Sure.  My point is that the modeling that's being done doesn't accurately
predict the actual loop performance.  What we need to do is figure out why.

[Bug gcov-profile/83678] [GCOV] a pointer assignment before a break statment lead to incorrect coverage in gcov

[yangyibiao at nju dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
simpler reproducer:

void main() {
  while (1) {
int a;

if (0)
  break;
if (1)
  break;
  }
}

$ gcc-8 small.c -fprofile-arcs -ftest-coverage; ./a.out gcov-8 small.c; cat
small.c.gcov
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:void main() {
-:2:  while (1) {
-:3:int a;
-:4:
-:5:if (0)
1:6:  break;
-:7:if (1)
1:8:  break;
-:9:  }
1:   10:}

Line #6 is wrongly marked as executed.

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[amker at gcc dot gnu.org]

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

--- Comment #16 from amker at gcc dot gnu.org ---
(In reply to Bill Schmidt from comment #15)
> It's a bit shift, but the result is still that it is now in the loop instead
> of outside the loop, and the total cost of the loop has increased.

But the addition for "ivtmp.10_17 = ivtmp.10_18 + 32;" is now removed?