[Bug target/84743] default widths for parallel reassociation now hurt rather than help

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from acsawdey at gcc dot gnu.org ---
Updated parallel reassociation widths that give better performance than no
parallel reassociation are checked in now so this can be closed.

[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Mar 14, 2018 at 02:41:19AM +, kargl at gcc dot gnu.org wrote:
> > 
> > Yep, gfortran is missing a simplification.  When
> > simplification of size(a) occurs, the int(1) is
> > still an expression with EXPR_FUNCTION.
> 
> Testing a patch.
> 

Bummer.  The patch causes 2 regressions.

FAIL: gfortran.dg/pr84734.f90   -O   (test for errors, line 3)
FAIL: gfortran.dg/typebound_proc_32.f90   -O  (test for excess errors)

The former should fail, but doesn't.  The latter
should pass, but fails.

[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> (In reply to Harald Anlauf from comment #4)
> > Replacing the line
> > 
> >   INTEGER :: A(int(1))
> > 
> > in comment #0 by
> > 
> >   INTEGER :: A(1)
> > 
> > or
> > 
> >   INTEGER :: A(1+0)
> > 
> > works, but other variants like
> > 
> >   INTEGER :: A((1))
> > 
> > fail.
> > 
> > Apparently some attempt to simplify is missing.
> > I think I've seen related PRs or duplicates.
> 
> Yep, gfortran is missing a simplification.  When
> simplification of size(a) occurs, the int(1) is
> still an expression with EXPR_FUNCTION.

Testing a patch.

[Bug tree-optimization/84859] New: bogus -Warray-bounds on a memcpy in a loop

[msebor at gcc dot gnu.org]

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

Bug ID: 84859
   Summary: bogus -Warray-bounds on a memcpy in a loop
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case was reduced from the report at
https://lkml.org/lkml/2018/3/13/383.

In g() GCC correctly figures out the memcpy call is safe.  In h(), though, it
thinks it overflows.

$ cat x.c && gcc -S -O2 -Wall x.c
void f (void*);

void __attribute__ ((noinline, noclone))
g (const void *p, unsigned n)
{
  unsigned char a[8];
  if (n > sizeof a)
return;

  for (; n > 0; n -= *a)
  {
 *a = n > 255 ? 255 : n;

__builtin_memcpy (a, p, *a);   // no warning (good)
  }
}

void __attribute__ ((noinline, noclone))
h (const void *p, unsigned n)
{
  unsigned char a[8];
  if (n > sizeof a)
return;

  for (; n > 0; n -= *a)
  {
if (n > 255)
  *a = 255;
else
  *a = n;

__builtin_memcpy (a, p, *a);   // bogus -Warray-bounds
  }
}
x.c: In function ‘h’:
x.c:32:5: warning: ‘__builtin_memcpy’ forming offset [9, 255] is out of the
bounds [0, 8] of object ‘a’ with type ‘unsigned char[8]’ [-Warray-bounds]
 __builtin_memcpy (a, p, *a);   // bogus -Warray-bounds
 ^~~
x.c:21:17: note: ‘a’ declared here
   unsigned char a[8];
 ^

[Bug c++/84858] New: wrong exception handling of std::function

[herumi at nifty dot com]

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

Bug ID: 84858
   Summary: wrong exception handling of std::function
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herumi at nifty dot com
  Target Milestone: ---

The following code shows "g" infinitely.
Is my code wrong? Or is it a bug of gcc?

>g++ t.cpp -O2 -std=c++11 && ./a.out
>f
>f
>g
>g
>

My environments are
Ubuntu 16.04.4 LTS
kernel : 4.4.0-116-generic
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

This was reproduced by g++ 7.2.0, 6.3.0, 5.5.0 with same option -O2 -std=c++11
and not reproduced by clang-5.0 or Visual Studio 2015.

cat t.cpp
---
#include 
#include 
#include 

void f() noexcept
{
puts("f");
}

void g()
{
puts("g");
throw std::runtime_error("err");
}

int main()
{
std::function a = f;
a();
try{
a();
} catch (...) {
}
std::function b = g;
try {
b();
} catch (...) {
}
}
---

[Bug c/30552] gcc crashes when compiling examples with GNU statement expressions in VLAs (also involved: nested functions declared K)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Eric Gallager  ---
(In reply to Dave Pagan from comment #8)
> Patch submitted for review:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00621.html

thanks; adding "patch" keyword

[Bug libstdc++/78420] [6/7/8 Regression] std::less<T*> is not a total order with -O2 enabled

[redi at gcc dot gnu.org]

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

--- Comment #29 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #28)
> I can commit a patch that fixes the original testcase, but I now think that
> the resolution of https://wg21.link/lwg2450 requires compiler help of some
> kind, at least for cases like comment 27. It effectively says "if x < y uses
> the built-in operator< for pointers, that comparison yields a total order".
> That's very different to "if x and y are pointers, comparing them yields a
> total order". The library can't tell whether x < y uses a built-in operator
> for pointers, because there could be conversions involved, so the library
> can't decide whether the cast to uintptr_t is needed.

https://github.com/ericniebler/stl2/issues/154#issuecomment-311828747 suggests
a rather disgusting way for the library to decide whether the built-in operator
for pointers would be used.

[Bug c++/82336] [6/7/8 Regression] GCC requires but does not emit defaulted constructors in certain cases

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Mar 14 01:03:13 2018
New Revision: 258512

URL: https://gcc.gnu.org/viewcvs?rev=258512=gcc=rev
Log:
PR c++/82336 - link error with list-init default argument.

* decl.c (check_default_argument): Unshare an initializer list.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-defarg2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #10 from kargl at gcc dot gnu.org ---
Closing as fixed on trunk.  I've converted the
code in comment #7 to a testcase, and committed
it so hopefully it won't get unfixed.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Mar 14 00:45:45 2018
New Revision: 258509

URL: https://gcc.gnu.org/viewcvs?rev=258509=gcc=rev
Log:
2018-03-13  Steven G. Kargl  

PR fortran/61775
* gfortran.dg/pr61775.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr61775.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/83916] [7/8 Regression] Internal compiler error on valid template code

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #4)
> Replacing the line
> 
>   INTEGER :: A(int(1))
> 
> in comment #0 by
> 
>   INTEGER :: A(1)
> 
> or
> 
>   INTEGER :: A(1+0)
> 
> works, but other variants like
> 
>   INTEGER :: A((1))
> 
> fail.
> 
> Apparently some attempt to simplify is missing.
> I think I've seen related PRs or duplicates.

Yep, gfortran is missing a simplification.  When
simplification of size(a) occurs, the int(1) is
still an expression with EXPR_FUNCTION.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #5 from Jonathan Wakely  ---
I thought this should be as simple as adding OPT_Wreturn_type to the relevant
warnings in c_finish_return in gcc/c/typeck-c.c

But it seems to be more complicated. In C89 mode the "does not" case is
actually controlled by -pedantic (and -pedantic-errors) and the "does" case is
controlled by -Wreturn-type. In C99 and later modes both diagnostics are
controlled by -pedantic.

So with current GCC and the default -std=gnu11 you do get two diagnostics:

ret.c: In function ‘t’:
ret.c:1:20: warning: ‘return’ with a value, in function returning void
 void t () { return 1; } /* does not error */
^
ret.c:1:6: note: declared here
 void t () { return 1; } /* does not error */
  ^
ret.c: In function ‘b’:
ret.c:2:12: warning: ‘return’ with no value, in function returning non-void
 int b () { return; }/* does */
^~
ret.c:2:5: note: declared here
 int b () { return; }/* does */
 ^

-Werror=return-type doesn't affect either of them, but -pedantic-errors does.

[Bug c++/82336] [6/7/8 Regression] GCC requires but does not emit defaulted constructors in certain cases

[jason at gcc dot gnu.org]

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

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/80283] [6/7/8 Regression] bad SIMD register allocation

[rsandifo at gcc dot gnu.org]

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

--- Comment #24 from rsandifo at gcc dot gnu.org  
---
(In reply to Wilco from comment #23)
> (In reply to rsand...@gcc.gnu.org from comment #22)
> 
> > > SCHED_PRESSURE_MODEL first tries to create a "model" schedule
> > > that keeps register down as far as possible and then uses that
> > > to guide the "real" schedule.  It looks like the model schedule
> > > goes catastrophically wrong in this case though: the original
> > > order had a VFP_REGS pressure of 56 (against a capacity of 64)
> > > while the model schedule had a pressure of 76(!).
> 
> Since when does ARM have 64 128-bit VFP registers? If it can't even count
> registers correctly that's the #1 problem right there...

Each 32-bit chunk is modelled as a separate VFP register, and 128-bit
modes take 4 registers each, so it all works out.

[Bug libstdc++/78420] [6/7/8 Regression] std::less<T*> is not a total order with -O2 enabled

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  ---
I can commit a patch that fixes the original testcase, but I now think that the
resolution of https://wg21.link/lwg2450 requires compiler help of some kind, at
least for cases like comment 27. It effectively says "if x < y uses the
built-in operator< for pointers, that comparison yields a total order". That's
very different to "if x and y are pointers, comparing them yields a total
order". The library can't tell whether x < y uses a built-in operator for
pointers, because there could be conversions involved, so the library can't
decide whether the cast to uintptr_t is needed.

(In reply to Jakub Jelinek from comment #21)
> So, any progress here on either the standard side or GCC side?  Do you still
> need a builtin for constexpr compatible reinterpret cast from the FE, or can
> it be solved solely in the library?

Even such a magic cast doesn't help, because the library can't tell when that
cast should be used. We can't unconditionally cast everything to uintptr_t,
only pointers, but we can't tell which operands convert to pointers.

One solution would be a new __builtin_less(op1, op2) builtin that does all the
required work:

- if overload resolution for op1 < op2 results in comparing two pointers, then
return the result of (uintptr_t)op1 < (uintptr_t)op2 instead, in a
constexpr-compatible way (including rejecting comparisons that aren't allowed
in constant expressions);
- otherwise, just evaluate op1 < op2 as normal, which may or may not be
constexpr-compatible, depending on decltype(op1) and decltype(op2).

Then std::less would just use __builtin_less(x, y) and everything is done by
the compiler. And similarly for __builtin_greater/greater_equal/less_equal.

Another solution might be __builtin_totally_ordered(op) which results in some
tree type that wraps op, and when used as the operand of a relational operator
it performs overload resolution as would happen for op, and if that would
compare pointers then op is converted to (uintptr_t)op and that is compared
instead. Then std::less would use:
  return __builtin_totally_ordered(x) < __builtin_totally_ordered(y);
But this seems a lot more work to implement, with no advantages.

Another solution would be to change the standard, so that std::less only
requires a total order when the arguments are pointers, and not for arbitrary
types that might convert to pointers.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[dave.pagan at oracle dot com]

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

Dave Pagan  changed:

   What|Removed |Added

 CC||dave.pagan at oracle dot com

--- Comment #4 from Dave Pagan  ---
If no one is working on this, I'd like to take a look into it.

[Bug c++/84855] structered bindings require "decomposed" type to be copy'able

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Hannes Hauswedell from comment #0)
> I would assume that invoking
> the structed bindings just calls get() twice on the f,

No, that's not how structured bindings are specified to work. There are not
variables 'a' and 'b' defined. Instead a variable 'e' is created from the
initializer expression, and then the identifiers 'a' and 'b' refer to members
of 'e'. The type of 'e' in your example is 'foobar'.

http://en.cppreference.com/w/cpp/language/structured_binding is a good
explanation.

[Bug c++/84857] New: A valid call to a template function in a variadic template struct is rejected

[v.reshetnikov at gmail dot com]

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

Bug ID: 84857
   Summary: A valid call to a template function in a variadic
template struct is rejected
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

The following C++ code is rejected by GCC 8.0.1 20180313 (tested with
https://godbolt.org/):

/* SOURCE */
template
struct S {
template
static int f() {
return 0;
}
};

int t = S<int, int>::f<0, 0>();
/*** END SOURCE ***/


/* OUTPUT */
:9:30: error: no matching function for call to 'S<int, int>::f<0, 0>()'
 int t = S<int, int>::f<0, 0>();
  ^
:4:16: note: candidate: 'template static int S::f() [with T
...xs = {xs ...}; T = {int, int}]'
 static int f() {
^
:4:16: note:   template argument deduction/substitution failed:
:9:30: error: wrong number of template arguments (2, should be 1)
 int t = S<int, int>::f<0, 0>();
  ^
Compiler returned: 1
/*** END OUTPUT ***/

I believe this code is correct and should be accepted.

[Bug fortran/56422] IR F08/0086: gfortran rejects valid implied-shape arrays

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
Example 2 in comment #0 should read (c.f. link in comment #2):

  Subroutine test2(a)
Real,Dimension(*) :: a,c
Parameter (c = [ 45.6 ])
a(:size(c)) = c
  End Subroutine

This one still fails, as does example 1.

However, the following rewrite of example 2 compiles with 8.0 trunk:

  Subroutine test2(a)
Real,Dimension(*) :: a
Real,Parameter:: c(*) = [ 45.6 ]
a(:size(c)) = c
  End Subroutine

[Bug middle-end/80283] [6/7/8 Regression] bad SIMD register allocation

[wilco at gcc dot gnu.org]

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

--- Comment #23 from Wilco  ---
(In reply to rsand...@gcc.gnu.org from comment #22)

> > SCHED_PRESSURE_MODEL first tries to create a "model" schedule
> > that keeps register down as far as possible and then uses that
> > to guide the "real" schedule.  It looks like the model schedule
> > goes catastrophically wrong in this case though: the original
> > order had a VFP_REGS pressure of 56 (against a capacity of 64)
> > while the model schedule had a pressure of 76(!).

Since when does ARM have 64 128-bit VFP registers? If it can't even count
registers correctly that's the #1 problem right there...

[Bug bootstrap/84856] New: Bootstrap failure on riscv: comparison of integer expressions of different signedness

[belyshev at depni dot sinp.msu.ru]

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

Bug ID: 84856
   Summary: Bootstrap failure on riscv:  comparison of integer
expressions of different signedness
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belyshev at depni dot sinp.msu.ru
  Target Milestone: ---
Target: riscv*-*-*

On RISC-V STACK_BOUNDARY and BIGGEST_ALIGNMENT are defined to an unsigned
varible, unlike most other architectures where they are constants, triggering
bootstrap failure with:

../../gcc/gcc/calls.c: In function 'poly_int64 compute_argument_block_size(int,
args_size*, tree, tree, int)':
../../gcc/gcc/calls.c:2201:60: error: comparison of integer expressions of
different signedness: 'int' and 'unsigned int' [-Werror=sign-compare]
  if (ACCUMULATE_OUTGOING_ARGS && preferred_stack_boundary > STACK_BOUNDARY)

../../gcc/gcc/final.c: In function 'int
final_addr_vec_align(rtx_jump_table_data*)':
../../gcc/gcc/final.c:521:13: error: comparison of integer expressions of
different signedness: 'int' and 'unsigned int' [-Werror=sign-compare]
   if (align > BIGGEST_ALIGNMENT / BITS_PER_UNIT)


The fix would be to change appropriate variables also to unsigned.  (Also may
as well to remove ATTRIBUTE_UNUSED annotations on of
compute_argument_block_size(), which are no longer useful since r44814.

[Bug middle-end/80283] [6/7/8 Regression] bad SIMD register allocation

[rsandifo at gcc dot gnu.org]

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

--- Comment #22 from rsandifo at gcc dot gnu.org  
---
(In reply to rsand...@gcc.gnu.org from comment #21)
> Created attachment 43646 [details]
> Patch to reduce spills for Armv7
> 
> (In reply to rsand...@gcc.gnu.org from comment #20)
> > (In reply to Wilco from comment #12)
> > > There are 2 separate issues in the ARMv7 case. One is scheduling, the -S
> > > output goes down from 437 lines to 305 lines with -fno-schedule-insns 
> > > (stack
> > > size 276 rather than 448 bytes). So basically the "register pressure 
> > > aware"
> > > scheduler introduces lots of unnecessary spills.
> > 
> > This is kind-of expected in general, though almost certainly wrong in this
> > case.  The default "weighted" algorithm tended to overemphasise decreasing
> > spills (at the cost of decreasing ILP) and slowed down some important
> > benchmarks for which some spilling was better.  The "model" algorithm was
> > supposed to be a compromise.
> > 
> > I'll have a look to see whether there's an easy way of handling this case
> > better without regressing others.  (I'm not assigning myself since it's
> > unrelated to the x86 problem.)
> 
> SCHED_PRESSURE_MODEL first tries to create a "model" schedule
> that keeps register down as far as possible and then uses that
> to guide the "real" schedule.  It looks like the model schedule
> goes catastrophically wrong in this case though: the original
> order had a VFP_REGS pressure of 56 (against a capacity of 64)
> while the model schedule had a pressure of 76(!).
> 
> I think the problem is that the algorithm was tuned on load/store
> style loops, where it was beneficial to keep the model schedule
> narrow and try to reach the eventual store (so killing off a
> whole chain).  It doesn't cope well with so many accumulators,
> where completing the chain never leads to a reduction in pressure.
> 
> The attached patch is a proof of concept that tries to handle
> this kind of situation better.  The model schedule now gives
> a VFP_REGS pressure of 52 instead of 76, which is 4 below the
> unscheduled code.  I'll try to give it more wider testing when
> I have time.
> 
> Although the patch removes some of the spills, the scheduler
> still thinks that it's better to keep others.  And in that
> sense it's working as intended, since as far as GCC's view
> of the pipeline is concerned, the spills give faster code.
> 
> This can be seen by grepping for "total time" in the sched2
> dumps, which include the effect of all the spill code.
> The times for the inner loop in this test are:
> 
> 307 cycles for the unpatched compiler (most spills)
> 355 cycles for the patched compiler (some spills)
> 398 cycles with -fno-schedule-insns (no spills)
> 
> These were all with "-mcpu=cortex-a15 -O2" but the
> results are similar with other -mcpu options.
> 
> So on GCC's own terms, using its model of the CPU,
> the current mega-spill code seems like a 25% win over
> the spill-free code.  That's probably not true in practice,
> but the scheduler can only work within the description
> it's given.

Sorry, forgot to say that all the above was with Wilco's
vdup_n_f32 modification, to work around the arm_neon.h problem.

[Bug c/84853] [7/8 Regression] ICE: verify_gimple failed (expand_shift_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
Replacing the line

  INTEGER :: A(int(1))

in comment #0 by

  INTEGER :: A(1)

or

  INTEGER :: A(1+0)

works, but other variants like

  INTEGER :: A((1))

fail.

Apparently some attempt to simplify is missing.
I think I've seen related PRs or duplicates.

[Bug c/30552] gcc crashes when compiling examples with GNU statement expressions in VLAs (also involved: nested functions declared K)

[dave.pagan at oracle dot com]

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

--- Comment #8 from Dave Pagan  ---
Patch submitted for review:

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00621.html

[Bug libstdc++/78420] [6/7/8 Regression] std::less<T*> is not a total order with -O2 enabled

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely  ---
Here's a really horrible case:

#include 
#include 

struct X {
  operator const X*() const { return this; }
};

X x;
X y;

int main()
{
  std::less<> lt;
  bool x_less_than_y = lt(x, y);
  bool y_less_than_x = lt(y, x);
  bool x_equal_to_y = !lt(x, y) && !lt(y, x);
  assert( ((int)x_less_than_y + (int)y_less_than_x + (int)x_equal_to_y) == 1 );
}

This happens to give the right answer today, but I don't trust it to always do
so. We can't dispatch to the special case for pointers that casts to uintptr_t
because we can't know that we'll be comparing pointers (without
std::experimental::invocation_type at least ... so I guess I finally have a use
case for that).

[Bug c++/84855] New: structered bindings require "decomposed" type to be copy'able

[h2+bugs at fsfe dot org]

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

Bug ID: 84855
   Summary: structered bindings require "decomposed" type to be
copy'able
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

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

If I do

foobar f; // has tuple-like interface
auto [ a, b ] = f;

Then for some reason foo needs to be copyable and I don't understand why, i.e.
perceive this as a bug, although both GCC and Clang require it.

I have attached a file that illustrates this. I would assume that invoking the
structed bindings just calls get() twice on the f, but gobolting the attached
code without optimisations reveals that indeed f is being copied.

And the actual problem is that explicitly deleting the copy-constructor of
foobar makes the build fail.

Like I said, maybe I am missing something here, but why would there be a copy
involved of type f. [Obviously there is copy involved of the members of f,
depending on the return type of get(), but that's a different matter from f].

Thank you for your help!

Confirmed on
g++-7 (Debian 7.3.0-8)
g++-8 (Debian 8-20180308-1)
clang version 5.0.1-2

[Bug middle-end/80283] [6/7/8 Regression] bad SIMD register allocation

[rsandifo at gcc dot gnu.org]

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

--- Comment #21 from rsandifo at gcc dot gnu.org  
---
Created attachment 43646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43646=edit
Patch to reduce spills for Armv7

(In reply to rsand...@gcc.gnu.org from comment #20)
> (In reply to Wilco from comment #12)
> > There are 2 separate issues in the ARMv7 case. One is scheduling, the -S
> > output goes down from 437 lines to 305 lines with -fno-schedule-insns (stack
> > size 276 rather than 448 bytes). So basically the "register pressure aware"
> > scheduler introduces lots of unnecessary spills.
> 
> This is kind-of expected in general, though almost certainly wrong in this
> case.  The default "weighted" algorithm tended to overemphasise decreasing
> spills (at the cost of decreasing ILP) and slowed down some important
> benchmarks for which some spilling was better.  The "model" algorithm was
> supposed to be a compromise.
> 
> I'll have a look to see whether there's an easy way of handling this case
> better without regressing others.  (I'm not assigning myself since it's
> unrelated to the x86 problem.)

SCHED_PRESSURE_MODEL first tries to create a "model" schedule
that keeps register down as far as possible and then uses that
to guide the "real" schedule.  It looks like the model schedule
goes catastrophically wrong in this case though: the original
order had a VFP_REGS pressure of 56 (against a capacity of 64)
while the model schedule had a pressure of 76(!).

I think the problem is that the algorithm was tuned on load/store
style loops, where it was beneficial to keep the model schedule
narrow and try to reach the eventual store (so killing off a
whole chain).  It doesn't cope well with so many accumulators,
where completing the chain never leads to a reduction in pressure.

The attached patch is a proof of concept that tries to handle
this kind of situation better.  The model schedule now gives
a VFP_REGS pressure of 52 instead of 76, which is 4 below the
unscheduled code.  I'll try to give it more wider testing when
I have time.

Although the patch removes some of the spills, the scheduler
still thinks that it's better to keep others.  And in that
sense it's working as intended, since as far as GCC's view
of the pipeline is concerned, the spills give faster code.

This can be seen by grepping for "total time" in the sched2
dumps, which include the effect of all the spill code.
The times for the inner loop in this test are:

307 cycles for the unpatched compiler (most spills)
355 cycles for the patched compiler (some spills)
398 cycles with -fno-schedule-insns (no spills)

These were all with "-mcpu=cortex-a15 -O2" but the
results are similar with other -mcpu options.

So on GCC's own terms, using its model of the CPU,
the current mega-spill code seems like a 25% win over
the spill-free code.  That's probably not true in practice,
but the scheduler can only work within the description
it's given.

[Bug target/83712] [6/7 Regression] "Unable to find a register to spill" when compiling for thumb1

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Mar 13 20:42:49 2018
New Revision: 258504

URL: https://gcc.gnu.org/viewcvs?rev=258504=gcc=rev
Log:
2018-03-13  Vladimir Makarov  

PR target/83712
* lra-assigns.c (find_all_spills_for): Ignore uninteresting
pseudos.
(assign_by_spills): Return a flag of reload assignment failure.
Do not process the reload assignment failures.  Do not spill other
reload pseudos if they has the same reg class.  Update n if
necessary.
(lra_assign): Add a return arg.  Set up from the result of
assign_by_spills call.
(find_reload_regno_insns, lra_split_hard_reg_for): New functions.
* lra-constraints.c (split_reg): Add a new arg.  Use it instead of
usage_insns if it is not NULL.
(spill_hard_reg_in_range): New function.
(split_if_necessary, inherit_in_ebb): Pass a new arg to split_reg.
* lra-int.h (spill_hard_reg_in_range, lra_split_hard_reg_for): New
function prototypes.
(lra_assign): Change prototype.
* lra.c (lra): Add code to deal with fails by splitting hard reg
live ranges.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/lra-int.h
trunk/gcc/lra.c

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jason at gcc dot gnu.org]

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

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

[Bug c++/82410] [7/8 Regression] ICE in replace_placeholders_r

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
It really is the same issue.

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

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 13 20:32:54 2018
New Revision: 258503

URL: https://gcc.gnu.org/viewcvs?rev=258503=gcc=rev
Log:
PR c++/84843
* decl.c (duplicate_decls): For redefinition of built-in, use error
and return error_mark_node.  For redeclaration, return error_mark_node
rather than olddecl if !flag_permissive.

* g++.dg/ext/pr84843-1.C: New test.
* g++.dg/ext/pr84843-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr84843-1.C
trunk/gcc/testsuite/g++.dg/ext/pr84843-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82565] [7 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||gccbugzilla at szaszm dot tk

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

[Bug c++/67491] [meta-bug] concepts issues

[jason at gcc dot gnu.org]

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

Bug 81997 Summary: [7/8 Regression] segfault while instantiating constrained 
function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81997

   What|Removed |Added

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

[Bug c++/81997] [7/8 Regression] segfault while instantiating constrained function template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Same issue.

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

[Bug c++/82565] [7 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jesse at mind dot net

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

[Bug c++/67491] [meta-bug] concepts issues

[jason at gcc dot gnu.org]

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

Bug 81918 Summary: [7/8 Regression] muddled Concept confuses compiler (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81918

   What|Removed |Added

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

[Bug c++/81918] [7/8 Regression] muddled Concept confuses compiler (segfault)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Same issue.

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

[Bug c++/82565] [7 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|[7/8 Regression] Concept|[7 Regression] Concept and
   |and lambda return type  |lambda return type
   |deduction cause compilation |deduction cause compilation
   |to crash with "mmap: Cannot |to crash with "mmap: Cannot
   |allocate memory"|allocate memory"

[Bug c++/82565] [7/8 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Mar 13 20:22:31 2018
New Revision: 258502

URL: https://gcc.gnu.org/viewcvs?rev=258502=gcc=rev
Log:
PR c++/82565 - ICE with concepts and generic lambda.

* pt.c (instantiate_decl): Clear fn_context for lambdas.

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

[Bug c++/84798] [6/7 Regression] ICE (Segmentation fault) if `auto` appears in a template argument

[reichelt at gcc dot gnu.org]

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

--- Comment #8 from Volker Reichelt  ---
*** Bug 79525 has been marked as a duplicate of this bug. ***

[Bug c++/79525] [c++1y] ICE with auto as function parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||8.0.1
 Resolution|--- |DUPLICATE
  Known to fail||7.3.0

--- Comment #2 from Volker Reichelt  ---
This was fixed by Jason's patch for PR84798.

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

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

--- Comment #9 from Pat Haugen  ---
(In reply to Martin Jambor from comment #7)
> Do I understand it correctly that you suspect that the new IPA-CP
> clone that is created from r256888 on is harmful?  In that case, you
> want to test that by trying higher values of ipa-cp-eval-threshold,
> something like --param ipa-cp-eval-threshold 610 (i.e. bigger than
> 606).  Of course, if there are other clones with evaluations between
> 500 and 610, it would affect them too.
> 

Building with --param ipa-cp-eval-threshold=610 prevented the creation of the
.resid_.constprop.1 clone and eliminated the performance degradation.

Looking at the profile more in depth, I saw that most of the time in
resid_.constprop was spent in the main vectorized loop. I tried both revisions
with -fno-tree-vectorize to see if vectorization in the clone is the real
problem on powerpc, but ran into issues with output miscompare (pr83497, which
I'm still digging on). Ignoring output miscompare and just timing the two
versions built with -fno-tree-vectorize, I see that the  performance is
similar. So possibly a powerpc vector cost issue.


> You may also want to try both fast and slow revisions with
> -fno-ipa-cp-clone as the first step, actually.

Doing this showed r256888 about 4% slower, so not near as bad.

[Bug c++/84798] [6/7 Regression] ICE (Segmentation fault) if `auto` appears in a template argument

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #7 from Volker Reichelt  ---
*** Bug 84541 has been marked as a duplicate of this bug. ***

[Bug c++/84541] ICE with auto in function parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #3 from Volker Reichelt  ---
Duplicate of PR84798.

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

[Bug c++/84349] [6/7/8 Regression] ICE with auto in function cast

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Depends on||84798

--- Comment #3 from Volker Reichelt  ---
This was fixed on trunk by Jason's patch for PR84798.
Do we want to add this as a testcase or close it as a duplicate?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84798
[Bug 84798] [6/7 Regression] ICE (Segmentation fault) if `auto` appears in a
template argument

[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #13 from kargl at gcc dot gnu.org ---
I intend to close this PR after updating the information
about Cray pointers and an assumed-sized array.  The
Fortran clearly states


8.5.8.5 Assumed-size array
An assumed-size array is a dummy argument array whose size
is assumed from that of its effective argument, ...

An assumed-sized simply cannot appear in the specification
portion of a module. The text in gfortran.info will be


The pointer is an integer that is intended to hold
a memory address. The pointee may be an array or scalar.
If an assumed-size array is permitted within the scoping
unit, a pointee can be an assumed-size array. That is, the
last dimension may be left unspecified by using a * in place
of a value. A pointee cannot be an assumed shape array. No
space is allocated for the pointee.

Index: gfortran.texi
===
--- gfortran.texi   (revision 258468)
+++ gfortran.texi   (working copy)
@@ -1906,10 +1906,13 @@ or,
 pointer (  ,  ), (  ,  ), ...
 @end smallexample
 The pointer is an integer that is intended to hold a memory address.
-The pointee may be an array or scalar.  A pointee can be an assumed
-size array---that is, the last dimension may be left unspecified by
-using a @code{*} in place of a value---but a pointee cannot be an
-assumed shape array.  No space is allocated for the pointee.
+The pointee may be an array or scalar.
+If an assumed-size array is permitted within the scoping unit, a
+pointee can be an assumed-size array.
+That is, the last dimension may be left unspecified by using a @code{*}
+in place of a value.
+A pointee cannot be an assumed shape array.
+No space is allocated for the pointee.

 The pointee may have its type declared before or after the pointer
 statement, and its array specification (if any) may be declared

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
(In reply to kargl from comment #7)

> I would like to close this as fixed after committing the following
> testcase
> 
> program pi
> real   , allocatable :: x(:)
> integer  :: n
> n  = 1
> x = [ (i,i=1,n) ]
> if (x(n) /= 1) stop 1
> end

Sure, go ahead.

[Bug c++/84720] [7/8 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.c:3472

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Mar 13 18:58:15 2018
New Revision: 258501

URL: https://gcc.gnu.org/viewcvs?rev=258501=gcc=rev
Log:
PR c++/84720 - ICE with rvalue ref non-type argument.

* pt.c (convert_nontype_argument): Handle rvalue references.

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

[Bug c++/84839] [6/7/8 Regression] ICE (Segmentation fault) when `decltype` is used with parameter pack

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Mar 13 18:57:10 2018
New Revision: 258500

URL: https://gcc.gnu.org/viewcvs?rev=258500=gcc=rev
Log:
PR c++/84839 - ICE with decltype of parameter pack.

* pt.c (tsubst_pack_expansion): Set cp_unevaluated_operand while
instantiating dummy parms.

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

[Bug c/84853] [7/8 Regression] ICE: verify_gimple failed (expand_shift_1)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |7.4

[Bug c/84853] [7/8 Regression] ICE: verify_gimple failed (expand_shift_1)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r238936.

[Bug c++/84849] Ambiguous resolution of braze initializer list to a class with explicit constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|Ambiguous resolution of |Ambiguous resolution of
   |braze initializer list to a |braze initializer list to a
   |class with explicit |class with explicit
   |copy/move constructors  |constructors

--- Comment #2 from Jonathan Wakely  ---
Further reduced:


struct X {
  X(int) { }
};

struct Foo {
  explicit Foo(const X&);
  explicit Foo(X&&) { }
};

int main() {
  Foo v({1});
}


vs.cc: In function 'int main()':
vs.cc:11:12: error: call of overloaded 'Foo()'
is ambiguous
   Foo v({1});
^
vs.cc:7:12: note: candidate: 'Foo::Foo(X&&)'
   explicit Foo(X&&) { }
^~~
vs.cc:6:12: note: candidate: 'Foo::Foo(const X&)'
   explicit Foo(const X&);
^~~
vs.cc:5:8: note: candidate: 'constexpr Foo::Foo(const Foo&)'
 struct Foo {
^~~
vs.cc:5:8: note: candidate: 'constexpr Foo::Foo(Foo&&)'

[Bug c++/84854] [7/8 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/84854] [7/8 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774

[mpolacek at gcc dot gnu.org]

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

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

[Bug c++/84849] Ambiguous resolution of braze initializer list to a class with explicit copy/move constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jose Dapena Paz from comment #0)
> For a template class with explicit copy and move constructors,

Those aren't copy and move constructors.

Reduced:

struct X
{
  X(const char*) { }
};

template 
class Foo {
 public:
  template 
  explicit Foo(Args&&... args);

  explicit Foo(const T&);
  explicit Foo(T&&) { }

  Foo(const Foo&) = delete;
  Foo& operator=(const Foo&) = delete;

  ~Foo() = default;
};

int main() {
  Foo v({"a"});
}



vs.cc: In function 'int main()':
vs.cc:22:17: error: call of overloaded 'Foo()'
is ambiguous
   Foo v({"a"});
 ^
vs.cc:15:3: note: candidate: 'Foo::Foo(const Foo&) [with T = X]'

   Foo(const Foo&) = delete;
   ^~~
vs.cc:13:12: note: candidate: 'Foo::Foo(T&&) [with T = X]'
   explicit Foo(T&&) { }
^~~
vs.cc:12:12: note: candidate: 'Foo::Foo(const T&) [with T = X]'
   explicit Foo(const T&);
^~~

[Bug c++/84854] [7/8 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

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

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from David Malcolm  ---
Started with r250203 ("c/c++: Add fix-it hints for suggested missing
#includes")

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
I think that this is now fixed on trunk.  Don't know which patch.

% gfcx -o z a.f90 && ./z
   1.
% gfcx -o z a.f90 -O2 -fcheck=all && ./z
   1.
% valgrind ./z
==85120== Memcheck, a memory error detector
==85120== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==85120== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==85120== Command: ./z
==85120== 
   1.
==85120== 
==85120== HEAP SUMMARY:
==85120== in use at exit: 0 bytes in 0 blocks
==85120==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==85120== 
==85120== All heap blocks were freed -- no leaks are possible
==85120== 
==85120== For counts of detected and suppressed errors, rerun with: -v
==85120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I've read the tree dump for -fdump-tree-optimized and it appears to
do the right think with expanding the constructor, allocating, and
freeing memory.

Both 6-branch and 7-branch still fail
% gfc6 -o z a.f90 -O2 -fcheck=all && ./z
 Segmentation fault (core dumped)
% gfc7 -o z a.f90 -O2 -fcheck=all && ./z
Segmentation fault (core dumped)

I would like to close this as fixed after committing the following
testcase

program pi
real   , allocatable :: x(:)
integer  :: n
n  = 1
x = [ (i,i=1,n) ]
if (x(n) /= 1) stop 1
end

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; am investigating.

[Bug c++/84854] New: [7/8 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774

[gs...@t-online.de]

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

Bug ID: 84854
   Summary: [7/8 Regression] ICE: unexpected expression in
cxx_eval_constant_expression, at cp/constexpr.c:4774
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20160807 and 20160814 :


$ cat z1.cc
template  void a() {
  if constexpr(a) { };
}


$ gcc-8-20180311 -c z1.cc
z1.cc: In function 'void a()':
z1.cc:2:6: warning: 'if constexpr' only available with -std=c++17 or
-std=gnu++17
   if constexpr(a) { };
  ^
z1.cc:2:17: internal compiler error: unexpected expression 'a' of kind overload
   if constexpr(a) { };
 ^
0x6a506d cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4774
0x6a67fc cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:4833
0x793945 finish_if_stmt_cond(tree_node*, tree_node*)
../../gcc/cp/semantics.c:739
0x737e93 cp_parser_selection_statement
../../gcc/cp/parser.c:11393
0x737e93 cp_parser_statement
../../gcc/cp/parser.c:10816
0x7387a7 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11274
0x73887f cp_parser_compound_statement
../../gcc/cp/parser.c:11228
0x74a37e cp_parser_function_body
../../gcc/cp/parser.c:21778
0x74a37e cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21813
0x74ab40 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26828
0x74dce6 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26745
0x74dce6 cp_parser_init_declarator
../../gcc/cp/parser.c:19502
0x74e0cf cp_parser_single_declaration
../../gcc/cp/parser.c:27284
0x74e1bc cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:26886
0x74e82c cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:27124
0x74e82c cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:27142
0x757929 cp_parser_declaration
../../gcc/cp/parser.c:12729
0x756356 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12656
0x75665f cp_parser_translation_unit
../../gcc/cp/parser.c:4561
0x75665f c_parse_file()
../../gcc/cp/parser.c:39005

[Bug c/84853] New: [7/8 Regression] ICE: verify_gimple failed (expand_shift_1)

[gs...@t-online.de]

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

Bug ID: 84853
   Summary: [7/8 Regression] ICE: verify_gimple failed
(expand_shift_1)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed before 20160807, invalid code affects version 7/8 :


$ cat z1.c
typedef float V __attribute__((vector_size(16)));
V
foo (int a, V b)
{
  return b << a;
}


$ gcc-8-20180311 -c z1.c
during RTL pass: expand
z1.c: In function 'foo':
z1.c:5:12: internal compiler error: in expand_shift_1, at expmed.c:2631
   return b << a;
  ~~^~~~
0x83168f expand_shift_1
../../gcc/expmed.c:2631
0x8329c3 expand_variable_shift(tree_code, machine_mode, rtx_def*, tree_node*,
rtx_def*, int)
../../gcc/expmed.c:2673
0x8500b0 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9381
0x75053d expand_gimple_stmt_1
../../gcc/cfgexpand.c:3729
0x75053d expand_gimple_stmt
../../gcc/cfgexpand.c:3790
0x75191d expand_gimple_basic_block
../../gcc/cfgexpand.c:5819
0x756da6 execute
../../gcc/cfgexpand.c:6425



Configured with --enable-checking=yes :

$ gcc-8-20180311 -c z1.c
z1.c: In function 'foo':
z1.c:3:1: error: type mismatch in shift expression
 foo (int a, V b)
 ^~~
V
V
int
D.1963 = b << a;
z1.c:3:1: internal compiler error: verify_gimple failed
0xcbbbcd verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5247
0x9e35a7 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12710
0x9e3944 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12800
0x82e987 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x832083 analyze_functions
../../gcc/cgraphunit.c:1131
0x832b92 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2691

[Bug c++/84720] [7/8 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.c:3472

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/84852] New: [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[gs...@t-online.de]

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

Bug ID: 84852
   Summary: [8 Regression] ICE in calculate_line_spans, at
diagnostic-show-locus.c:1105
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20170618 and 20170716 :


$ cat z1.c
#line 77
int foo (void) { return strlen(""); }


$ gcc-8-20180311 -c z1.c
z1.c: In function 'foo':
z1.c:-812156815:25: warning: implicit declaration of function 'strlen'
[-Wimplicit-function-declaration]
z1.c:-812156815:25: warning: incompatible implicit declaration of built-in
function 'strlen'
z1.c:-812156815:25: note: include '' or provide a declaration of
'strlen'

z1.c:-812156815:1: internal compiler error: in calculate_line_spans, at
diagnostic-show-locus.c:1105
0x123853b calculate_line_spans
../../gcc/diagnostic-show-locus.c:1105
0x123853b layout
../../gcc/diagnostic-show-locus.c:819
0x1238724 diagnostic_show_locus(diagnostic_context*, rich_location*,
diagnostic_t)
../../gcc/diagnostic-show-locus.c:1970
0x6f8df7 c_diagnostic_finalizer
../../gcc/c-family/c-opts.c:169
0x12352f5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:989
0x1235743 diagnostic_impl
../../gcc/diagnostic.c:1108
0x1236489 inform(rich_location*, char const*, ...)
../../gcc/diagnostic.c:1181
0x666377 implicitly_declare(unsigned int, tree_node*)
../../gcc/c/c-decl.c:3418
0x67a4db build_external_ref(unsigned int, tree_node*, bool, tree_node**)
../../gcc/c/c-typeck.c:2755
0x6980d7 c_parser_postfix_expression
../../gcc/c/c-parser.c:7881
0x6a0fa2 c_parser_unary_expression
../../gcc/c/c-parser.c:7263
0x6a1d57 c_parser_cast_expression
../../gcc/c/c-parser.c:7104
0x6a2023 c_parser_binary_expression
../../gcc/c/c-parser.c:6907
0x6a3065 c_parser_conditional_expression
../../gcc/c/c-parser.c:6645
0x6a35f0 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6562
0x6a3872 c_parser_expression
../../gcc/c/c-parser.c:9292
0x6a4d79 c_parser_expression_conv
../../gcc/c/c-parser.c:9325
0x6b4c77 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5451
0x6b0a4a c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5078
0x6b1156 c_parser_compound_statement
../../gcc/c/c-parser.c:4912

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #11)

> Nah, just the following - you removed LTO testing of prettyprinters
> 
> Index: libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
> ===
> --- libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp  
> (revision 258481)
> +++ libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp  
> (working copy)
> @@ -50,7 +50,7 @@ gdb-dg-runtest [lsort [glob $srcdir/$sub
>  if { [check_effective_target_lto] } {
>append cxxflags " -flto"
># work around sourceware.org 20882
> -  regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags
> +  #regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags
>gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
>  "" "$DEFAULT_CXXFLAGS -flto $PCH_CXXFLAGS"
>  }

With this patch applied:

https://sourceware.org/ml/binutils/2018-03/msg00175.html

I got

# of expected passes140

=== libstdc++ Summary ===

# of expected passes201

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #5)
> (In reply to Jakub Jelinek from comment #2)
> > Just a note, as can be seen e.g. on
> > static volatile int a;
> > static int my_foo1 (void) { return 1; }
> > static int my_foo2 (void) { return 2; }
> > typedef int (*F) (void);
> > static F resolve_foo (void) { if (a) return my_foo1; else return my_foo2; }
> > static int foo (void) __attribute__ ((ifunc ("resolve_foo")));
> > 
> > int
> > main ()
> > {
> >   if (foo () != 2)
> > __builtin_abort ();
> > }
> > there is no reason why any of the target clones, resolver or the ifunc
> > function should be .globl, they can all be local to the TU, IFUNC work just
> > fine that way too.  So, if the function with target_clones attribute is not
> > TREE_PUBLIC, neither should be any of the multiple_targets.c created 
> > symbols.
> 
> If I see correctly, we do not make these global:
> 
> nm pr84833-2.o 
>  b a
>  U abort
> 000c i foo
> 0022 T main
>  t my_foo1
> 0006 t my_foo2
> 000c t resolve_foo
> 
> Note that it was subject of PR81213.

nm is not really usable to determine if an IFUNC symbol is global or local, i
is printed regardless if it is global or local.
$ nm pr84833 | grep foo; readelf -Ws pr84833 | grep foo
00400560 i foo
00400540 t my_foo1
00400550 t my_foo2
00400560 t resolve_foo
27: 00400540 6 FUNCLOCAL  DEFAULT   13 my_foo1
28: 00400550 6 FUNCLOCAL  DEFAULT   13 my_foo2
29: 0040056023 FUNCLOCAL  DEFAULT   13 resolve_foo
31: 0040056023 IFUNC   LOCAL  DEFAULT   13 foo
$ nm pr84833-2 | grep foo; readelf -Ws pr84833-2 | grep foo
00400560 i foo
00400540 t my_foo1
00400550 t my_foo2
00400560 t resolve_foo
27: 00400540 6 FUNCLOCAL  DEFAULT   13 my_foo1
28: 00400550 6 FUNCLOCAL  DEFAULT   13 my_foo2
29: 0040056023 FUNCLOCAL  DEFAULT   13 resolve_foo
59: 0040056023 IFUNC   GLOBAL DEFAULT   13 foo
Where pr84833.c is the above #c2 testcase and pr84833-2.c is that without
static keyword on foo.

These testcases are compiled fine, what I was trying to make sure is that if
the target_clones function is static, it is not exported outside of the TU.

[Bug c/46921] Lost side effect when struct initializer expression uses comma operator

[jsm28 at gcc dot gnu.org]

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

--- Comment #5 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Mar 13 18:10:09 2018
New Revision: 258497

URL: https://gcc.gnu.org/viewcvs?rev=258497=gcc=rev
Log:
PR c/46921 Lost side effect when struct initializer expression uses comma
operator

This patch fixes improper handling of comma operator expression in a
struct field initializer as described in:

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

Currently, function output_init_element () does not evaluate the left
hand expression in a comma operator that's used for a struct
initializer field if the right hand side is zero-sized. However, the
left hand expression must be evaluated if it's found to have side
effects (for example, a function call).

Patch was successfully bootstrapped and tested on x86_64-linux.

gcc/c:
2018-03-13  David Pagan  

PR c/46921
* c-typeck.c (output_init_element): Ensure field initializer
expression is always evaluated if there are side effects.

gcc/testsuite:
2018-03-13  David Pagan  

PR c/46921
* gcc.dg/pr46921.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr46921.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/46921] Lost side effect when struct initializer expression uses comma operator

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #6 from Joseph S. Myers  ---
Fixed for GCC 8.

[Bug c++/84839] [6/7/8 Regression] ICE (Segmentation fault) when `decltype` is used with parameter pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84850] -Wclass-memaccess on a memcpy in a copy assignment operator with no nontrivial bases or members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Depends on||84851

--- Comment #2 from Martin Sebor  ---
Bug 84851 shows that the exemption for copy ctors is overly simplistic and
broad.  Using the same mechanism for copy assignment would not be appropriate
because it would compromise the warning and prevent it from detecting some
undefined cases.  Adding an exemption for copy assignment will require checking
all bases and members to make sure they are trivial.  That makes the solution
for this bug dependent on pr84851.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84851
[Bug 84851] missing -Wclass-memaccess for a memcpy in a copy ctor with a
non-trivial member

[Bug target/84845] [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/84851] New: missing -Wclass-memaccess for a memcpy in a copy ctor with a non-trivial member

[msebor at gcc dot gnu.org]

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

Bug ID: 84851
   Summary: missing -Wclass-memaccess for a memcpy in a copy ctor
with a non-trivial member
   Product: gcc
   Version: 8.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: ---

-Wclass-memaccess excempts ctors and dtors of non-polymorphic classes from
checking for raw memory accesses, but the warning does trigger for such
accesses in classes with a virtual table to help detect virtual table
corruption.  However, the exemption is too broad and allows for the corruption
of virtual tables or subobjects with non-trivial members.

$ cat u.C && gcc -S -Wall -Wextra u.C
struct A
{
  const int 

  A ();

  A (const A&);

  virtual ~A ();
};

struct B: A
{
  B (const B&);
};

B::B (const B )
{
  __builtin_memcpy (this, , sizeof b);   // -Wclass-memaccess (good)
}

struct C
{
  A a;

  C (const C&);
};

C::C (const C )
{
  __builtin_memcpy (this, , sizeof c);   // missing -Wclass-memaccess
}
u.C: In copy constructor ‘B::B(const B&)’:
u.C:17:1: warning: base class ‘struct A’ should be explicitly initialized in
the copy constructor [-Wextra]
 B::B (const B )
 ^
u.C:19:39: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned
int)’ writing to an object of type ‘struct B’ with no trivial copy-assignment;
use copy-initialization instead [-Wclass-memaccess]
   __builtin_memcpy (this, , sizeof b);   // -Wclass-memaccess (good)
   ^
u.C:12:8: note: ‘struct B’ declared here
 struct B: A
^

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On March 13, 2018 5:15:33 PM GMT+01:00, "nickc at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
>
>--- Comment #16 from Nick Clifton  ---
>Hi H.J.
>
>(In reply to H.J. Lu from comment #15)
>> It should be fixed in linker.
>
>OK - so how does the linker distinguish between a file that only
>contains
>debug information, none of which is needed, and a file that only
>contains
>debug information of which some/all actually is needed ?

There are used symbols and associated debug sections need to be kept. If
nothing references the debug it can be discarded. 

>Cheers
>  Nick

[Bug c++/84850] -Wclass-memaccess on a memcpy in a copy assignment operator with no nontrivial bases or members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||msebor at gcc dot gnu.org
Summary|new GCC version prints  |-Wclass-memaccess on a
   |warning on memcpy call (no  |memcpy in a copy assignment
   |nontrivial bases or |operator with no nontrivial
   |members)|bases or members
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The warning is designed to allow raw memory access in ctors and dtors of
non-trivial classes with no non-trivial bases or members, but the exemption
doesn't extend to assignment operators of such classes.  Some such types
(including squid's TrafficMode class) use memcpy in the special functions as a
shortcut to copy multiple trivial members without having to explicitly
enumerate them.  Since this is safe it makes sense to exempt the copy
assignment operator as well.  Confirmed with the test case below.

$ cat pr84850.C && gcc -S  -Wall pr84850.C
struct S
{
  bool a, b;
  S ();
  S (const S&);
  ~S ();
  void operator= (const S&);
};

S::S ()
{
  __builtin_memset (this, 0, sizeof *this);
}

S::S (const S )
{
  __builtin_memcpy (this, , sizeof s);
}

S::~S ()
{
  __builtin_memset (this, 0, sizeof *this);
}

void S::operator= (const S )
{
  __builtin_memcpy (this, , sizeof s);
}

pr84850.C: In member function ‘void S::operator=(const S&)’:
pr84850.C:27:39: warning: ‘void* __builtin_memcpy(void*, const void*, long
unsigned int)’ writing to an object of type ‘struct S’ with no trivial
copy-assignment; use copy-assignment or copy-initialization instead
[-Wclass-memaccess]
   __builtin_memcpy (this, , sizeof s);
   ^
pr84850.C:1:8: note: ‘struct S’ declared here
 struct S
^

[Bug fortran/84848] [8 Regression] FAIL: gfortran.dg/coarray/event_3.f08 -fcoarray=single -O2 -latomic execution test

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2018-03-13 10:57 AM, dominiq at lps dot ens.fr wrote:
> WORKSFORME on x86_64-apple-darwin17. A target issue?
I'm not sure how this test is supposed to work:

Breakpoint 3, 0x00010498 in main (argc=, argv=)
     at 
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/event_3.f08:10
10    call exchange
(gdb) disass
Dump of assembler code for function main:
    0x00010488 <+0>: stw rp,-14(sp)
    0x0001048c <+4>: ldo 40(sp),sp
    0x00010490 <+8>: b,l 0x10448,rp
    0x00010494 <+12>:    nop
=> 0x00010498 <+16>:    ldi 7,r26
    0x0001049c <+20>:    ldil L%10800,r25
    0x000104a0 <+24>:    b,l 0x10458,rp
    0x000104a4 <+28>:    ldo 2ec(r25),r25
    0x000104a8 <+32>:    ldw -38(sp),ret0
    0x000104ac <+36>:    cmpib,<> 0,ret0,0x104c0 
    0x000104b0 <+40>:    ldi 0,ret0
    0x000104b4 <+44>:    ldw -54(sp),rp
    0x000104b8 <+48>:    bv r0(rp)
    0x000104bc <+52>:    ldo -40(sp),sp
    0x000104c0 <+56>:    ldi 0,r25
    0x000104c4 <+60>:    b,l 0x10468,rp
    0x000104c8 <+64>:    ldi 1,r26
    0x000104cc <+68>:    nop
End of assembler dump.
(gdb) x/x $sp - 0x38
0xf8d02308: 0x00130ee8
(gdb) c
Continuing.

Breakpoint 2, 0x000104ac in exchange ()
     at 
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/event_3.f08:17
17    if (cnt /= 2) error stop 1
(gdb) x/x $sp - 0x38
0xf8d02308: 0x00130ee8
(gdb) p/x $ret0
$1 = 0x130ee8

cnt is a location on the stack but the address of options.0.923 is 
passed in %r25 to _gfortran_set_options.
It looks as if the "call event_query(x, cnt)" line in the test has bee 
optimized away.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #17 from H.J. Lu  ---
Moved to

https://sourceware.org/bugzilla/show_bug.cgi?id=20882

[Bug target/84845] [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
First of all, I'd say it is very weird not to include the actual operation name
in the instruction name, that is the most important part.

So something like:
--- gcc/config/aarch64/aarch64.md.jj2018-03-13 00:38:26.0 +0100
+++ gcc/config/aarch64/aarch64.md   2018-03-13 18:08:23.513894885 +0100
@@ -4262,7 +4262,7 @@
   [(set_attr "type" "shift_reg")]
 )

-(define_insn_and_split "*aarch64_reg_3_neg_mask2"
+(define_insn_and_split "*aarch64__reg_3_neg_mask2"
   [(set (match_operand:GPI 0 "register_operand" "=")
(SHIFT:GPI
  (match_operand:GPI 1 "register_operand" "r")
@@ -4286,7 +4286,7 @@
   }
 )

-(define_insn_and_split "*aarch64_reg_3_minus_mask"
+(define_insn_and_split "*aarch64_ashl_reg_3_minus_mask"
   [(set (match_operand:GPI 0 "register_operand" "=")
(ashift:GPI
  (match_operand:GPI 1 "register_operand" "r")
@@ -4333,7 +4333,7 @@
   [(set_attr "type" "shift_reg")]
 )

-(define_insn_and_split "*aarch64_reg__minus3"
+(define_insn_and_split "*aarch64__reg_minus3"
   [(set (match_operand:GPI 0 "register_operand" "=")
(ASHIFT:GPI
  (match_operand:GPI 1 "register_operand" "r")

[Bug target/84845] [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r249774.

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> I thank you for the fast fix. I can confirm that libreoffice now builds fine.

You're welcome.

> Are you considering adding the reduced test-case to our test-suite?

See the submission.

[Bug libstdc++/70664] failbit is not set on stream reading negative value into unsigned type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Patch fixing this:
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00601.html

[Bug target/84743] default widths for parallel reassociation now hurt rather than help

[acsawdey at gcc dot gnu.org]

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

--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Mar 13 16:28:09 2018
New Revision: 258495

URL: https://gcc.gnu.org/viewcvs?rev=258495=gcc=rev
Log:
2018-03-13  Aaron Sawdey  

PR target/84743
* config/rs6000/rs6000.c (rs6000_reassociation_width): Disable parallel
reassociation for int modes.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug c++/84850] New: new GCC version prints warning on memcpy call (no nontrivial bases or members)

[luhliari at redhat dot com]

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

Bug ID: 84850
   Summary: new GCC version prints warning on memcpy call (no
nontrivial bases or members)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luhliari at redhat dot com
  Target Milestone: ---

Hello gcc-c++ team,

I'm trying to build squid with new gcc-c++, and I'm getting following error:

libtool: compile:  g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib
-I../../src -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -Wall
-Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual
-Werror -pipe -D_REENTRANT -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection
-fPIC -c PoolChunked.cc  -fPIC -DPIC -o PoolChunked.o >/dev/null 2>&1
In file included from ../../src/anyp/PortCfg.h:14,
 from ../../src/MasterXaction.h:13,
 from ../../src/CommCalls.h:16,
 from ../../src/comm.h:13,
 from ../../src/CommRead.h:15,
 from ../../src/Store.h:15,
 from old_api.cc:26:
../../src/anyp/TrafficMode.h: In member function 'AnyP::TrafficMode&
AnyP::TrafficMode::operator=(const AnyP::TrafficMode&)':
../../src/anyp/TrafficMode.h:26:93: error: 'void* memcpy(void*, const void*,
size_t)' writing to an object of type 'class AnyP::TrafficMode' with no trivial
copy-assignment; use copy-assignment or copy-initialization instead
[-Werror=class-memaccess]
 TrafficMode  =(const TrafficMode ) { memcpy(this, ,
sizeof(TrafficMode)); return *this; }
   
 ^
In file included from ../../src/anyp/PortCfg.h:14,
 from ../../src/MasterXaction.h:13,
 from ../../src/CommCalls.h:16,
 from ../../src/comm.h:13,
 from ../../src/CommRead.h:15,
 from ../../src/Store.h:15,
 from old_api.cc:26:
../../src/anyp/TrafficMode.h:21:7: note: 'class AnyP::TrafficMode' declared
here
 class TrafficMode
   ^~~
In file included from ../../src/comm/Connection.h:18,
 from ../../src/anyp/PortCfg.h:15,
 from ../../src/MasterXaction.h:13,
 from ../../src/CommCalls.h:16,
 from ../../src/comm.h:13,
 from ../../src/CommRead.h:15,
 from ../../src/Store.h:15,
 from old_api.cc:26:
../../src/eui/Eui64.h: In member function 'Eui::Eui64&
Eui::Eui64::operator=(const Eui::Eui64&)':
../../src/eui/Eui64.h:40:70: error: 'void* memcpy(void*, const void*, size_t)'
writing to an object of type 'class Eui::Eui64' with no trivial
copy-assignment; use copy-assignment or copy-initialization instead
[-Werror=class-memaccess]
 Eui64& operator= (const Eui64 ) {memcpy(this, , sizeof(Eui64)); return
*this;}
  ^
../../src/eui/Eui64.h:34:7: note: 'class Eui::Eui64' declared here
 class Eui64
   ^
cc1plus: all warnings being treated as errors



I guess, in this case, warning should not be printed.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[nickc at gcc dot gnu.org]

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

--- Comment #16 from Nick Clifton  ---
Hi H.J.

(In reply to H.J. Lu from comment #15)
> It should be fixed in linker.

OK - so how does the linker distinguish between a file that only contains
debug information, none of which is needed, and a file that only contains
debug information of which some/all actually is needed ?

Cheers
  Nick

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
(In reply to Nick Clifton from comment #14)
> Created attachment 43643 [details]
> Proposed patch
> 
> Hi Guys.
> 
>   Here is a possible patch, although it is a bit hackish.
>   Richard might not like it because it changes gcc/lto-wrapper.c rather than
>   the linker, but I honestly think that the linker is doing the right thing
>   in this case.
> 

It should be fixed in linker.

[Bug c++/84849] New: Ambiguous resolution of braze initializer list to a class with explicit copy/move constructors

[jose.dapena at lge dot com]

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

Bug ID: 84849
   Summary: Ambiguous resolution of braze initializer list to a
class with explicit copy/move constructors
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jose.dapena at lge dot com
  Target Milestone: ---

Created attachment 43644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43644=edit
Test case

For a template class with explicit copy and move constructors, passing a
std::vector of std::string using initializer list syntax fails because of geing
ambiguous.

Attached test example.

main.cc: In function ‘int main(int, char**)’:
main.cc:22:62: error: call of overloaded ‘Foo()’ is ambiguous
   static Foo vector({"a", "b", "c"});
  ^
main.cc:14:3: note: candidate: Foo::Foo(const Foo&) [with T =
std::vector] 
   Foo(const Foo&) = delete;
   ^~~
main.cc:12:12: note: candidate: Foo::Foo(T&&) [with T =
std::vector]
   explicit Foo(T&& x) { }
^~~
main.cc:11:12: note: candidate: Foo::Foo(const T&) [with T =
std::vector]
   explicit Foo(const T& x) {  }

This test case works properly on clang (it resolves to the move constructor.

[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
That is a separate issue, not caused by the previous patch.

I have a patch for this, too.

[Bug fortran/84848] [8 Regression] FAIL: gfortran.dg/coarray/event_3.f08 -fcoarray=single -O2 -latomic execution test

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2018-03-13 10:57 AM, dominiq at lps dot ens.fr wrote:
> WORKSFORME on x86_64-apple-darwin17. A target issue?
I see it also occurs on 32-bit hppa-unknown-linux-gnu but not on 32-bit 
hppa2.0w-hp-hpux11.11.
So, it might be ELF specific.

On the linux target, r257884 was okay and r257960 bad. Last target 
change in February was r257672.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[nickc at gcc dot gnu.org]

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

--- Comment #14 from Nick Clifton  ---
Created attachment 43643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43643=edit
Proposed patch

Hi Guys.

  Here is a possible patch, although it is a bit hackish.
  Richard might not like it because it changes gcc/lto-wrapper.c rather than
  the linker, but I honestly think that the linker is doing the right thing
  in this case.

Cheers
  Nick

[Bug sanitizer/83392] FAIL: c-c++-common/ubsan/ptr-overflow-sanitization-1.c scan-tree-dump-times

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested fix.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm  ---
(In reply to H.J. Lu from comment #12)
> Need GCC 8 to reproduce:
Thanks.  What version of ld was this with?

[Bug c++/84798] [6/7/8 Regression] ICE (Segmentation fault) if `auto` appears in a template argument

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Mar 13 15:55:07 2018
New Revision: 258493

URL: https://gcc.gnu.org/viewcvs?rev=258493=gcc=rev
Log:
PR c++/84798 - ICE with auto in abstract function declarator.

* parser.c (cp_parser_parameter_declaration_clause): Check
parser->default_arg_ok_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/auto51.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/cpp1y/pr60393.C

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from H.J. Lu  ---
Need GCC 8 to reproduce:

/usr/gcc-8.0.1-x32/bin/gcc -I ./src -flto -O2 -g -c src/bootchart.c -o
build/bootchart.o
/usr/gcc-8.0.1-x32/bin/gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
/usr/gcc-8.0.1-x32/bin/gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
  build/bootchart.o build/log.o \
  -o build/systemd-bootchart
/usr/local/bin/ld: removing unused section '.rodata.cst4' in file
'/lib/../lib64/crt1.o'
/usr/local/bin/ld: removing unused section '.data' in file
'/lib/../lib64/crt1.o'
/usr/local/bin/ld: removing unused section '.data' in file
'/usr/gcc-8.0.1-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.1/crtbegin.o'
/usr/local/bin/ld: removing unused section '.debug_abbrev' in file
'/tmp/ccpV3zjtdebugobj'
/usr/local/bin/ld: removing unused section '.debug_str' in file
'/tmp/ccpV3zjtdebugobj'
/usr/lib/rpm/debugedit build/systemd-bootchart
/usr/lib/rpm/debugedit: build/systemd-bootchart: Invalid .line_table offset
0x2b0803
make: *** [Makefile:23: test] Segmentation fault

[Bug sanitizer/83392] FAIL: c-c++-common/ubsan/ptr-overflow-sanitization-1.c scan-tree-dump-times

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
When I try to fix this using:
--- gcc/sanopt.c.jj 2018-03-02 00:15:54.670780980 +0100
+++ gcc/sanopt.c2018-03-13 16:35:38.333020680 +0100
@@ -486,12 +486,17 @@ maybe_optimize_ubsan_ptr_ifn (sanopt_ctx
   HOST_WIDE_INT bitpos;
   base = get_inner_reference (base, , , , ,
  , , );
-  if (offset == NULL_TREE
+  if ((offset == NULL_TREE || TREE_CODE (offset) == INTEGER_CST)
  && DECL_P (base)
  && pbitpos.is_constant ())
{
  gcc_assert (!DECL_REGISTER (base));
- offset_int expr_offset = bitpos / BITS_PER_UNIT;
+ offset_int expr_offset;
+ if (offset)
+   expr_offset = wi::to_offset (offset) + bitpos / BITS_PER_UNIT;
+ else
+   expr_offset = bitpos / BITS_PER_UNIT;
+ expr_offset = wi::sext (expr_offset, POINTER_SIZE);
  offset_int total_offset = expr_offset + cur_offset;
  if (total_offset != wi::sext (total_offset, POINTER_SIZE))
{
then ptr-overflow-sanitization-1.c FAILs for -m32 like before (i.e. 14 times,
would need to adjust testcase), but -m64 FAILs 13 times compared to previous 17
times.

[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Mine.  I think we can handle this in vect_can_force_dr_alignment_p, maybe using
SCEV analysis.

[Bug tree-optimization/84725] enable attribute nonstring for all narrow character types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Adjusted patch committed in r258492.

[Bug tree-optimization/84725] enable attribute nonstring for all narrow character types

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Mar 13 15:33:16 2018
New Revision: 258492

URL: https://gcc.gnu.org/viewcvs?rev=258492=gcc=rev
Log:
PR tree-optimization/84725 - enable attribute nonstring for all narrow
character types

gcc/c-family/ChangeLog:

PR tree-optimization/84725
* c-attribs.c (handle_nonstring_attribute): Allow attribute nonstring
with all three narrow character types, including their qualified forms.

gcc/testsuite/ChangeLog:

PR tree-optimization/84725
* c-c++-common/Wstringop-truncation-4.c: New test.
* c-c++-common/attr-nonstring-5.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
trunk/gcc/testsuite/c-c++-common/attr-nonstring-5.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/83392] FAIL: c-c++-common/ubsan/ptr-overflow-sanitization-1.c scan-tree-dump-times

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The difference is in:
486   HOST_WIDE_INT bitpos;
487   base = get_inner_reference (base, , , ,
,
488   , , );
489   if (offset == NULL_TREE
490   && DECL_P (base)
491   && pbitpos.is_constant ())

On 64-bit, offset is non-NULL, sizetype 0x8001, and pbitpos is 0,
on 32-bit offset is NULL and pbitpos is -17179869176 (i.e. signed HWI
0xfffc0008).  The difference is because pbitpos is poly_int16 and 8 *
0x8001 is not representable in signed HOST_WIDE_INT, while 8 *
0x8001 is.