[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on powerpc-apple-darwin9

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51059

--- Comment #1 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-10 
07:38:26 UTC ---
There's something strange about the semantics of weak  inline on darwin (or a
bug in the darwin linker?).

Here's the bits of the testcase:

extern int __attribute__ ((weak)) Foo ();

extern __inline int Foo ()
{
  return 0; /* count(-) */
}

The program doesn't call 'Foo', but uses its address.  The intent is to make
sure that there's no body of 'Foo' emitted in the executable (or at least
coverage data indicates there's no body).  As the external declaration of 'Foo'
is weak, I expect the value of the 'Foo' symbol to be 0.

So, I think this test is either invalid for Darwin (and should be skipped), or
exposing an orthogonal bug (and should be xfailed).  Someone who knows darwin
better than me needs to comment.

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51059

--- Comment #6 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-11 
20:11:31 UTC ---
great, who wants to commit the fix?

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-13 
10:08:52 UTC ---
hm, at a wild guess it looks like  -fvisibility-inlines-hidden is not being
taken into consideration in my patch.  If you build without that option, does
it succeed?

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-15
 Ever Confirmed|0   |1

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113

--- Comment #9 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-20 
09:09:39 UTC ---
Author: nathan
Date: Sun Nov 20 09:09:34 2011
New Revision: 181524

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181524
Log:
PR gcov-profile/51113
* coverage.c (build_var): Propagate visibility for public decls.

testsuite/
* gcc.misc-tests/gcov-13.c: Check gcovpart-13b coverage
* gcc.misc-tests/gcov-16.c: New.
* gcc.misc-tests/gcov-17.c: New.
* g++.dg/gcov/gcov-8.C: New.
* g++.dg/gcov/gcov-9.C: New.
* g++.dg/gcov/gcov-10.C: New.

Added:
trunk/gcc/testsuite/g++.dg/gcov/gcov-10.C
trunk/gcc/testsuite/g++.dg/gcov/gcov-11.C
trunk/gcc/testsuite/g++.dg/gcov/gcov-8.C
trunk/gcc/testsuite/g++.dg/gcov/gcov-9.C
trunk/gcc/testsuite/gcc.misc-tests/gcov-16.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.misc-tests/gcov-13.c

[Bug gcov-profile/51297] [4.7 regressions] Many gcov tests FAIL on Tru64 UNIX, Solaris 8

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297

--- Comment #1 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-24 
18:30:40 UTC ---
The line numbers in the backtrace don't seem to correspond to current sources. 
for instance line 866 is the definition of find_source, not the location of one
of the two bsearch calls.

which of the two bsearch calls is blowing up?

this one:
 name_map = (name_map_t *)bsearch
(file_name, names, n_names, sizeof (*names), name_search);

or this one:
  name_map = (name_map_t *)bsearch
(canon, names, n_names, sizeof (*names), name_search);

What are the values being passed to the bsearch call?

Oh, I see that it appears the string being passed to 'find_source' is
unreadable:
#2  0x08056d88 in find_source (file_name=0x80a2f70 error reading variable)
at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:866

What does gcov-dump -lo tell you about the gcno file?

[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297

--- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-24 
19:08:24 UTC ---
the names being entered into the array are unique, so there is a total ordering
-- I think that's a red herring.  I think the problem is the string read from
the data file is corrupted in some way.  Is that clueful enough?

[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297

--- Comment #11 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-26 
21:44:26 UTC ---
Author: nathan
Date: Sat Nov 26 21:44:24 2011
New Revision: 181745

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181745
Log:
PR gcov-profile/51297
* gcov.c (main): Allocate initial names and sources arrays.
(find_source): Don't check for null name or source arrays here.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov.c

[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |nathan at gcc dot gnu.org
   |gnu.org |

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113

--- Comment #10 from Nathan Sidwell nathan at gcc dot gnu.org 2011-12-01 
19:58:55 UTC ---
Author: nathan
Date: Thu Dec  1 19:58:51 2011
New Revision: 181892

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181892
Log:
PR gcov-profile/51113
* coverage.c (build_var): Keep coverage variables static.

testsuite/
* lib/gcov.exp (verify-lines): Add support for xfailing.
(run-gcov): Likewise.
* gcc.misc-tests/gcov-13.c: Xfail weak function.
* gcc.misc-tests/gcov-16.c: Remove.
* gcc.misc-tests/gcov-17.c: Remove.
* g++.dg/gcov-8.C: Remove.
* g++.dg/gcov-9.C: Remove.
* g++.dg/gcovpart-12b.C: New.
* g++.dg/gcov-12.C: New.

Added:
trunk/gcc/testsuite/g++.dg/gcov/gcov-12.C
trunk/gcc/testsuite/g++.dg/gcov/gcovpart-12b.C
Removed:
trunk/gcc/testsuite/g++.dg/gcov/gcov-8.C
trunk/gcc/testsuite/g++.dg/gcov/gcov-9.C
trunk/gcc/testsuite/gcc.misc-tests/gcov-16.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.misc-tests/gcov-13.c
trunk/gcc/testsuite/lib/gcov.exp

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113

--- Comment #12 from Nathan Sidwell nathan at gcc dot gnu.org 2011-12-06 
07:25:47 UTC ---
Thanks for confirming.  I 'fixed' it by reverting part of the new feature set I
was implementing (hence the new xfail and removed testcases).  What's the
precedence here?  Should a new bug be opened for that reverted feature, should
I keep it in my head, or should this remain open?  I don't mind either way.

[Bug gcov-profile/51449] [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51449

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-07
 Ever Confirmed|0   |1

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org 2011-12-07 
20:35:18 UTC ---
Crud, not doing very well, am I?  Here's a reduced testcase:

template typename T struct TPL
{
  int Baz ();

  int Foo ()
  {
return Baz ();
  }
};

extern template struct TPLchar;

void Bar (TPLchar *ptr)
{
  ptr-Foo ();
}

nathan@cartagia:53./cc1plus -fprofile-arcs tpl.ii -Ofast
nathan@cartagia:53grep gcov0 tpl.s 
addl$1, __gcov0__Z3BarP3TPLIcE
adcl$0, __gcov0__Z3BarP3TPLIcE+4
addl$1, __gcov0__ZN3TPLIcE3FooEv
adcl$0, __gcov0__ZN3TPLIcE3FooEv+4
addl$1, __gcov0__ZN3TPLIcE3FooEv+8
adcl$0, __gcov0__ZN3TPLIcE3FooEv+12
addl$1, __gcov0__Z3BarP3TPLIcE+8
adcl$0, __gcov0__Z3BarP3TPLIcE+12
.local__gcov0__Z3BarP3TPLIcE
.comm__gcov0__Z3BarP3TPLIcE,16,8
.long__gcov0__Z3BarP3TPLIcE

Notice __gcov0__ZN3TPLIcE3FooEv is referenced but not defined.

[Bug gcov-profile/51361] [4.7 Regression] 471.omnetpp of SPEC2006 fails to build with -fprofile-generate

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51361

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org 2011-12-08 
07:11:58 UTC ---
I don't think it is -- that defect relates to __gcov0__FOO objects, this one
mentions the __gcov__FOO objects.  Also, that defect was apparently introduced
by an even more recent cleanup patch.

[Bug gcov-profile/51449] [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51449

--- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org 2011-12-10 
08:32:38 UTC ---
Author: nathan
Date: Sat Dec 10 08:32:34 2011
New Revision: 182184

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182184
Log:
PR gcov-profile/51449
* coverage.c (coverage_end_function): Always process the coverage
variables.

testsuite/
* g++.dg/gcov/gcov-14.C: New.

Added:
trunk/gcc/testsuite/g++.dg/gcov/gcov-14.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/51449] [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure

[nathan at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51449

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Nathan Sidwell nathan at gcc dot gnu.org 2011-12-10 
08:35:24 UTC ---
I've committed the attached patch to resolve 51449.  Even though the function
is entirely inlined, we need to emit its coverage counters.

tested in i686-pc-linux-gnu with profiled bootstrap.

[Bug c++/65954] gcc segfaults on the following input with a syntax error

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Wed May 20 01:54:09 2015
New Revision: 223430

URL: https://gcc.gnu.org/viewcvs?rev=223430root=gccview=rev
Log:
cp/
PR c++/65954
* typeck.c (finish_class_member_access_expr): Diagnose failed
lookup of enum class member.

testsuite/
* g++.dg/cpp0x/pr65954.C: New.

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

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Fri Jun  5 13:35:30 2015
New Revision: 224152

URL: https://gcc.gnu.org/viewcvs?rev=224152root=gccview=rev
Log:
cp/
PR c++/52595
* parser.c (cp_parser_cache_defarg): Continue looking for
declarators when scanning a potential template argument list of an
NSDMI.

testsuite/
PR c++/52595
* g++,dg/cpp0x/nsdmi-defer5.C: Add template case.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer5.C

[Bug c++/58616] [meta-bug] nsdmi

[nathan at gcc dot gnu.org]

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

Bug 52595 Summary: [DR 325] commas and non-static data member initializers 
don't mix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595

   What|Removed |Added

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

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from Nathan Sidwell nathan at gcc dot gnu.org ---
patch committed

https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02582.html

[Bug c++/66421] G++ fails compilation when assigning tuple created with variadic template to auto variable

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org ---
Appears resolved in version r224163

[Bug c++/66443] Virtual inheritance vs. non-default constructors

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-08
 CC||nathan at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell nathan at gcc dot gnu.org ---
fixed on trunk.  Note initializers are instantiated lazily, so invalid ones may
be accepted without error, if never instantiated.

[Bug c++/58616] [meta-bug] nsdmi

[nathan at gcc dot gnu.org]

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

Bug 58583 Summary: [c++11] ICE with invalid non-static data member 
initialization in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583

   What|Removed |Added

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

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Tue Jun 16 01:59:55 2015
New Revision: 224502

URL: https://gcc.gnu.org/viewcvs?rev=224502root=gccview=rev
Log:
cp/
PR c++/58583
* cp-tree.h (DECL_INSTANTIATING_NSDMI_P): New.
* init.c (get_nsdmi): Check for DEFAULT_ARG in template case and
protect it from recursive instantiation.

testsuite/
PR c++/58583
* g++.dg/cpp0x/nsdmi-template14.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Wed May 27 20:36:14 2015
New Revision: 223773

URL: https://gcc.gnu.org/viewcvs?rev=223773root=gccview=rev
Log:
PR c++/66270
* tree.c (build_pointer_type_for_mode): Canonical type does not
inherit can_alias_all.
(build_reference_type_for_mode): Likewise.

PR c++/66270
* g++.dg/ext/alias-canon3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/alias-canon3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell nathan at gcc dot gnu.org ---
Patch applied to trunk

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED
 CC||nathan at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell nathan at gcc dot gnu.org ---
committed obvious patch

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Sun May 24 23:17:58 2015
New Revision: 223636

URL: https://gcc.gnu.org/viewcvs?rev=223636root=gccview=rev
Log:
cp/
PR c++/66243
* decl.c (build_enumerator): Don't silently convert scoped enums.

testsuite/
PR c++/66243
* g++.dg/cpp0x/pr66243.C: New.

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

[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug c++/65936] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Sat May 23 22:28:54 2015
New Revision: 223613

URL: https://gcc.gnu.org/viewcvs?rev=223613root=gccview=rev
Log:
cp/
PR c++/65936
* pt.c (lookup_template_class_1): Copy may_alias attribute too.

testsuite/
PR c++/65936
* g++.dg/template/pr65936.C: New.

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

[Bug c++/65936] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org ---
Patch committed to trunk

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell nathan at gcc dot gnu.org ---
Propagate ref qualifier to new function type.

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org ---
Author: nathan
Date: Thu May 21 20:50:45 2015
New Revision: 223502

URL: https://gcc.gnu.org/viewcvs?rev=223502root=gccview=rev
Log:
cp/
PR c++/60943
* decl2.c (change_return_type): Propagate FUNCTION_REF_QUALIFIED.

testsuite/
* g++.dg/cpp1y/pr60943.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr60943.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug c++/65954] gcc segfaults on the following input with a syntax error

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org ---
Added expected diagnostic

[Bug middle-end/67027] [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-28
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/67027] [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell nathan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org ---
Fixed in r226310

* gimplify.c (oacc_default_clause): Always set GOVD_MAP if found
in outer scope.

[Bug libgomp/68242] [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
I think my firstprivate patch resolves this one.

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Fri Oct  9 14:13:39 2015
New Revision: 228657

URL: https://gcc.gnu.org/viewcvs?rev=228657=gcc=rev
Log:
* config/nvptx/nvptx.c (nvptx_init_axis_predicate): Fix output
formatting.

PR 67861
* gimple-fold.c (gimple_fold_builtin): Add break after
BUILT_IN_PRINTF_CHK, BUILT_IN_VPRINTF_CHK folding.

Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/config/nvptx/nvptx.c
branches/gomp-4_0-branch/gcc/gimple-fold.c

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Tue Oct  6 16:47:00 2015
New Revision: 228536

URL: https://gcc.gnu.org/viewcvs?rev=228536=gcc=rev
Log:
PR 67861
* gimple-fold.c (gimple_fold_builtin): Add break after
BUILT_IN_PRINTF_CHK, BUILT_IN_VPRINTF_CHK folding.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed in 228536.

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

--- Comment #9 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan  5 14:40:11 2016
New Revision: 232075

URL: https://gcc.gnu.org/viewcvs?rev=232075=gcc=rev
Log:
gcc/cp/
PR c++/58583
* pt.c (build_non_dependent_expr): Don't try a checking fold when
parsing an nsdmi.

gcc/testsuite/
PR c++/58583
* g++.dg/cpp0x/nsdmi-template14.C: Adjust test & errors.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #10 from Nathan Sidwell  ---
Patch tested with both checking & release builds.  Applied.

[Bug c++/58616] [meta-bug] nsdmi

[nathan at gcc dot gnu.org]

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

Bug 58583 Summary: [c++11] ICE with invalid non-static data member 
initialization in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583

   What|Removed |Added

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

[Bug tree-optimization/68977] [gomp4] FAIL: c-c++-common/goacc/loop-2.c (internal compiler error)

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
As the code is ill-formed, and IIUC the error only happens if we;ve seen an
error, I suggest
push_gimplify_context (!seen_error ());

No point making the compiler work harder than necesary in the usual case?

[Bug c/69033] [6 regression] many internal compiler errors starting with r231928

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
patch r231928 reverted.  Analysis at
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02100.html

[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-06
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Nathan Sidwell  ---
Testing patch.  Aaron's isn't quite right.

[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jun  6 15:24:24 2016
New Revision: 237135

URL: https://gcc.gnu.org/viewcvs?rev=237135=gcc=rev
Log:
PR libgcc/71400
* libgcov-driver-system.c (__gcov_error_file): Disable if IN_GCOV_TOOL.
(get_gcov_error_file): Check __gcov_error_file before trying to
initialize it.
(gcov_error): Always use get_gcov_error_file.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-driver-system.c

[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed r237135.

[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Adding an at_eof check into try_const fixes the testcase.  (also) Adding an
at_eof <= 1 assert into cxx_eval_outermost_constant_expr causes 261 new fails. 
Although many are obviously init & ctor related, they're a fairly widely
distributed bunch -- one is even abi name mangling. I don't see any a priori
reason as to why those calls to cxx_eval_outermost_constant_expr couldn't end
up evaluating a constexpr call.

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Wed Feb 24 13:38:20 2016
New Revision: 233663

URL: https://gcc.gnu.org/viewcvs?rev=233663=gcc=rev
Log:
gcc/
PR other/69916
* omp-low.c (struct oacc_loop): Add ifns.
(new_oacc_loop_raw): Initialize it.
(finish_oacc_loop): Clear mask & flags if no ifns.
(oacc_loop_discover_walk): Count IFN_GOACC_LOOP calls.
(oacc_loop_xform_loop): Add ifns arg & adjust.
(oacc_loop_process): Adjust oacc_loop_xform_loop call.

gcc/testsuite/
PR other/69916
* c-c-++-common/goacc/pr69916.c: New.

Added:
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/pr69916.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Fixed on gomp4 r233663. Porting to trunk ...

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/55635] Deallocation function ("operator delete") not called when destructor throws exception

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Tue Apr 12 16:24:11 2016
New Revision: 234904

URL: https://gcc.gnu.org/viewcvs?rev=234904=gcc=rev
Log:
PR c++/70501

cp/
* constexpr.c (cxx_eval_bare_aggregate): Handle VECTOR_TYPE
similarly to PMF.

testsuite/
* g++.dg/init/pr70501.C: New.

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

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed r234904.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

--- Comment #11 from Nathan Sidwell  ---
Patrick's original patch did 2 things AFAICT
1) make constexpr_call_table GC deletable
2) add the fundef_copies_table etc.

The failure we're observing is of constexpr_call_table losing information,
which then causes the changing calls  of copy_fn.  Now, we'd still see that
changing behaviour without #2.  But I don't think we get it without #1.  The
logic in cxx_eval_call_expression is (pseudo code-ish):

entry = constexpr_call_table->find_or_insert (...)
if (entry->value)
  return entry->value

fn = get_fundef_copy (...)
result = evaluate (...)
entry->value = result;

return result;

Those are the only uses of the call_table and get_fundef_copy.

So restoring constexpr_call_table to non-deletableness is the safe patch.  We
still get the fundef_copy improvement.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

--- Comment #12 from Nathan Sidwell  ---
(In reply to Patrick Palka from comment #9)

> The decls belonging to a copy of a function must have new UIDs though
> because their uids are used to track their mutable values (within the
> constexpr_ctx::values hash_map).  So if the decls of two copies of the same
> function didn't have different uids then e.g. recursive function calls
> wouldn't get evaluated properly.

One could probably add something like DECL_CONTEXT(decl) into the hash's eq
function?

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

--- Comment #14 from Nathan Sidwell  ---
(In reply to Jakub Jelinek from comment #13)

> If you remove the deletableness, then I'd say it is really important to
> empty the whole freelist at least at the end of parsing, so that when GIMPLE
> optimizations and RTL optimizations run memory is not occupied by those
> anymore.

Makes sense.

> And perhaps instead of GC use some LRU eviction from the freelist if there
> are too many constexpr functions on the freelist (but it certainly shouldn't
> be dependent on stuff like free memory or GC etc.), so that builds are
> reproduceable.  There could be some --param with some sane defaults on how
> many functions in freelist can be kept.

Good idea.  I guess the right place is in cxx_eval_call_expression, when we
find  we're inserting a new entry we  should zap its current contents if it is
'too large'.

To be specific, I mean changing constexpr_call_table,  which holds call
results.  Not changing the fundef_copies_table, which holds lists of copied
functions and can remain  GC-deletable.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

--- Comment #27 from Nathan Sidwell  ---
(In reply to Jason Merrill from comment #26)

> With this patch gengtype seems to assign gt_ggc_mx(tree&) to cp/constexpr.o,
> breaking cc1 link.  I'm not going to try to fix that now, though someone
> else is welcome to.

Yeah, a similar link failure led me to adding all that gt_ggc_mx stuff in
yesterday's protopatch.  However, I think you're on the right minimal track. 
When the constexpr_call_table is gc-deleted, the preservation of the
fn_copies_table will guarantee we won't change UID allocation.  We'll still
want the post-parseing hook to kill the copies table.

I'll see what I can do with your patch.

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #7 from Nathan Sidwell  ---
Fixed r234768.

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Tue Apr  5 23:47:21 2016
New Revision: 234768

URL: https://gcc.gnu.org/viewcvs?rev=234768=gcc=rev
Log:
PR c++/70512
* class.c (fixup_may_alias): New.
(fixup_attribute_variants): Call it.

* g++.dg/ext/attribute-may-alias-5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/attribute-may-alias-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00191.html

but read the thread for why that's not the best patch.  Continuing ...

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #7 from Nathan Sidwell  ---
The change in debug  generation causes purtabations in  when GC happens.  Such
that in onecase we find  a cached result, and in the other case we do not. 
When we don't we end up here:

0  allocate_decl_uid () at ../../../src/gcc/tree.c:990
#1  0x01362a01 in copy_node_stat (node=0x76093e10) at
../../../src/gcc/tree.c:1157
#2  0x010f1a97 in copy_decl_no_change (decl=0x76093e10,
id=0x7fffb120) at ../../../src/gcc/tree-inline.c:5444
#3  0x010e0ebe in remap_decl (decl=0x76093e10, id=0x7fffb120)
at ../../../src/gcc/tree-inline.c:357
#4  0x010f45fe in copy_fn (fn=0x76168c40, parms=@0x76683a28:
0x0, result=@0x76683a30: 0xafafafafafafafaf)
at ../../../src/gcc/tree-inline.c:6148
#5  0x009ec170 in get_fundef_copy (fun=0x76168c40) at
../../../src/gcc/cp/constexpr.c:1021

copy_node_stat allocates  a new  UID for decls.  so despite its name
'copy_decl_no_change' does cause a change.

That decl never escapes out of the const-expr machinery, but of cause causes
later decls to have different numberings.  (which is what we're observing).

I suppose the constexpr machinery could restore the next_decl_uid (and perhaps
others?) after copy_fn -- or somewhere in that call chain.  But that does seem
rather icky.

Alternatively copy_decl_no_change could not allocate new UIDs?

Anyway, hope  that helps.

For reference, the difference happens with a  call to finish_return_stmt at
parser.c:11808 when input_location == 17095968.  We eventually end up in
cxx_eval_call_expression where the call:
 constexpr_call **slot
= constexpr_call_table->find_slot (_call, INSERT);
(line 1433) finds a non-empty slot in one case and not in the other. 
(constexpr_call_table is a deletable hash)

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

--- Comment #19 from Nathan Sidwell  ---
(In reply to Jason Merrill from comment #17)
> I still don't understand why/how this is causing problems, if
> -fcompare-debug only cares about the order of decls.  The copied decls
> shouldn't appear anywhere in the output, and other decls should still have
> the same order.

DECL_UID escapes into the emitted names, as the fragment Jakub's just pointed
to shows.  We perturb the DECL_UID's allocated, as I describe in comment 7. 
Hope that helps.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #5 from Nathan Sidwell  ---
We're turning 'ab's initializer into a static one (so the lack of a dynamic
initializer is a red herring).  But we're flubbing the form of that initializer
because the placement of AB's bases is not their declaration order.  B is
chosen as the primary base, so AB is laid out as:
AB size 24 align 8
  A @ 16
  B @ 0

The  emitted initializer is:
_ZL2ab:
.zero   16
.long   1  <-- A::a
.quad   _ZTV2AB+16
.quad   2  <-- B::element

(I modified the testcase so the NSDMIs are distinct non-zero values).  The 16
zero bytes appear to be skipping over the B sub-object to place A's
initializer.

We should be emitting something more like:

_ZL2ab:
.quad   _ZTV2AB+16
.quad   2  <--B::element
.long   1  <-- A::a
.zero   4  <-- tail padding

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Indeed, manually editing the assembly to such an initializer results in  a
working program.

The CONSTRUCTOR created for ab's  DECL_INITIAL has the correct things in it,
but in declaration  order.  I.e. it looks like:
IDX=field-for-A-base VAL=CONSTRUCTOR (...)
IDX=field-for-B-base VAL=CONSTRUCTOR (...)

I think CONSTRUCTOR_ELTs are expected to be in ascending placement order?

[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
the intended current implementation is to treat 'sum' as firstprivate. 
however, putting in an explicit firstprivate causes another different ICE (in 
lower_oacc_reductions) -- regardless of whether 'sum' is a parameter, or a
local (initialized) variable.  Clearly at least two other bugs lurk.

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Mon Mar  7 13:22:07 2016
New Revision: 234026

URL: https://gcc.gnu.org/viewcvs?rev=234026=gcc=rev
Log:
gcc/
PR middle-end/69916
* omp-low.c (struct oacc_loop): Add ifns.
(new_oacc_loop_raw): Initialize it.
(finish_oacc_loop): Clear mask & flags if no ifns.
(oacc_loop_discover_walk): Count IFN_GOACC_LOOP calls.
(oacc_loop_xform_loop): Add ifns arg & adjust.
(oacc_loop_process): Adjust oacc_loop_xform_loop call.

gcc/testsuite/
PR middle-end/69916
* c-c-++-common/goacc/pr69916.c: New.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/pr69916.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
Fixed r234636.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Thu Mar 31 15:30:33 2016
New Revision: 234636

URL: https://gcc.gnu.org/viewcvs?rev=234636=gcc=rev
Log:
PR c++/70393
* varasm.c (output_constructor_regular_field): Flush bitfield
earlier.  Assert we don't want to move backwards.

cp/
* constexpr.c (cxx_eval_store_expression): Keep CONSTRUCTOR
elements in field order.

testsuite/
* g++.dg/cpp0x/constexpr-virtual6.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual6.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #11 from Nathan Sidwell  ---
Applied to gcc-5 branch r234653.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  ---
Author: nathan
Date: Thu Mar 31 20:51:20 2016
New Revision: 234653

URL: https://gcc.gnu.org/viewcvs?rev=234653=gcc=rev
Log:
PR c++/70393
* varasm.c (output_constructor_regular_field): Flush bitfield
earlier.  Assert we don't want to move backwards.

cp/
PR c++/70393
* constexpr.c (cxx_eval_store_expression): Keep CONSTRUCTOR
elements in field order.

testsuite/
PR c++/70393
* g++.dg/cpp0x/constexpr-virtual6.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual6.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/varasm.c

[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Fri Apr  1 12:10:17 2016
New Revision: 234667

URL: https://gcc.gnu.org/viewcvs?rev=234667=gcc=rev
Log:
PR c++/68475
* decl.c (check_redeclaration_exception_specification): Check
regardless of -fno-exceptions.
* typeck2.c (merge_exception_specifiers): Relax assert by checking
flag_exceptions too.

* g++.dg/g++.dg/cpp0x/noexcept29.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r234667.

As this is a checking ICE, I don't intend backporting.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Marek, I suspected  something like what you say happening, I think we then need
to go through all the 'struct  S' types created during the parse and modify
them?

Are you working on that?  If so, please reassign this bug.

[Bug c++/68724] [4.9/5/6 Regression] ice in unify, at cp/pt.c:19902

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
One can turn it into the syntactically correct:
template 
  struct integral_constant {
  };

  struct X : integral_constant < bool, true >{
  };

template 
struct integral_constant < bool, __is_enum(_Tp)> {
};

but still get the ICE when unify meets an unexpected TRAIT_EXPR.

[Bug c++/55635] Deallocation function ("operator delete") not called when destructor throws exception

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
fixed r235297.

[Bug c++/55635] Deallocation function ("operator delete") not called when destructor throws exception

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Wed Apr 20 19:59:56 2016
New Revision: 235297

URL: https://gcc.gnu.org/viewcvs?rev=235297=gcc=rev
Log:
cp/
PR c++/55635
* init.c (build_vec_delete_1): Protect operator delete call in try
finally.
(build_delete): Likewise.
* optimize.c (build_delete_destructor_body): Likewise.

testsuite/
PR c++/55635
* g++.dg/eh/delete1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/eh/delete1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/optimize.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70819] New: constexpr error location wrong

[nathan at gcc dot gnu.org]

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

Bug ID: 70819
   Summary: constexpr error location wrong
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

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

Invoked as:
nathan@morden:28>./cc1plus -fpreprocessed cexpr-error.ii 

we get:

 constexpr int fn6(const int&, int) constexpr int fn7(const int*, int)
cexpr-error.ii: At global scope:
cexpr-error.ii:17:24:   in constexpr expansion of 'fn7(0u, 0)'
cexpr-error.ii:14:14:   in constexpr expansion of 'fn6((* a), b)'
cexpr-error.ii:7:7: error: 'a' is not a constant expression
   b = a;
   ^
cexpr-error.ii:18:24:   in constexpr expansion of 'fn7(0u, 8)'
cexpr-error.ii:14:14:   in constexpr expansion of 'fn6((* a), b)'
cexpr-error.ii:6:13:   in constexpr expansion of 'fn6(a, 0)'
cexpr-error.ii:18:43: error: 'a' is not a constant expression
 constexpr int n4 = fn7 ((const int *) 0, 8);

The first error is correctly located at tha 'b = a;' location.  The second
instance is  not, and shows the original call site.  inside constexpr.c the
first error is from an evaluation of the original function body.  the second is
from a cloned copy via the recursive call.  Something about cloning is throwing
off the error location.

[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
build_vec_init_elt (tree.c) says:

/* Subroutine of build_vec_init_expr: Build up a single element
   intialization as a proxy for the full array initialization to get things
   marked as used and any appropriate diagnostics.

   Since we're deferring building the actual constructor calls until
   gimplification time, we need to build one now and throw it away so
   that the relevant constructor gets mark_used before cgraph decides
   what functions are needed.  Here we assume that init is either
   NULL_TREE, void_type_node (indicating value-initialization), or
   another array to copy.  */

With constexprs now in play, that appears to be an incorrect approach.   I'm
not sure why it's even sensible to go building things early only to throw them
away and redo it.  It would seem better to just build the constructor (or
whatever) tree and keep it.

[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Created attachment 38514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38514=edit
slightly more reduced test case

We're invoking constexpr evaluation machinery after parsing is complete --
fini_constexpt has already been called.  This occurs during the emission of
BarContainer's constructor, after we've destructively gimplified MakeFoo.  We
end up in

0xa05bf2 maybe_constant_init(tree_node*, tree_node*)
../../../src/gcc/cp/constexpr.c:4457
0x929ce6 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../../src/gcc/cp/init.c:4178
0x9db06b cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../../src/gcc/cp/cp-gimplify.c:592

and from there we have const_expr_eval (Bar) -> const_expr_eval (MakeFoo) ->
ICE
The object we're gimplifying is a vec_init_expr

[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
I'm such a doofus :(

[Bug c++/70616] [4.9/5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #4 from Nathan Sidwell  ---
12.4 seems to cover this case, and indicate that with an unqualified name, we
call the complete object destructor -- not the base destructor.Thus
Patrick's test case is behaving as expected.

The qualified name will call that specific base's (in-charge, complete)
destructor.   And I think will not work with the current ABI in the case of
virtual bases.  The virtual bases could be placed  differently in the complete
object to how a particlar base would place them if it were the complete object 
(that's what  the VTT param is all about).

The std does not seem to indicate such calls are undefined though.

[Bug c++/70616] [4.9/5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Assignee|nathan at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #45 from Nathan Sidwell  ---
I am no longer  working  on this, Richard appears to have the ball.

A patch to stop GC cause the constexpr machinery perturbing DECL_UID is
attached to https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00607.html, but
currently deemed unnecessary.

[Bug c++/70616] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
Fixed by Jason's commit r238681

2016-07-22  Jason Merrill  

PR c++/71748
PR c++/52746
* pt.c (tsubst_baselink): Call
adjust_result_of_qualified_name_lookup for unqualified
destructors.

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

[Bug c++/71748] [5 Regression] ICE on valid (?) C++ template code invoking a base destructor: in build_base_path, at cp/class.c:304

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
*** Bug 70616 has been marked as a duplicate of this bug. ***

[Bug c/71849] New: bitfield placement of overly aligned type

[nathan at gcc dot gnu.org]

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

Bug ID: 71849
   Summary: bitfield placement of overly aligned type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

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

Iain Sandoe & I have discovered an anomaly with the placement of bitfields with
a paradoxically aligned underlying type (alignment > size).  The calculation in
 excess_unit_span (stor-layout.c) erroneously considers such bitfields to
always straddle an allocation unit boundary, unless they start at bit-offset 0
within such an allocation.

The testcase contains two struct definitions that differ only by the underlying
type of the SECOND field.  In char_bit, it's type is 'char
__attribute__((aligned(__alignof(int' -- a char with int alignment.  In
int_bit, its type is plain int.  Both are 1 bit in size.

One might expect these two structs to be laid out the same.  That doesn't
happen.

char_bit's second field is placed at byte offset 4 bit 0, whereas int_bit's
second field is placed at byte offset 0 bit 1.  The struct sizes and offsets of
the third field are also different, as fallout from this change.

It seems excess_unit_span (or its callers) should check for such paradoxical
bitfield types.

However, (a) this is probably a rare case and (b) changing this is going to
break ABI compatibility.  So we may not care (but I couldn't find an existing
bug capturing this problem).

FWIW clang lays out these structs identically, which is how we became aware of
the problem.

[Bug c++/68724] [5/6/7 Regression] ice in unify, at cp/pt.c:19902

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed r239167

[Bug c++/68724] [5/6/7 Regression] ice in unify, at cp/pt.c:19902

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Fri Aug  5 12:21:46 2016
New Revision: 239167

URL: https://gcc.gnu.org/viewcvs?rev=239167=gcc=rev
Log:
PR c++/68724
* pt.c (unify): TRAIT_EXPR is an expr.

PR c++/68724
* g++.dg/cpp0x/pr68724.C: New.

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

[Bug c++/68724] [5/6/7 Regression] ice in unify, at cp/pt.c:19902

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Fri Aug  5 19:58:36 2016
New Revision: 239177

URL: https://gcc.gnu.org/viewcvs?rev=239177=gcc=rev
Log:
PR c++/68724
* pt.c (unify): TRAIT_EXPR is an expr.

PR c++/68724
* g++.dg/cpp0x/pr68724.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/pr68724.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/68724] [5/6/7 Regression] ice in unify, at cp/pt.c:19902

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Fri Aug  5 20:04:27 2016
New Revision: 239178

URL: https://gcc.gnu.org/viewcvs?rev=239178=gcc=rev
Log:
PR c++/68724
* pt.c (unify): TRAIT_EXPR is an expr.

PR c++/68724
* g++.dg/cpp0x/pr68724.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/pr68724.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/79369] New: namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

Bug ID: 79369
   Summary: namespace definition with qualified id
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

namespaces are magically conjured up if you use a qualified name:

namespace X::Y::Z 
{
}

X::Y must already be a namespace, but we don't complain.

Also, we do the strong using dance on reopenings of a inline namespace.  We
only need to do it on creation.