[Bug middle-end/64242] Longjmp expansion incorrect

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #19 from Paul Hua  ---
It's fails on mips64el-unknown-linux-gnu

FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test

[Bug sanitizer/56682] -fsanitize documentation

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Maybe for leak, not sure about that.  For UBSan I think it isn't needed.

[Bug sanitizer/88333] [9 Regression] ice in asan_emit_stack_protection, at asan.c:1574

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  5 08:26:06 2018
New Revision: 266817

URL: https://gcc.gnu.org/viewcvs?rev=266817&root=gcc&view=rev
Log:
PR sanitizer/88333
* cfgexpand.c (expand_stack_vars): If asan_vec is empty, start with
aligning frame offset to ASAN_RED_ZONE_SIZE bytes.

* c-c++-common/asan/pr88333.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr88333.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88092] class nontype template deduction failed when providing type to class

[emmanuel.le-tr...@cnrs-orleans.fr]

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

emmanuel.le-tr...@cnrs-orleans.fr changed:

   What|Removed |Added

 CC||emmanuel.le-trong@cnrs-orle
   ||ans.fr

--- Comment #3 from emmanuel.le-tr...@cnrs-orleans.fr ---
I have a problem with this. AFAIK, nowhere in the standard is written that a
class template without argument (i.e. not a type!) can be used as the type of a
non-type template argument. [temp.param] §4 says

> A non-type template-parameter shall have one of the following (optionally 
> cv-qualified) types:
>  — a type that is literal, has strong structural equality (10.10.1), has no 
> mutable or volatile subobjects, and in which if there is a defaulted member 
> operator<=>, then it is declared public,
>  — an lvalue reference type,
>  — a type that contains a placeholder type (9.1.7.5), or
>  — a placeholder for a deduced class type (9.1.7.6).

So 

template  struct A {};
template  struct B {};

should not be valid IMO.

[Bug sanitizer/88333] [9 Regression] ice in asan_emit_stack_protection, at asan.c:1574

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  5 08:43:12 2018
New Revision: 266818

URL: https://gcc.gnu.org/viewcvs?rev=266818&root=gcc&view=rev
Log:
PR c++/87897
* g++.dg/init/const13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/const13.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/85569] [8/9 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
*** Bug 87897 has been marked as a duplicate of this bug. ***

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed by r266816 aka PR85569 fix.

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

[Bug c++/85569] [8 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
Summary|[8/9 Regression]|[8 Regression]
   |is_invocable(F, |is_invocable(F,
   |decltype(objs)...)  fails   |decltype(objs)...)  fails
   |with "not supported by  |with "not supported by
   |dump_expr#" unless via  |dump_expr#" unless via
   |indirection |indirection

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug c++/88092] class nontype template deduction failed when providing type to class

[hanicka at hanicka dot net]

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

--- Comment #4 from Hana Dusíková  ---
(In reply to Emmanuel Le Trong from comment #3)
> I have a problem with this. AFAIK, nowhere in the standard is written that a
> class template without argument (i.e. not a type!) can be used as the type
> of a non-type template argument. [temp.param] §4 says
> 
> > A non-type template-parameter shall have one of the following (optionally 
> > cv-qualified) types:
> >  — a type that is literal, has strong structural equality (10.10.1), has no 
> > mutable or volatile subobjects, and in which if there is a defaulted member 
> > operator<=>, then it is declared public,
> >  — an lvalue reference type,
> >  — a type that contains a placeholder type (9.1.7.5), or
> >  — a placeholder for a deduced class type (9.1.7.6).
> 
> So 
> 
> template  struct A {};
> template  struct B {};
> 
> should not be valid IMO.

You are correct, you must have class template argument deduction rule. This
should be valid:

template  struct A {
constexpr A(...) {}
};
template  A(T) -> A;

template  struct B {};

[Bug c++/88092] class nontype template deduction failed when providing type to class

[hanicka at hanicka dot net]

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

--- Comment #5 from Hana Dusíková  ---
So minimal example is:

template
struct S {
 constexpr S(...) { }
};

template  S(T) -> S;

template  struct foo { };


template 
void fn ()
{
  auto t = s;
  foo f1;
  foo f2;
}

[Bug target/88343] [7/8/9 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
I've been trying the following;

There were two bugs;
1) the test for Darwin's pic reg needs to be in the save_reg_p () func for
other callers.
2) the bit of code in the #ifdef was essentially doing nothing in most cases
since Darwin's RS6000_PIC_OFFSET_TABLE_REGNUM is usually (always?) 31.

--

(keeping V4 and Darwin separate in the testing was because there was another
option for V4 [ !constant_pool_empty_p () ] to be evaluated).  

This completed without regression on Power7 (gcc110) and correctly elides the
pic reg save for the trivial testcase.  Darwin bootstrapped, but testing will
take at least 8h so not able to say if that's OK yet.

---

commit cef9f706e794d85afbebc748dbb89541519428c9
Author: Iain Sandoe 
Date:   Tue Dec 4 08:01:05 2018 +

trial fix for 88343

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index b5d8584..c296a4a 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -23949,8 +23949,12 @@ save_reg_p (int reg)
  || !constant_pool_empty_p ()))
return true;

-  if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
- && flag_pic)
+  if (DEFAULT_ABI == ABI_V4
+  && flag_pic && crtl->uses_pic_offset_table)
+   return true;
+
+  else if (DEFAULT_ABI == ABI_DARWIN
+  && flag_pic && crtl->uses_pic_offset_table)
return true;
 }

@@ -23970,13 +23974,6 @@ first_reg_to_save (void)
 if (save_reg_p (first_reg))
   break;

-#if TARGET_MACHO
-  if (flag_pic
-  && crtl->uses_pic_offset_table
-  && first_reg > RS6000_PIC_OFFSET_TABLE_REGNUM)
-return RS6000_PIC_OFFSET_TABLE_REGNUM;
-#endif
-
   return first_reg;
 }

[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Reduced testcase:
module pr88304
  implicit none
  type t
 integer :: b = -1
  end type t
contains
  subroutine f1 (x)
integer (kind = 4), intent(out) :: x
x = 5
  end subroutine f1
  subroutine f2 ()
type(t) :: x
call f3
if (x%b .ne. 5) stop 1
  contains
subroutine f3
  call f1 (x%b)
end subroutine f3
  end subroutine f2
end module pr88304

[Bug fortran/88356] [9 Regression] ICE with -Werror in reduce_binary_ac, at fortran/arith.c:1318 (and others)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/88361] gcc does not unroll loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-05
 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Richard Biener  ---
Well, 9*9 == 81 is simply above the hard limit we put on the number of unrolled
iterations (controlled by --param max-completely-peel-times where the default
is 16).  For a loop nest the limit is applied to individual loops which
explains
why you may see a total of 81 scalar iterations unrolled.

One could say we have too many individual knobs (we do!) and that the number
of copies limit is pointless since we have a size limit as well.  But that
doesn't work for the case where GCC thinks the loop shrinks by unrolling it.

But yes, improvements are possible here (esp. with inner body unroll times
in a nest vs. non-nest).

[Bug c++/88362] attribute aligned silently ignored on C++ references

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
But isn't alignof (r) the alignment of the 'int' while alignof (p) is the
alignment of the pointer?!

That is, alignof(&r) should produce 64, no?  Seems to produce 8 for me.

Still your test is bougs?

Btw, alignof(*p) produces 4 as well, consistent with that for r.

I think to align the pointer you need a typedef, attribute placement doesn't
allow distinguishing between pointed-to vs. pointer type the same way
as qualifiers do.

[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I'll fix the tree-nested.c issue, but I'm wondering about the clobber.  E.g.
for
module pr88304
  implicit none
  type t
integer :: b = -1
integer :: c = 2
  end type t
contains
  subroutine f1 (x)
integer, intent(out) :: x
x = 5
  end subroutine f1
  subroutine f4 (x)
integer, intent(in) :: x
  end subroutine f4
  subroutine f2 ()
type(t) :: x
call f3
if (x%b .ne. 5) stop 1
  contains
subroutine f3
  call f1 (x%b)
end subroutine f3
subroutine f5
  call f4 (x%b)
end subroutine f5
  end subroutine f2
end module pr88304

the clobber at the beginning of f3 doesn't make sense to me:
f3 ()
{
  x = {CLOBBER};
  _1 = &x.b;
  f1 (_1);
}
Does the fact that you call f1 (x%b) and f1's argument is intent(in) clobber
the whole type, including x%c?  I'd expect only x%b to be clobbered.

Or consider:
module pr88304
  implicit none
  type t
integer :: b = -1
integer :: c = 2
  end type t
contains
  subroutine f1 (x)
integer, intent(out) :: x
x = 5
  end subroutine f1
  subroutine f2 ()
type(t) :: x
call f1 (x%b)
if (x%b .ne. 5 .or. x%c .ne. 2) stop 1
  end subroutine f2
end module pr88304
  use pr88304
  call f2
end

This fails at -O2, is it really undefined?

[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
And lastly, what tree-nested.c does in cases which don't really fail is pretty
weird:
module pr88304
  implicit none
contains
  subroutine f1 (x)
integer, intent(out) :: x
x = 5
  end subroutine f1
  subroutine f2 ()
integer :: x
call f3
if (x .ne. 5) stop 1
  contains
subroutine f3
  call f1 (x)
end subroutine f3
  end subroutine f2
end module pr88304

The original
  x = {CLOBBER};
is replaced here with:
  integer(kind=4) D.3863;

  D.3863 = {CLOBBER};
  CHAIN.3->x = D.3863;
I guess we want to drop those from the IL instead as well.

[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Wed, 5 Dec 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
> 
> --- Comment #10 from Jakub Jelinek  ---
> And lastly, what tree-nested.c does in cases which don't really fail is pretty
> weird:
> module pr88304
>   implicit none
> contains
>   subroutine f1 (x)
> integer, intent(out) :: x
> x = 5
>   end subroutine f1
>   subroutine f2 ()
> integer :: x
> call f3
> if (x .ne. 5) stop 1
>   contains
> subroutine f3
>   call f1 (x)
> end subroutine f3
>   end subroutine f2
> end module pr88304
> 
> The original
>   x = {CLOBBER};
> is replaced here with:
>   integer(kind=4) D.3863;
> 
>   D.3863 = {CLOBBER};
>   CHAIN.3->x = D.3863;
> I guess we want to drop those from the IL instead as well.

Heh, yes.  Or convert them to

D.3863 = CHAIN.3->x;
*D.3863 = {CLOBBER};

but not sure if those will ever end up being useful.

[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 5 Dec 2018, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
> 
> --- Comment #11 from rguenther at suse dot de  ---
> On Wed, 5 Dec 2018, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
> > 
> > --- Comment #10 from Jakub Jelinek  ---
> > And lastly, what tree-nested.c does in cases which don't really fail is 
> > pretty
> > weird:
> > module pr88304
> >   implicit none
> > contains
> >   subroutine f1 (x)
> > integer, intent(out) :: x
> > x = 5
> >   end subroutine f1
> >   subroutine f2 ()
> > integer :: x
> > call f3
> > if (x .ne. 5) stop 1
> >   contains
> > subroutine f3
> >   call f1 (x)
> > end subroutine f3
> >   end subroutine f2
> > end module pr88304
> > 
> > The original
> >   x = {CLOBBER};
> > is replaced here with:
> >   integer(kind=4) D.3863;
> > 
> >   D.3863 = {CLOBBER};
> >   CHAIN.3->x = D.3863;
> > I guess we want to drop those from the IL instead as well.
> 
> Heh, yes.  Or convert them to
> 
> D.3863 = CHAIN.3->x;
> *D.3863 = {CLOBBER};
> 
> but not sure if those will ever end up being useful.

Might be in case the function is inlined if we manage to turn
it back to

  x = {CLOBBER};

?

[Bug target/87288] [8 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
I'm doing the backport now.

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha  ---
Created attachment 45157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45157&action=edit
Testcase #5

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181202 -mavx2 -O2
-fsave-optimization-record -ftree-parallelize-loops=2 -ftree-slp-vectorize -g
-w -c pa97jedl.c
during GIMPLE pass: parloops
pa97jedl.c: In function 'n':
pa97jedl.c:49:1: internal compiler error: tree check: expected block, have
 in inlining_chain_to_json, at optinfo-emit-json.cc:285
   49 | n(__int128 u128_8, uint8_t uc_9) {
  | ^
0x6dd3f7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree.c:9757
0x65f661 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree.h:3154
0x65f661 optrecord_json_writer::inlining_chain_to_json(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/optinfo-emit-json.cc:285
0xc14b1a optrecord_json_writer::optinfo_to_json(optinfo const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/optinfo-emit-json.cc:419
0xc14b48 optrecord_json_writer::add_record(optinfo const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/optinfo-emit-json.cc:141
0x94bc42 dump_context::emit_optinfo(optinfo const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/dumpfile.c:1207
0x94bc42 dump_context::end_any_optinfo()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/dumpfile.c:1193
0x94e33f dump_context::begin_scope(char const*, dump_user_location_t const&,
dump_impl_location_t const&)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/dumpfile.c:1132
0xf47943 auto_dump_scope::auto_dump_scope(char const*, dump_user_location_t
const&, dump_impl_location_t const&)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/dumpfile.h:609
0xf47943 vect_analyze_loop_form_1(loop*, gcond**, tree_node**, tree_node**,
tree_node**, gcond**)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-vect-loop.c:1156
0xf48134 vect_analyze_loop_form(loop*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-vect-loop.c:1312
0xdb983f gather_scalar_reductions
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-parloops.c:2599
0xdb983f try_create_reduction_list
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-parloops.c:2784
0xdb983f parallelize_loops
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-parloops.c:3391
0xdbb4ad execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-parloops.c:3505
0xdbb4ad execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-parloops.c:3484

parloops again.

This one is weird. Why does it stop ICEing when I simply change indentation or
remove obviously superfluous semicolons or parens?

[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 45158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45158&action=edit
gcc9-pr88304.patch

Untested fix for the tree-nested.c bug, handles it like we handle it in
convert_local_reference_stmt.

[Bug fortran/88364] New: [9 Regression] Wrong-code due to CLOBBER

[jakub at gcc dot gnu.org]

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

Bug ID: 88364
   Summary: [9 Regression] Wrong-code due to CLOBBER
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: anlauf at gmx dot de, jakub at gcc dot gnu.org, rguenth at 
gcc dot gnu.org,
unassigned at gcc dot gnu.org
Depends on: 88304
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

+++ This bug was initially created as a clone of Bug #88304 +++

As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304#c9
I believe the CLOBBERs added in:
  else if (add_clobber)
{
  tree clobber;
  tree var;
  /* FIXME: This fails if var is passed by reference, see PR
 41453.  */
  var = expr->symtree->n.sym->backend_decl;
  clobber = build_clobber (TREE_TYPE (var));
  gfc_add_modify (&se->pre, var, clobber);
}
are sometimes IMHO inappropriate, in particular if we are passing by reference
only a part of some variable (when the size of the expression that actually
should be clobbered is smaller than the whole backend_decl).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
[Bug 88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267

[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |wrong-code
 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from Jakub Jelinek  ---
Testcase (FAILs with -O2):

module pr88364
  implicit none
  type t
integer :: b = -1
integer :: c = 2
  end type t
contains
  subroutine f1 (x)
integer, intent(out) :: x
x = 5
  end subroutine f1
  subroutine f2 ()
type(t) :: x
call f1 (x%b)
if (x%b .ne. 5 .or. x%c .ne. 2) stop 1
  end subroutine f2
end module pr88364
  use pr88364
  call f2
end

If t doesn't have c field, it would be ok to clobber whole x, even when we want
to clobber just x%b, because x%b occupies all bits of x.

Likely started with r264506 aka PR41453 fix.

[Bug middle-end/41453] use INTENT(out) for optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
See PR88364 for fallout.

[Bug c++/88365] New: -Wsign-conversion ignores implicit conversion

[igor.chorazewicz at intel dot com]

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

Bug ID: 88365
   Summary: -Wsign-conversion ignores implicit conversion
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.chorazewicz at intel dot com
  Target Milestone: ---

Consider following code, compiled with -Wsign-conversion:

#include 

template 
struct wrapper {
T t;

operator T() 
{
return t; 
}

T get()
{
return t;
}
};

int main() {
int a[10];
int* x { a } ;
wrapper y{2};

std::cout << (x + y); // warning
}

It produces "warning: conversion to 'long int' from 'long unsigned int' may
change the sign of the result". If y is of type "long unsigned int", there is
no warning. Moreover when I explicitly call y.get() there is also no warning:

std::cout << (x + y.get()); // ok

[Bug tree-optimization/87360] [8/9 Regression] ICE in remove_redundant_iv_tests at gcc/tree-ssa-loop-ivcanon.c:571 since r255467

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  5 11:05:59 2018
New Revision: 266820

URL: https://gcc.gnu.org/viewcvs?rev=266820&root=gcc&view=rev
Log:
PR tree-optimization/87360
* gimple-loop-jam.c (tree_loop_unroll_and_jam): On failure to analyze
data dependencies, don't return false, just continue.  Formatting
fixes.
(merge_loop_tree, bb_prevents_fusion_p, unroll_jam_possible_p,
fuse_loops): Formatting fixes.

* g++.dg/opt/pr87360.C: New test.
* gfortran.dg/pr87360.f90: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr87360.C
trunk/gcc/testsuite/gfortran.dg/pr87360.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-loop-jam.c
trunk/gcc/testsuite/ChangeLog

[Bug d/88366] New: ubsan build of d

[dcb314 at hotmail dot com]

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

Bug ID: 88366
   Summary: ubsan build of d
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried a ubsan build of the new D code in gcc trunk.

./../trunk/gcc/d/dmd/dsymbol.c:1194:56: runtime error: shift exponent 32 is too
large for 32-bit type 'int'

../../trunk/gcc/d/dmd/intrange.c:240:7: runtime error: shift exponent 64 is too
large for 64-bit type 'long unsigned int'

../../trunk/gcc/d/dmd/dsymbol.c:1199:64: runtime error: shift exponent 53 is
too large for 32-bit type 'int'

[Bug tree-optimization/87360] [8 Regression] ICE in remove_redundant_iv_tests at gcc/tree-ssa-loop-ivcanon.c:571 since r255467

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |remove_redundant_iv_tests   |remove_redundant_iv_tests
   |at  |at
   |gcc/tree-ssa-loop-ivcanon.c |gcc/tree-ssa-loop-ivcanon.c
   |:571 since r255467  |:571 since r255467
  Known to fail|9.0 |

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

[Bug c++/88362] attribute aligned silently ignored on C++ references

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
More likely clang implemented a different extension than gcc had.

[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug bootstrap/81033] [8 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #51 from Iain Sandoe  ---
closing as fixed - the problem exists on 6 and 5, but those branches are
closed, so interested folks will have to apply the patches locally.

[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 45159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45159&action=edit
candidate patch

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
I think the issue is we use vect_location via DUMP_VECT_SCOPE before we
set it, thus using an old location in a function where we may have GCed
BLOCKs, etc.  The loop vectorization pass resets it via

  vect_location = dump_user_location_t ();

(?)  but the SLP vectorization pass not.

diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index 0a4eca51ad7..1a6cb56a872 100644
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -1303,6 +1303,8 @@ pass_slp_vectorize::execute (function *fun)
   loop_optimizer_finalize ();
 }

+  vect_location = dump_user_location_t ();
+
   return 0;
 }


This fixes one testcase.  I'm going to apply that.

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Fixed?

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Dec  5 11:36:03 2018
New Revision: 266821

URL: https://gcc.gnu.org/viewcvs?rev=266821&root=gcc&view=rev
Log:
2018-12-05  Richard Biener  

PR tree-optimization/86637
* tree-vectorizer.c (pass_slp_vectorize::execute): Reset
vect_location at the end.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vectorizer.c

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #6 from Alexandre Oliva  ---
The patch I've just attached to bug 87814 affects this as well, but although it
allows the testcase to avoid this specific crash, it still fails later, while
synthesizing a ctor for dn.

[Bug c/88367] New: [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[pbutsykin at virtuozzo dot com]

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

Bug ID: 88367
   Summary: [9 Regression] -fno-delete-null-pointer-checks doesn't
work properly
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pbutsykin at virtuozzo dot com
  Target Milestone: ---

For some reason gcc9 began to delete NULL pointer checks even with
-fno-delete-null-pointer-checks option (which should prohibit doing so).

There is the following function:
static long kmapset_cmp(struct kmapset_map *map_a, struct kmapset_map *map_b)
{
struct kmapset_link *link_a, *link_b;

if (map_a->hash != map_b->hash)
return map_a->hash - map_b->hash;

if (map_a->size != map_b->size)
return map_a->size - map_b->size;

link_a = hlist_entry(map_a->links.first,
struct kmapset_link, map_link);
link_b = hlist_entry(map_b->links.first,
struct kmapset_link, map_link);
while (&link_a->map_link) {
if (link_a->key != link_b->key)
return (long)link_a->key - (long)link_b->key;
if (link_a->value != link_b->value)
return link_a->value - link_b->value;
link_a = list_entry(link_a->map_link.next,
struct kmapset_link, map_link);
link_b = list_entry(link_b->map_link.next,
struct kmapset_link, map_link);
}

return map_a->default_value - map_b->default_value;
}
Full source:
https://github.com/OpenVZ/vzkernel/blob/branch-rh7-3.10.0-123.1.2-ovz/lib/kmapset.c

The problem is that gcc9 removes while condition 'while (&link_a->map_link)'
even with -fno-delete-null-pointer-checks option. There is undefined behavior
with taking the address from lvalue which doesn't designate an object. In the
case when map_a->links.first is NULL, then link_a will be equal to (NULL - 24)
and expression &((struct kmapset_link *)(NULL - 24))->map_link will refer to
NULL. Ok, it's undefined behavior and the compiler can remove this check, but
shouldn't -fno-delete-null-pointer-checks prevent this? GCC8 with
-fno-delete-null-pointer-checks don't remove this check.
GCC9 was built on this commit:
commit 3d4762327aed5cf6cafbaa7a52166df4ef92eb82
Author: rguenth 
Date:   Tue Dec 4 11:26:14 2018 +

2018-12-04  Richard Biener  

PR tree-optimization/88301
* tree-vrp.c (register_edge_assert_for_2): Fix sign-conversion
issues in last commit.

The assembly code generated by gcc9 - https://pastebin.com/dkuEuyLQ
81b4bd9c:   48 8b 48 f0 movrcx,QWORD PTR 
[rax-0x10]  //BUG: unable to handle kernel paging request at fff0
(this is link_a->key)

All gcc flags that are used - https://pastebin.com/6AbyEXgF

[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Adjusted testcase that fails also with -m64:
struct A { unsigned char a[84]; };
struct B { unsigned char b[216]; };
struct C { union { struct A c; struct B d; }; };
struct D { unsigned char e[65536]; unsigned int f; __SIZE_TYPE__ g; };

void
foo (struct D *s)
{
  struct C t;
  unsigned char *e = s->e + 64;
  unsigned int l = s->f;
  __SIZE_TYPE__ o = s->g;
  if (o > 512)
o -= 512;
  o -= 204;
  if (o > sizeof t.c.a || o + l > sizeof t.c.a)
l = 0;
  else
__builtin_memcpy (e, t.c.a + o, l);
}

If this warning would be done during vrp2 when there are still asserts
available rather than in a separate pass right after it, or if it used evrp
analyzer, guess it could easily find out from the guarding condition that the
range is narrower.
But even if it doesn't, I think we shouldn't warn even for:
void
bar (struct D *s)
{
  struct C t;
  unsigned char *e = s->e + 64;
  unsigned int l = s->f;
  __SIZE_TYPE__ o = s->g;
  if (o > 512)
o -= 512;
  o -= 204;
  __builtin_memcpy (e, t.c.a + o, l);
}

  # RANGE ~[18446744073709550900, 18446744073709551411]
  o_10 = o_3 + 18446744073709551412;
  # RANGE [0, 4294967295] NONZERO 4294967295
  _1 = (long unsigned int) l_7;
  _2 = &t.D.1913.c.a + o_10;
  __builtin_memcpy (e_5, _2, _1);

we should treat at least anti-ranges where both min and max are completely
outside of the bounds of the object as effectively VARYING, it doesn't tell us
any interesting information.

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-12-05
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please provide preprocessed source as requested.

发 ^136^6247^6541^票

[leciu]

灿

[Bug target/87288] [8 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.2.1
 Resolution|--- |FIXED

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

[Bug target/87288] [8 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Wed Dec  5 12:19:32 2018
New Revision: 266822

URL: https://gcc.gnu.org/viewcvs?rev=266822&root=gcc&view=rev
Log:
2018-12-05  Richard Biener  

Backport from mainline
2018-09-20  Richard Sandiford  

PR tree-optimization/87288
* tree-vect-loop.c (vect_analyze_loop_2): Take PEELING_FOR_GAPS
into account when determining PEELING_FOR_NITERS.

* gcc.dg/vect/pr87288-1.c: New test.
* gcc.dg/vect/pr87288-2.c: Likewise,
* gcc.dg/vect/pr87288-3.c: Likewise.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr87288-1.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr87288-2.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr87288-3.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-vect-loop.c

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

--- Comment #2 from Richard Biener  ---
This isn't about NULL pointers.  &link_a->map_link is never NULL unless link_a
is a NULL pointer and map_link is the first member.  Thus GCC preserves the
check
with

struct X { int i; };

int foo (struct X *p)
{
  return &p->i == (void *)0;
}

I suspect your hlist_entry et al have a returns_nonnull attribute or so?

[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> Adjusted testcase that fails also with -m64:
> struct A { unsigned char a[84]; };
> struct B { unsigned char b[216]; };
> struct C { union { struct A c; struct B d; }; };
> struct D { unsigned char e[65536]; unsigned int f; __SIZE_TYPE__ g; };
> 
> void
> foo (struct D *s)
> {
>   struct C t;
>   unsigned char *e = s->e + 64;
>   unsigned int l = s->f;
>   __SIZE_TYPE__ o = s->g;
>   if (o > 512)
> o -= 512;
>   o -= 204;
>   if (o > sizeof t.c.a || o + l > sizeof t.c.a)
> l = 0;
>   else
> __builtin_memcpy (e, t.c.a + o, l);
> }
> 
> If this warning would be done during vrp2 when there are still asserts
> available rather than in a separate pass right after it, or if it used evrp
> analyzer, guess it could easily find out from the guarding condition that
> the range is narrower.
> But even if it doesn't, I think we shouldn't warn even for:
> void
> bar (struct D *s)
> {
>   struct C t;
>   unsigned char *e = s->e + 64;
>   unsigned int l = s->f;
>   __SIZE_TYPE__ o = s->g;
>   if (o > 512)
> o -= 512;
>   o -= 204;
>   __builtin_memcpy (e, t.c.a + o, l);
> }
> 
>   # RANGE ~[18446744073709550900, 18446744073709551411]
>   o_10 = o_3 + 18446744073709551412;
>   # RANGE [0, 4294967295] NONZERO 4294967295
>   _1 = (long unsigned int) l_7;
>   _2 = &t.D.1913.c.a + o_10;
>   __builtin_memcpy (e_5, _2, _1);
> 
> we should treat at least anti-ranges where both min and max are completely
> outside of the bounds of the object as effectively VARYING, it doesn't tell
> us any interesting information.

It tells us that the index is always out-of-bounds in case one is above
and one is below the range of valid values.  But yes, the quality
of the diagnostic is lacking.

Note we never reported ranges that overlap the valid indexes and the cited
anti-range above definitely does.

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[pbutsykin at virtuozzo dot com]

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

--- Comment #3 from Pavel  ---
Created attachment 45160
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45160&action=edit
preprocessed source

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[pbutsykin at virtuozzo dot com]

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

--- Comment #4 from Pavel  ---
Jonathan, sorry, attached.


Richard,

I forgot to show the structures:

struct kmapset_map {
struct kref kref;
unsignedsize;
struct kmapset_set  *set;
unsigned long   default_value;
unsigned long   hash;
struct hlist_head   links;
union {
struct rb_node  node;
struct rcu_head rcu_head;
};
};

struct kmapset_link {
struct kmapset_map  *map;
struct kmapset_key  *key;
unsigned long   value;
struct hlist_node   map_link;
union {
struct hlist_node   key_link;
struct rcu_head rcu_head;
};
};



Actually link_a is'n NULL, because map_link isn't the first member and
hlist_entry is just container_of:
#define hlist_entry(ptr, type, member) container_of(ptr,type,member)

"In the case when map_a->links.first is NULL, then link_a will be equal to
(NULL - 24) and expression &((struct kmapset_link *)(NULL - 24))->map_link will
refer to NULL."

[Bug c++/87571] [8/9 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
ICE started with r255780.

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[pbutsykin at virtuozzo dot com]

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

--- Comment #5 from Pavel  ---
Jonathan, sorry, attached.


Richard,

I forgot to show the structures:

struct kmapset_map {
struct kref kref;
unsignedsize;
struct kmapset_set  *set;
unsigned long   default_value;
unsigned long   hash;
struct hlist_head   links;
union {
struct rb_node  node;
struct rcu_head rcu_head;
};
};

struct kmapset_link {
struct kmapset_map  *map;
struct kmapset_key  *key;
unsigned long   value;
struct hlist_node   map_link;
union {
struct hlist_node   key_link;
struct rcu_head rcu_head;
};
};



Actually link_a is'n NULL, because map_link isn't the first member and
hlist_entry is just container_of:
#define hlist_entry(ptr, type, member) container_of(ptr,type,member)

"In the case when map_a->links.first is NULL, then link_a will be equal to
(NULL - 24) and expression &((struct kmapset_link *)(NULL - 24))->map_link will
refer to NULL."

[Bug libfortran/87048] [9 Regression] array_constructor_8.f90 failure on armeb

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Has there been any analysis why it fails?  Is it really a library issue, or
miscompiled library, something else?  The testcase doesn't seem to use
asynchronous keyword anywhere, so it is unclear why that commit would make any
difference.

[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018

[mcccs at gmx dot com]

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

MCCCS  changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #5 from MCCCS  ---
*** Bug 88353 has been marked as a duplicate of this bug. ***

[Bug target/88353] AVX512 instructions on macOS using Xcode Clang's assembler needs extra flags

[mcccs at gmx dot com]

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

MCCCS  changed:

   What|Removed |Added

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

--- Comment #2 from MCCCS  ---
Duplicate of 86393

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

[Bug middle-end/64242] Longjmp expansion incorrect

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||ro at gcc dot gnu.org

--- Comment #20 from Rainer Orth  ---
The new testcase also FAILs on sparc-sun-solaris2.11 (both 32 and 64-bit):

+FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr64242.c   -O2 -flto  execution test
+FAIL: gcc.c-torture/execute/pr64242.c   -O2 -flto -flto-partition=none 
execution test
+FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x0008 in ?? ()
(gdb) where
#0  0x0008 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Single-stepping, I find that this happens at the very end of main:

1: x/i $pc
=> 0x10de4 :  return  %i7 + 8
(gdb) 
0x00010de8 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/pr64242.c:50
50return 0;
1: x/i $pc
=> 0x10de8 :  nop 
(gdb) 
0x0008 in ?? ()
1: x/i $pc
=> 0x8: 

Obviously the stack is corrupted beyond repair.  I tried to avoid this by
replacing the return 0 with exit (0) to no avail.

The original testcase (before Jakub's patch) would abort instead:

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec7e044 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfec7e044 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfebb9898 in raise () from /lib/libc.so.1
#2  0xfeb8b1d0 in abort () from /lib/libc.so.1
#3  0x00010ce8 in main () at /homes/ro/pr64242.c:27

[Bug c/85870] [7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Reduced testcase that still ICEs in patch form:
--- gcc/testsuite/gcc.dg/lto/pr85870_0.c.jj 2018-12-05 14:30:47.506208171
+0100
+++ gcc/testsuite/gcc.dg/lto/pr85870_0.c2018-12-05 14:29:15.468725392
+0100
@@ -0,0 +1,34 @@
+/* PR c/85870 */
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -flto -O2 } } } */
+
+typedef struct abc_s {
+  char a1;
+  short a2;
+  unsigned int a3;
+  unsigned int a4;
+} abc;
+
+typedef struct xyz_s {
+ unsigned x1;
+ unsigned x2;
+ abc *x3;
+} xyz;
+
+extern xyz XYZ[3];
+static const abc Arr1[]={
+   {0,0,0xdeadbeaf,0xbeefdead} ,
+#line 1040
+{0,0,0xdeadbeaf,0xbeefdead} };
+
+void init_xyz_0() {
+  XYZ[0].x1=975753;
+  XYZ[0].x2=1024;
+  XYZ[0].x3=(abc *)Arr1;
+
+}
+
+int
+main ()
+{
+}
--- gcc/testsuite/gcc.dg/lto/pr85870_1.c.jj 2018-12-05 14:30:53.269113163
+0100
+++ gcc/testsuite/gcc.dg/lto/pr85870_1.c2018-12-05 14:29:22.613607607
+0100
@@ -0,0 +1,27 @@
+typedef struct abc_s {
+  char a1;
+  short a2;
+  unsigned int a3;
+  unsigned int a4;
+} abc;
+
+
+typedef struct xyz_s {
+ unsigned int x1;
+ unsigned int x2;
+ abc *x3;
+} xyz;
+
+
+extern xyz XYZ[3];
+static const abc Arr2[]={
+   {0,0,0xbeafdead,0xdeadbeef} ,
+#line 1048594
+   {0,0,0xbeafdead,0xdeadbeef} };
+
+void init_xyz_1() {
+  XYZ[1].x1=425753;
+  XYZ[1].x2=1048576;
+  XYZ[1].x3=(abc *)Arr2;
+
+}

[Bug c/85870] [7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Bet the line number is high enough that we jump over some threshold and stop
counting ranges or columns or whatever at that point.  David, can you please
have a look?

[Bug c++/88368] New: Improper ``use of deleted function''

[serge.guel...@telecom-bretagne.eu]

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

Bug ID: 88368
   Summary: Improper ``use of deleted function''
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: serge.guel...@telecom-bretagne.eu
  Target Milestone: ---

The following code fails to compile: https://godbolt.org/z/briQXa
Adding a `noexcept` specifier to the default constructor fixes the issue, but
it shouldn't be needed..

Clang compiles this code correctly, so does gcc 4.9. But gcc 7.3 doesn't, for
another reason.

[Bug c++/88368] Improper ``use of deleted function''

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
#include 
#include 

template
union trivial_helper {
T t;
};

template 
struct trait {
  static constexpr bool value =
std::is_copy_constructible>::value;
};

struct BlockFrequencyInfoImplBase {

  struct BlockNode {
int Index = 1;
BlockNode() = default;
  };

  static constexpr bool v = trait>::value; // <<
remove this line to remove the error

  void print() const {
BlockNode BB;
  }
};

Testcase included inline.  Used to be rejected e.g. in r21, from r216750
and before r250994 used to be rejected with a different error.

[Bug testsuite/88369] New: [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 88369
   Summary: [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org, schwab at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.*, ia64-suse-linux-gnu

Between 20180928 (r264685) and 20180929 (r264715), two tests started to regress
on SPARC and IA-64:
+FAIL: g++.dg/vect/pr33426-ivdep-2.cc  -std=c++11 (test for excess errors)
+FAIL: g++.dg/vect/pr33426-ivdep-2.cc  -std=c++14 (test for excess errors)
+FAIL: g++.dg/vect/pr33426-ivdep-2.cc  -std=c++98 (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc:12:3:
optimized:  loop versioned for vectorization to enhance alignment
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc:23:3:
optimized:  loop versioned for vectorization to enhance alignment

+FAIL: g++.dg/vect/pr33426-ivdep.cc  -std=c++11 (test for excess errors)
+FAIL: g++.dg/vect/pr33426-ivdep.cc  -std=c++14 (test for excess errors)
+FAIL: g++.dg/vect/pr33426-ivdep.cc  -std=c++98 (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/vect/pr33426-ivdep.cc:11:13:
optimized:  loop versioned for vectorization to enhance alignment

[Bug testsuite/88369] [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/88368] Improper ``use of deleted function''

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
r209907 is the first one that rejects it this way, before that the preprocessed
source I'm trying doesn't compile because of some __is_trivially_assignable
changes, so it is possible 4.9 accepted this with 4.9 headers.

[Bug libgomp/88370] New: acc_get_cuda_stream/acc_set_cuda_stream: acc_async_sync, acc_async_noval

[tschwinge at gcc dot gnu.org]

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

Bug ID: 88370
   Summary: acc_get_cuda_stream/acc_set_cuda_stream:
acc_async_sync, acc_async_noval
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Per my reading of the OpenACC specification (and I submitted to them a patch to
clarify that, ), it's valid
to call "acc_get_cuda_stream"/"acc_set_cuda_stream" also with "acc_async_sync",
"acc_async_noval" arguments, not just with the nonnegative values as currently
implemented.

This is also supported by secondary documentation, such as code examples, or
presentations, which especially makes use of
"acc_get_cuda_stream(acc_async_sync)".  For example:
,
or the PGI "OpenACC Getting Started Guide" (Version 2017) stating that "the
input argument is an async number or a pre-defined value such as
acc_async_sync".

This will need to be fixed on all release branches.

[Bug c++/88371] New: Gratuitous (?) warning regarding an implicit conversion in pointer arithmetic

[eyalroz at technion dot ac.il]

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

Bug ID: 88371
   Summary: Gratuitous (?) warning regarding an implicit
conversion in pointer arithmetic
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

See: https://godbolt.org/z/tYn9SX
for a live example and comparison with clang

Se: https://stackoverflow.com/q/53628998/1593077
for the question motivating this bug report.

---

Consider the following program:

#include 

template 
struct wrapper {
T t;
operator T() const { return t; }
T get() const { return t; }
};

int main() {
int a[10];
int* x { a } ;
wrapper y1{2};
wrapper y2{2};
wrapper y3{2};

std::cout << (x + y1) << '\n';
std::cout << (x + y2) << '\n';
std::cout << (x + y3) << '\n'; // this triggers a warning
std::cout << (x + y3.get()) << '\n';
}

When compiling it (with g++ 8.2.0) with -std=c++2a -Wsign-conversion we get:

a.cpp: In function ‘int main()’:
a.cpp:20:23: warning: conversion to ‘long int’ from ‘long unsigned int’ may
change the sign of the result [-Wsign-conversion]
 std::cout << (x + y3) << '\n'; // this triggers a warning
   ^~
As far as I can tell, both the third and fourth line should trigger a warning,
or none of them should.

Also, a comment on the Stackoverflow page suggested this clause:
http://eel.is/c++draft/over.match.oper#9

may be relevant here.

[Bug testsuite/88208] new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Wed Dec  5 14:16:08 2018
New Revision: 266825

URL: https://gcc.gnu.org/viewcvs?rev=266825&root=gcc&view=rev
Log:
Provide SPARCv9 MAXALIGN in gcc.target/sparc/attr-aligned.c (PR
testsuite/88208)

PR testsuite/88208
* gcc.target/sparc/attr-aligned.c (MAXALIGN) [__sparcv9 ||
__arch64__]: Define.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sparc/attr-aligned.c

[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-05
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug c++/88368] Improper ``use of deleted function''

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Yes, 4.9 accepts it, but so does 5.5 which contains r209907

[Bug c/88372] New: alloc_size attribute is ignored on function pointers

[arichardson at FreeBSD dot org]

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

Bug ID: 88372
   Summary: alloc_size attribute is ignored on function pointers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arichardson at FreeBSD dot org
  Target Milestone: ---

In the following example code __builtin_object_size does not return 100 when
used on result of a call to a function pointer. See
https://godbolt.org/z/MI5k_m :
```
void *malloc_function(int) __attribute__((alloc_size(1)));
void* (*malloc_function_pointer)(int) __attribute__((alloc_size(1))) =
malloc_function;

unsigned long int foo(void) {
  void *ptr = malloc_function_pointer(100);
  return __builtin_object_size(ptr, 0);
}

unsigned long int bar(void) {
  void *ptr = malloc_function(100);
  return __builtin_object_size(ptr, 0);
}
```

I have been working on supporting alloc_size on function pointers in clang
(https://reviews.llvm.org/D55212) and was wondering if GCC might also support
this in the future.
Is i acceptable if clang also accepts [[gnu::alloc_size(N)]] on function
pointers or would this be incompatible with potential future GCC changes?

[Bug c++/88373] New: parse error in template argument list when using bitwise not with -std=c++2a switch

[emmanuel.le-tr...@cnrs-orleans.fr]

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

Bug ID: 88373
   Summary: parse error in template argument list when using
bitwise not with -std=c++2a switch
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emmanuel.le-tr...@cnrs-orleans.fr
  Target Milestone: ---

Using the bitwise not in a non-type template argument produces a parse error
with the -std=c++2a switch on. It works fine without the switch. It also works
with the switch on in version 8.2.1.

$ cat bug_3.cpp 
template 
constexpr T value = T {};

template 
struct S {};

using U = S >;

$ g++-9 -c bug_3.cpp && echo OK
   
  OK

$ g++-9 -c -std=c++2a bug_3.cpp 
bug_3.cpp:7:15: error: parse error in template argument list
7 | using U = S >;
  |   ^


g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/home/manu/system/opt/gcc-9/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9/configure --prefix=/home/manu/system/opt/gcc-9
--program-suffix=-9
Thread model: posix
gcc version 9.0.0 20181204 (experimental) (GCC)

[Bug c++/88373] parse error in template argument list when using bitwise not with -std=c++2a switch

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-05
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Yikes, started with r265734.

[Bug c++/88374] New: crash when stepping into for loop where iterators are created and compared with gdb

[bob.steagall.cpp at gmail dot com]

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

Bug ID: 88374
   Summary: crash when stepping into for loop where iterators are
created and compared with gdb
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bob.steagall.cpp at gmail dot com
  Target Milestone: ---

Created attachment 45161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45161&action=edit
preprocessed source file to demonstrate problem

Consider the following code:


#include 
#include 

struct TS
{
std::atomic mPtr;
};

int main()
{
std::vector test(10);
volatile inti = 0;

for (auto iter = test.begin();  iter != test.end();  ++iter)
{
++i;
}
return 0;
}


GDB 7.11 and 8.2 both crash when repeatedly stepping into the for loop on line
14 when compiled with gcc 8.2 and -std=c++17.

The problem appears to be related to the combination of std::atomic as an
element type AND the compilation flag -std=c++17.

If I change the flag to -std=c++14, gdb does not crash, and I can step thru the
iterator instantiations and comparisons as expected.  Also, if I change the
pointer type to void*, the crash does not occur, and stepping works correctly.  

I'm not sure if this is a GDB problem or a g++ codegen problem (or both?), so
I'm filing this report with both products.

Thanks,
--Bob


To reproduce:

$ g++ -std=c++17 -Wall -Wextra -g -O0 test_dbg.cpp -o test_dbg
$ gdb test_dbg

inside of gdb:

(gdb) b 12
(gdb) r
(gdb) s
(gdb) s
(gdb) s
(gdb) s
(gdb) s
(gdb) s
 { gdb crashes with segv }


The following is a transcript from such a session:

Reading symbols from test_dbg...done.
(gdb) b 12
Breakpoint 1 at 0x400738: file test_dbg.cpp, line 12.
(gdb) r
Starting program: /space/tmp/test_dbg

Breakpoint 1, main () at test_dbg.cpp:12
(gdb) s
(gdb) s
std::vector >::begin (this=0x7fffd7a0)
at /usr/local/gcc/8.2.0/include/c++/8.2.0/bits/stl_vector.h:699
(gdb) s
__gnu_cxx::__normal_iterator >
>::__normal_iterator (
this=0x7fffd778, __i=@0x7fffd7a0: 0x614c20)
at /usr/local/gcc/8.2.0/include/c++/8.2.0/bits/stl_iterator.h:781
(gdb) s
std::vector >::end (this=0x7fffd7a0)
at /usr/local/gcc/8.2.0/include/c++/8.2.0/bits/stl_vector.h:717
(gdb) s
__gnu_cxx::__normal_iterator >
>::__normal_iterator (
this=0x7fffd778, __i=@0x7fffd7a8: 0x614c70)
at /usr/local/gcc/8.2.0/include/c++/8.2.0/bits/stl_iterator.h:781
(gdb) s
Segmentation fault (core dumped)

=
Here are the tool specs:

$ gdb -v
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc. ...


$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.5 LTS
Release:16.04
Codename:   xenia


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc/8.2.0/libexec/gcc/x86_64-kewb-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-kewb-linux-gnu
Configured with: /space/zbuild/gcc-builder/gcc-8.2.0/configure -v
--with-pkgversion='KEWB Computing Build' --prefix=/usr/local/gcc/8.2.0
--program-suffix= --enable-tls --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
--enable-lto --enable-bootstrap --disable-nls --disable-multilib
--disable-install-libiberty --disable-werror --with-system-zlib
Thread model: posix
gcc version 8.2.0 (KEWB Computing Build) 

$ g++ -v -save-temps -std=c++17 -Wall -Wextra -g -O0 test_dbg.cpp -o test_dbg
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc/8.2.0/libexec/gcc/x86_64-kewb-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-kewb-linux-gnu
Configured with: /space/zbuild/gcc-builder/gcc-8.2.0/configure -v
--with-pkgversion='KEWB Computing Build' --prefix=/usr/local/gcc/8.2.0
--program-suffix= --enable-tls --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
--enable-lto --enable-bootstrap --disable-nls --disable-multilib
--disable-install-libiberty --disable-werror --with-system-zlib
Thread model: posix
gcc version 8.2.0 (KEWB Computing Build) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-Wall' '-Wextra' '-g'
'-O0' '-o' 'test_dbg' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc/8.2.0/libexec/gcc/x86_64-kewb-linux-gnu/8.2.0/cc1plus -E -quiet
-v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test_dbg.cpp -mtune=generic
-march=x86-64 -std=c++17 -Wall -Wextra -g -fworking-directory -O0
-fpch-preprocess -o test_dbg.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc/8.2.0/lib/gcc/x86_64-kewb-linux-gnu/8.2.0/../../../../x86_64-kewb-linux-gnu/include"
#include "..." search starts here:
#include <...> search sta

[Bug c++/88373] [9 Regression] parse error in template argument list when using bitwise not with -std=c++2a switch

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|parse error in template |[9 Regression] parse error
   |argument list when using|in template argument list
   |bitwise not with -std=c++2a |when using bitwise not with
   |switch  |-std=c++2a switch

[Bug c++/88368] [7/8/9 Regression] Improper ``use of deleted function''

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Target Milestone|--- |7.4
Summary|Improper ``use of deleted   |[7/8/9 Regression] Improper
   |function''  |``use of deleted function''

[Bug middle-end/63184] [7/8/9 Regression] Fails to simplify comparison

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.1.0
 Resolution|--- |FIXED
   Target Milestone|9.0 |6.0

--- Comment #12 from Richard Biener  ---
It happens that we optimize both cases now (with optimization only).  Would be
still a regression vs. GCC 4.7 at -O0 but IMHO we shouldn't care about
optimizing this at -O0.

Thus fixed.

I'll add the testcases.

[Bug c++/88375] New: Vague source location for bad initialization

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 88375
   Summary: Vague source location for bad initialization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Given this C++11 code:

enum struct a : int {
  one, two
};

struct foo {
  int e1, e2;
  a e3;
} arr[] = {
  { 1, 2, a::one },
  { 3, a::two },
  { 4, 5, a::two }
};

g++ trunk emits the unhelpfully vague:

/tmp/test.cc:12:1: error: cannot convert ‘a’ to ‘int’ in initialization
   12 | };
  | ^

(via an "error", with input_location at the final close-paren)

whereas clang identifies where the problem is:

/tmp/test.cc:10:8: error: cannot initialize a member subobject of type 'int'
with an rvalue of type 'a'
  { 3, a::two },
   ^~
1 error generated.

Similar to e.g. PR 45963, but might well be a different underlying issue.

[Bug middle-end/63184] [7/8/9 Regression] Fails to simplify comparison

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Wed Dec  5 14:55:59 2018
New Revision: 266827

URL: https://gcc.gnu.org/viewcvs?rev=266827&root=gcc&view=rev
Log:
2018-12-05  Richard Biener  

PR middle-end/63184
* c-c++-common/pr19807-2.c: New testcase.
* c-c++-common/pr19807-3.c: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/pr19807-2.c
trunk/gcc/testsuite/c-c++-common/pr19807-3.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-05
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to MCCCS from comment #5)
> *** Bug 88353 has been marked as a duplicate of this bug. ***

Taking the dup as confirmation.

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha  ---
(In reply to Richard Biener from comment #8)
> Fixed?

Yes, it fixes all three today's testcases, thanks.

[Bug tree-optimization/88064] [9 Regression] Incorrect vectorizer over_widening pattern handling

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Dec  5 15:53:03 2018
New Revision: 266829

URL: https://gcc.gnu.org/viewcvs?rev=266829&root=gcc&view=rev
Log:
Use unsigned arithmetic for demoted vector plus/minus/mult (PR 88064)

As Jakub pointed out, if we narrow a plus, minus or mult operation based
on the number of bits that consumers need, we have to convert a signed
operation to an unsigned one in order to avoid new undefined behaviour.
This patch does that and generalises vect_convert_input and
vect_recog_over_widening_pattern to cope with the extra casts.
(The changes to both functions are covered by existing tests.)

2018-12-03  Richard Sandiford  

gcc/
PR tree-optimization/88064
* tree-vect-patterns.c (vect_convert_input): Convert the result of
an existing cast if it has the right width but the wrong sign.
Do not test the signedness of the required result when
considering whether to split an existing cast; instead split to
a type with the same signedness as the source of the cast, then
convert it to the opposite signedness where necessary.
(vect_recog_over_widening_pattern): Handle sign changes between
the final PLUS_EXPR and the RSHIFT_EXPR.
(vect_recog_average_pattern): Use an unsigned operation when
truncating an addition, subtraction or multiplication.  Cast the
result back to the "real" signedness before promoting.

gcc/testsuite/
PR tree-optimization/88064
* gcc.dg/vect/vect-over-widen-23.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-23.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #7 from Alexandre Oliva  ---
Created attachment 45162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45162&action=edit
candidate patch

This patch fixes the additional problem.  We have a (...) ctor in a base class,
reexported with an access declaration.  We try to do_build_copy_constructor
from that, but then FUNCTION_FIRST_USER_PARM is NULL, and we attempt to
dereference it unconditionally, since copy ctors normally have at least one
user parm.  Should this one even match as a copy ctor?  Checking...

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #19 from Rainer Orth  ---
Created attachment 45163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45163&action=edit
Preliminary patch for regular sparc output patter test failures

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from Eric Botcazou  ---
> (> These are often just off-by-one errors in the line numbers; I believe I
>> have a patch around somewhere to fix at least some of those...
>
> OK, I see, a bit annoying in the test results though.

Very true.  The attached patch allows for the line number variations
I'm seeing in the failing sparc output pattern tests.  I've no idea yet
if something like this is acceptable, though.

This leaves me with the following output patter failures (on Solaris
11.5 Beta):

  c-c++-common/asan/global-overflow-1.c
AddressSanitizer: nested bug in the same thread, aborting.
  c-c++-common/asan/pr62089.c
AddressSanitizer: nested bug in the same thread, aborting.
  c-c++-common/asan/strlen-overflow-1.c
AddressSanitizer: nested bug in the same thread, aborting.
  g++.dg/asan/deep-tail-call-1.C
AddressSanitizer: nested bug in the same thread, aborting.
  g++.dg/asan/function-argument-3.C
empty output at -O0
  gcc.dg/asan/use-after-scope-5.c
AddressSanitizer:DEADLYSIGNAL (SIGBUS), a recent regression to
be dealt with separately

and of course the execution failures.

[Bug tree-optimization/85726] [7/8/9 Regression] div C1 to div C2 match.pd suboptimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 45164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45164&action=edit
gcc9-pr85726.patch

Untested fix.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
I think it is important to find out why there are those differences in line
numbers.  Is libbacktrace broken on Solaris, or not used at all, something
different?

[Bug c++/72842] non-type template-parameter of type void

[wjwray at gmail dot com]

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

Will Wray  changed:

   What|Removed |Added

 CC||wjwray at gmail dot com

--- Comment #8 from Will Wray  ---
Reporting a (non-variadic) case here in which gcc incorrectly accepts void,
and now also accepts class types not satisfying the requirements for a
class type non-type template parameter (now they are implemented on trunk).

https://godbolt.org/z/fjFzMm

template  struct TT;
template  class TT> struct TTT {};

TTT x;

GCC accepts the variable declaration
(or explicit instantiationtemplate struct TTT; )

Clang rejects with:

error: a non-type template parameter cannot have type 'void'
template  class TT> struct TTT {};
 ^
This is easy to CONFIRM via the compiler explorer link above.

Also
With class-type non-type template parameters now in gcc trunk
GCC incorrectly accepts this:

struct NotNTTP { int mutable i; };

TTT c;

https://godbolt.org/z/jfioyB

(The compiler explorer link implements a constraint to test
 if a type fits the requirements of a non-type template parameter,
 otherwise hard to implement without relying on default construction)

Perhaps this should be a new bug as the title is specific to void.

[Bug testsuite/88369] [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45165&action=edit
gcc9-pr88369.patch

Only those two and not the 4 other ones?
Does the following patch help?

[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
"target pdp11*-*-*" is the _comment_ argument to dg-error here as written;
that's why it is displayed in the summary like that, too.  I don't see why
it doesn't fail on most systems though, hrm.

FWIW, I'll update gcc110 to centos 7.6 some time soon (from 7.4).

[Bug c++/88320] GCC suggests variables that don't exist yet

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-05
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from David Malcolm  ---
Am testing a candidate patch for this.

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The dumps aren't very readable with all the instrumentations.
Anyway, if I look at -fdump-tree-all-lineno dumps, I see:
  [/root/src/vzkernel/lib//kmapset.c:47:8] goto ; [100.00%]
...
   [local count: 2396963771]:
  # link_a_99 = PHI <[/root/src/vzkernel/lib//kmapset.c:43:9] _96(13),
[/root/src/vzkernel/lib//kmapset.c:52:10] _115(18)>
  # link_b_101 = PHI <[/root/src/vzkernel/lib//kmapset.c:45:9] _98(13),
[/root/src/vzkernel/lib//kmapset.c:54:10] _117(18)>
  # DEBUG link_b => link_b_101
  # DEBUG link_a => link_a_99
  [/root/src/vzkernel/lib//kmapset.c:47:9] _118 =
[/root/src/vzkernel/lib//kmapset.c:47:9]
&[/root/src/vzkernel/lib//kmapset.c:47:16] link_a_99->ma
p_link;
  [/root/src/vzkernel/lib//kmapset.c:47:8] if (_118 != 0B)
goto ; [96.34%]
  else
goto ; [3.66%]

still in thread1 dump, but not in vrp1 dump.
In -fdump-tree-vrp1-lineno-details-alias dump I see:
Visiting statement:
[/root/src/vzkernel/lib//kmapset.c:47:9] # PT = nonlocal escaped null
_118 = [/root/src/vzkernel/lib//kmapset.c:47:9]
&[/root/src/vzkernel/lib//kmapset.c:47:16] link_a_99->map_link;
Found new range for _118: struct hlist_node * ~[0B, 0B]

[Bug c++/88320] GCC suggests variables that don't exist yet

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
FWIW, clang trunk currently gives the same erroneous suggestion:

:4:19: error: use of undeclared identifier 'aresults'; did you mean
'aresult'?
int aresult = aresults +1;
  ^~~~
  aresult
:4:9: note: 'aresult' declared here
int aresult = aresults +1;
^
1 error generated.

[Bug c++/88362] attribute aligned silently ignored on C++ references

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
It's not very clear to me what an aligned attribute on a reference, or a 
check of the alignment of a reference, should mean anyway.

Note that in some places, [[]]-style attributes appertain to different 
syntactic constructs than __attribute__ appertains in the same place (and 
in any case, what [[]] appertains to is more precisely defined, whereas 
what __attribute__ appertains to is what keeps compatibility with existing 
code).

C++ alignas can be applied to references, but I don't see anything in 
[dcl.align] to clarify what it means there - does it align the referenced 
type (so that it's only valid to bind the reference to an object that 
itself is sufficiently aligned), or something else?

[Bug fortran/88357] ICE in parse_associate, at fortran/parse.c:4568

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

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

--- Comment #4 from G. Steinmetz  ---

Thanks for working on these issues.

[Bug fortran/88376] New: ICE in is_illegal_recursion, at fortran/resolve.c:1689

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

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

Bug ID: 88376
   Summary: ICE in is_illegal_recursion, at fortran/resolve.c:1689
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code down to gfortran-6 :


$ cat z1.f90
module m
   integer :: n
contains
   subroutine s
  character(n(3)) :: c
   end
end


$ gfortran-5 -c z1.f90
z1.f90:5:16:

   character(n(3)) :: c
1
Error: 'n' at (1) is not a function


$ gfortran-9-20181202 -c z1.f90
f951: internal compiler error: in is_illegal_recursion, at
fortran/resolve.c:1689
0x67f5e9 is_illegal_recursion
../../gcc/fortran/resolve.c:1689
0x690e3e resolve_function
../../gcc/fortran/resolve.c:3296
0x68dcad gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6832
0x62140f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2953
0x60771d gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:3288
0x60ddc7 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3931
0x60eeec gfc_match_data_decl()
../../gcc/fortran/decl.c:5853
0x66f6e3 match_word
../../gcc/fortran/parse.c:65
0x66f6e3 decode_statement
../../gcc/fortran/parse.c:376
0x67118a next_free
../../gcc/fortran/parse.c:1235
0x67118a next_statement
../../gcc/fortran/parse.c:1467
0x6734f4 parse_spec
../../gcc/fortran/parse.c:3675
0x67526c parse_progunit
../../gcc/fortran/parse.c:5674
0x675651 parse_contained
../../gcc/fortran/parse.c:5575
0x676415 parse_module
../../gcc/fortran/parse.c:5947
0x676747 gfc_parse_file()
../../gcc/fortran/parse.c:6250
0x6bf5ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/88377] New: ICE in gfc_omp_clause_copy_ctor, at fortran/trans-openmp.c:614

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

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

Bug ID: 88377
   Summary: ICE in gfc_omp_clause_copy_ctor, at
fortran/trans-openmp.c:614
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gfortran-5 :


$ cat z1.f90
program p
   call s(3)
contains
   subroutine s(n)
  integer :: n
  character(n), allocatable :: x
  x = 'abc'
  !$omp task
  print *, x, (x == 'abc')
  !$omp end task
   end
end


$ gfortran-9-20181202 z1.f90 -static-libgfortran
$ a.out
 abc T


$ gfortran-9-20181202 -c z1.f90 -fopenmp
during GIMPLE pass: omplower
z1.f90:8:0:

8 |   !$omp task
  |
internal compiler error: Segmentation fault
0xb2ec9f crash_signal
../../gcc/toplev.c:326
0x72193c gfc_omp_clause_copy_ctor(tree_node*, tree_node*, tree_node*)
../../gcc/fortran/trans-openmp.c:614
0xa3b08f lower_rec_input_clauses
../../gcc/omp-low.c:4880
0xa3eb36 lower_omp_taskreg
../../gcc/omp-low.c:8965
0xa346b6 lower_omp_1
../../gcc/omp-low.c:10405
0xa346b6 lower_omp
../../gcc/omp-low.c:10495
0xa35529 lower_omp_1
../../gcc/omp-low.c:10331
0xa35529 lower_omp
../../gcc/omp-low.c:10495
0xa3544e lower_omp_1
../../gcc/omp-low.c:10339
0xa3544e lower_omp
../../gcc/omp-low.c:10495
0xa3929b execute_lower_omp
../../gcc/omp-low.c:10537
0xa3929b execute
../../gcc/omp-low.c:10584

[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728

[pkoning at gcc dot gnu.org]

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

--- Comment #9 from pkoning at gcc dot gnu.org ---
Comment?  I thought the comment is the null string after the regexp to match. 
Should it read { target { pdp11-*-* } } with the extra braces?
Other examples show up both with the braces and without, but the example in the
documentation is written without.

[Bug c++/88320] GCC suggests variables that don't exist yet

[jg at jguk dot org]

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

--- Comment #9 from Jonny Grant  ---
(In reply to David Malcolm from comment #8)
> FWIW, clang trunk currently gives the same erroneous suggestion:
> 
> :4:19: error: use of undeclared identifier 'aresults'; did you mean
> 'aresult'?
> int aresult = aresults +1;
>   ^~~~
>   aresult
> :4:9: note: 'aresult' declared here
> int aresult = aresults +1;
> ^
> 1 error generated.

Being better than Clang is always a plus.

[Bug c/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
In GCC 8 we had:
  else if (code == POINTER_PLUS_EXPR)
{
  /* For pointer types, we are really only interested in asserting
 whether the expression evaluates to non-NULL.  */
  if (range_is_nonnull (&vr0) || range_is_nonnull (&vr1))
set_value_range_to_nonnull (vr, expr_type);
and now we have:
  else if (code == POINTER_PLUS_EXPR)
{
  /* For pointer types, we are really only interested in asserting
 whether the expression evaluates to non-NULL.  */
  if (!range_includes_zero_p (&vr0)
  || !range_includes_zero_p (&vr1))
vr->set_nonnull (expr_type);
I think range_is_nonnull (&vr1) was pretty much never true before, that needs
vr1 (which is the integral offset) to be exactly ~[0, 0]; here we had constant
offset there (-24UL).
So, if the UB stuff kernel is doing is meant to be considered ok for
-fno-delete-null-pointer-checks, we either need to guard this condition on
flag_delete_null_pointer_checks, or think of what we want to support and what
we don't.  E.g. do we want to treat pointer wrapping as UB?  A problem is that
POINTER_PLUS_EXPR last argument is unsigned sizetype, so negative offsets
appear as very large positive ones.  So, perhaps do we want to conclude that if
vr0 doesn't include zero and vr1 is guaranteed not to have most significant bit
set (i.e. appear as negative), then the result is nonnull, otherwise varying?
Of course for flag_delete_null_pointer_checks do what we do right now.

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva  ---
So, no, it's not a copy ctor, but apparently we're reusing the logic that
synthesizes them for other non-default ctors.

[Bug c/87615] Possible excessive compile time with -O2

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
It's actually, ipa_polymorphic_call_context::get_dynamic_type that causes
problems here.  I'll prepare a patch.

[Bug c++/88362] attribute aligned silently ignored on C++ references

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I think the attribute on references needs to work the same way as on pointers
so that we get consistent behavior for reference members.  __alignof__ should
return the corresponding alignment.  For example, in the following all three
members are 32-byte aligned as expected:

  struct S {
__attribute__ ((aligned (32))) int i;
__attribute__ ((aligned (32))) int *p;
__attribute__ ((aligned (32))) int &r;
  };

  S s = { 0, &s.i, s.i };

but in the following the last assertion fails with GCC (it passes with Clang):

  static_assert (__alignof__ (s.i) == 32);
  static_assert (__alignof__ (s.p) == 32);
  static_assert (__alignof__ (s.r) == 32);