[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #13 from Matthijs van Duin  ---
I also just ran into this one with g++ 6.2.1.

Here are some interesting cases:

union Foo {
union { int x; char y; } u;
union { int x; char y; } v;
int n;
};
std::vector foo = {
{}, // ok
{ .u = {} },// ok
{ .u = { .x = {} } },   // ok
{ .u = { .x = 0 } },// ok
{ .u = { .y = {} } },   // ICE in reshape_init_class
{ .u = { .y = 0 } },// ICE in reshape_init_class
{ .v = {} },// ok
{ .v = { .x = {} } },   // ICE in reshape_init_class
{ .v = { .x = 0 } },// ICE in reshape_init_class
{ .v = { .y = {} } },   // ICE in reshape_init_class
{ .v = { .y = 0 } },// ICE in reshape_init_class
{ .n = {} },// ok
{ .n = 0 }, // error: could not convert
};

Some more observations:
- Replacing the inner unions by structs results in the same errors (in addition
to some warnings for missing initializers)
- No errors occur if a C-style array is initialized instead of std::vector
- It doesn't matter if the inner aggregates are anonymous or not.

Similar things with an outer struct:

struct Bar {
union { int x; char y; } u;
union { int x; char y; } v;
};
std::vector bar = {
{ .u = {}, .v = {} },   // ok
{ .u = {}, .v = { .x = 0 } },   // ok
//  { .u = {}, .v = { .y = 0 } },   // ICE in reshape_init_class
{ .u = { .x = 0 }, .v = {} },   // ok
//  { .u = { .y = 0 }, .v = {} },   // ICE in reshape_init_class
//  { .v = { .x = 0 }, .u = {} },   // ICE in reshape_init_class
//  { .v = {}, .u = { .x = 0 } },   // ICE in reshape_init_class
//  { .v = {}, .u = {} },   // sorry, unimplemented
};

[Bug fortran/78822] [cleanup] replace static char buffers by std:string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
You would need to make sure it uses a xmalloc based allocator first or at least
calls xmalloc_failed upon allocation failure, otherwise it will be a serious
regression.

[Bug c/78829] New: bit-rotten "C99 mode" references in GCC manual

[sandra at gcc dot gnu.org]

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

Bug ID: 78829
   Summary: bit-rotten "C99 mode" references in GCC manual
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

There are quite a few references in the GCC manual to "C99" or "C99 mode" when
it really is describing behavior common to C99 and later standards.  This is
really confusing now that GCC defaults to a dialect based on C11 -- the
documentation with the "C99" references was probably written when C90 was still
the default, and now "C99" refers to an old standard instead of a new one.  All
these instances need to be reviewed and corrected as necessary.

I also think that we could eliminate some material from extend.texi by just
having a single section with an abbreviated bullet list of C99 features
supported as extensions in GNU C90 mode (VLAs, variadic macros, // comments,
etc).  And then maybe group some other things into a section on backward
compatibility features like the alternate syntax for variadic macros (or maybe
we should even deprecate/remove the support for that).

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||paul.richard.thomas at gmail 
dot c
   ||om

--- Comment #2 from Jerry DeLisle  ---
This bug and 78670 are actually related. Our interpretation was that the child
procedure should handle all the necessary I/O including reading or writing of
namelist object names and '=' signs.

However, thinking further, I see the child procedure can not know the object
name, only the parent can no this. I am hopeful having the parent do this will
not be too difficult.  That being said, I am onto it.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
r243736 should avoid the warning in ordinary bootstrap.  A patch for most of
the profiledbootstrap warnings has been posted for review here:

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01437.html

[Bug c++/77914] Wrong lambda definition accepted

[abutcher at gcc dot gnu.org]

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

--- Comment #4 from Adam Butcher  ---
(In reply to Michele Caini from comment #3)
> (In reply to Jakub Jelinek from comment #1)
> > Shall we remove that altogether, or just pedwarn on it?
> 
> I suspect it should be rejected, unless it is an intended extension of the
> compiler (for which I've not been able to find the docs - in this case, a
> pedwarn should be emitted at least).

It was an intended extension.  Without it, a lambda argument cannot include a
non-type template parameter or name within its body (without decltype) a type
inferred from its arguments.  Since it does not conflict with the standard, it
should be acceptable as a GCC extension.  I didn't document it at the time,
however, or pedwarn about it.  Possibly at the time it was added the standard
was still being finalized.

We could leave this issue open to address the docs and pedwarn unless you want
to drop the feature completely?

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor  ---
Author: msebor
Date: Fri Dec 16 02:57:22 2016
New Revision: 243736

URL: https://gcc.gnu.org/viewcvs?rev=243736=gcc=rev
Log:
PR bootstrap/78817 - stage2 bootstrap failure in vec.h:1613:5: error: argument
1 null where non-null expected after r243661

gcc/ChangeLog:
* vec.h (vec::safe_grow_cleared): Assert
a pointer is non-null.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/vec.h

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

[abutcher at gcc dot gnu.org]

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

Adam Butcher  changed:

   What|Removed |Added

   Assignee|abutcher at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #22 from Adam Butcher  ---
Firstly, apologies for not unassigning myself from this; I hope it hasn't
stopped others from looking into it.  I had meant to unassign myself after my
last attempt to fix this in early 2015.  Since then I haven't had any spare
time to look into it.

The patch I submitted in 2015
(https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00617.html) does indeed solve
this.  However, it captures 'this' in generic lambdas in some cases where it is
not required.

This is not ideal (see the follow up list discussion starting from Jason's
review https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00934.html).

The current implementation, though non-optimal, may be preferable to waiting
for a better version as at least code can be written which is correct, minimal
and doesn't surprise users (i.e. no 'this->' workarounds required).

This bug could be closed in favor of a "'this' is captured in generic lambdas
when it is not necessary'" with proofs along the lines as I suggested in
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00959.html and
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00973.html.

I've just done some 'this' capture analysis using Clang (3.9.0), the current
stock ArchLinux GCC (6.2.1 20160830) and my own build of GCC (7.0.0 20161215)
including the patches above.

Clang stops short of a fully optimal solution.  In fact it is less optimal than
GCC even for monomorphic lambdas.  It seems to capture 'this' whenever it sees
a name within the lambda body that resolves to a member, whether or not that
reference requires 'this'.  It even captures 'this' when a reference is made to
static member of a _different_ class which is surprising.

The following show a handful of cases.  The comments inline indicate whether
'this' is captured (sizeof lambda == 8) or not captured (sizeof lambda == 1)
for Clang (C), GCC (G) and GCC with my 2015 patches (G').

The line tagged with the asterisk is the only case in this set where the patch
is non-optimal; "f (2.4)" unambiguously resolves to the static member "A::f",
so 'this' need not be captured.

Since, with the patch, GCC is correct and more optimal than Clang, I think it
would make sense to go with it and raise a separate ticket to address the other
issue.


struct A {
  void b ();
  void f (int);
  static void f (double);
};

struct O {
  void x (int);
  static void x (double);
};

namespace N {
  void y (double);
}

template  struct diag;

void A::b() {
  auto l0 = [&](auto z) { f (z); };diag {}; // C:8 G:1 G':8
  auto l1 = [&](auto) { f (2.4); };diag {}; // C:8 G:1 G':8 *
  auto l2 = [&](auto) { O::x (2.4); }; diag {}; // C:8 G:1 G':1
  auto l3 = [&](auto) { N::y (2.4); }; diag {}; // C:1 G:1 G':1
  auto l4 = [&](auto) { }; diag {}; // C:1 G:1 G':1
  auto l5 = [&](int z) { f (z); }; diag {}; // C:8 G:8 G':8
  auto l6 = [&](int) { f (2.4); }; diag {}; // C:8 G:1 G':1
  auto l7 = [&](int) { O::x (2.4); };  diag {}; // C:8 G:1 G':1
  auto l8 = [&](int) { N::y (2.4); };  diag {}; // C:1 G:1 G':1
  auto l9 = [&](int) { };  diag {}; // C:1 G:1 G':1
}

[Bug fortran/78662] [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Patch submitted:

https://gcc.gnu.org/ml/fortran/2016-12/msg00193.html

[Bug c++/77573] bogus wide string literals in diagnostics

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
David, thanks for looking into this!  It never occurred to me that what GCC
prints is actually a string of octal numbers representing the first 7 bytes of
the wide string literal.

Either printing L"\x12345678\x00" as you suggest or even nothing (as some
compilers do) would, IMO, be better than the sequence of an odd number of octal
characters.

Here are few examples of what other compilers print:

x.C:1:19: error: cannot initialize a variable of type 'const wchar_t' with an
  lvalue of type 'const wchar_t [2]'
constexpr wchar_t s = L"\x12345678";
  ^   ~
1 error generated.

The EDG front end:

"x.C", line 1: error: a value of type "const wchar_t *" cannot be used to
  initialize an entity of type "const wchar_t"
  constexpr wchar_t s = L"\x12345678";
^

IBM XLC++ (where wchar_t is 2 bytes);
"t.C", line 1.23: 1540-0812 (W) The escape sequence "\x12345678" is out of
range. Value is truncated.
"t.C", line 1.21: 1540-0132 (S) The expression must be a constant expression.
"t.C", line 1.23: 1540-0257 (S) An object or reference of type "const wchar_t"
cannot be initialized with an expression of type "const wchar_t [2]".

Intel ICC:
t.C: error: a value of type "const wchar_t *" cannot be used to initialize an
entity of type "const wchar_t"
constexpr wchar_t c = L"\x12345678";
  ^

Oracle CC:
"x.C", line 1: Error: Cannot use const wchar_t[2] to initialize const wchar_t.
1 Error(s) detected.

[Bug fortran/78719] [F03] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1438

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-15
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed. An instrumented gfortran gives

../../work/gcc/fortran/trans-decl.c:1472:29: runtime error: member access
within null pointer of type 'struct gfc_symbol'
ASAN:DEADLYSIGNAL
=
==74738==ERROR: AddressSanitizer: SEGV on unknown address 0x0110 (pc
0x000100561635 bp 0x7fff5fbfe0a0 sp 0x7fff5fbfdf40 T0)
==74738==The signal is caused by a READ memory access.
==74738==Hint: address points to the zero page.
#0 0x100561634 in gfc_get_symbol_decl(gfc_symbol*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100561634)
#1 0x1005f0fc7 in gfc_conv_variable(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1005f0fc7)
#2 0x1005ce99c in gfc_conv_expr(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1005ce99c)
#3 0x100642a40 in gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100642a40)
#4 0x100648154 in gfc_trans_pointer_assign(gfc_code*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100648154)
#5 0x100438fc6 in trans_code(gfc_code*, tree_node*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100438fc6)
#6 0x10043a9af in gfc_trans_code(gfc_code*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10043a9af)
#7 0x100586645 in gfc_generate_function_code(gfc_namespace*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100586645)
#8 0x10043aa36 in gfc_generate_code(gfc_namespace*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10043aa36)
#9 0x10028d66e in translate_all_program_units(gfc_namespace*)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10028d66e)
#10 0x1002a8776 in gfc_parse_file()
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1002a8776)
#11 0x100405913 in gfc_be_parse_file()
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100405913)
#12 0x104b49754 in compile_file()
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x104b49754)
#13 0x104b521ed in do_compile()
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x104b521ed)
#14 0x106c37bfe in toplev::main(int, char**)
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106c37bfe)
#15 0x106c3cf17 in main
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106c3cf17)
#16 0x7fffcfa5a254 in start (/usr/lib/system/libdyld.dylib+0x5254)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100561634)
in gfc_get_symbol_decl(gfc_symbol*)
==74738==ABORTING
==74738==WARNING: ASan is ignoring requested __asan_handle_no_return: stack
top: 0x7fff5fc0; bottom 0x000154e9; size: 0x7ffe0ad7
(140729080283136)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
pr78719.f90:13:0:

s => g

internal compiler error: Abort trap: 6

[Bug fortran/78746] charlen_15.f90, charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||physiker at toast2 dot net

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 78827 has been marked as a duplicate of this bug. ***

[Bug fortran/78827] Compiling gfortran.dg/charlen_03.f90 and gfortran.dg/charlen_10.f90 cause internal compiler error (regression)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr78746.

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

[Bug fortran/78827] New: Compiling gfortran.dg/charlen_03.f90 and gfortran.dg/charlen_10.f90 cause internal compiler error (regression)

[physiker at toast2 dot net]

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

Bug ID: 78827
   Summary: Compiling gfortran.dg/charlen_03.f90 and
gfortran.dg/charlen_10.f90 cause internal compiler
error (regression)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

There are to two regressions while running the gfortran.dg testsuite:
(See https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01567.html) 

FAIL: gfortran.dg/charlen_03.f90   -O   1 blank line(s) in output
FAIL: gfortran.dg/charlen_03.f90   -O  (internal compiler error)
FAIL: gfortran.dg/charlen_10.f90   -O   1 blank line(s) in output
FAIL: gfortran.dg/charlen_10.f90   -O  (internal compiler error)


LANG=C gfortran-7 -v -o charlen_03 charlen_03.f90 
Driving: gfortran-7 -v -o charlen_03 charlen_03.f90
-mmacosx-version-min=10.11.6 -asm_macosx_version_min=10.11 -l gfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/lto-wrapper
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-7
Thread model: posix
gcc version 7.0.0 20161215 (experimental) [trunk revision 243680] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' 'charlen_03' '-mmacosx-version-min=10.11.6'
'-asm_macosx_version_min=10.11' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951 charlen_03.f90
-fPIC -quiet -dumpbase charlen_03.f90 -mmacosx-version-min=10.11.6 -mtune=core2
-auxbase charlen_03 -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//cc0FKK10.s
GNU Fortran (GCC) version 7.0.0 20161215 (experimental) [trunk revision 243680]
(x86_64-apple-darwin15.6.0)
compiled by GNU C version 7.0.0 20161215 (experimental) [trunk revision
243680], GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 7.0.0 20161215 (experimental) [trunk revision
243680] (x86_64-apple-darwin15.6.0)
compiled by GNU C version 7.0.0 20161215 (experimental) [trunk revision
243680], GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
charlen_03.f90:5:39:

   character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
   1
Error: Allocatable component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfortran-7: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

gfortran version 6.2.0:
LANG=C gfortran-fsf-6 -o charlen_03 charlen_03.f90
charlen_03.f90:5:39:

   character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
   1
Error: Allocatable component of structure at (1) must have a deferred shape
(null):0: confused by earlier errors, bailing out

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

[ian at gcc dot gnu.org]

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

--- Comment #9 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Dec 15 22:47:43 2016
New Revision: 243729

URL: https://gcc.gnu.org/viewcvs?rev=243729=gcc=rev
Log:
PR go/78763
compiler: call determine_types even for constant expressions

We need to call determine_types even for constant expressions, since a
constant expression may include code like unsafe.Sizeof(0).  Something
needs to determine the type of the untyped 0, and that should be the
determine_types pass.

Implementing that triggered a compiler crash on test/const1.go because
it permitted some erroneous constants to make it all the way to the
backend.  Catch that case by checking whether we get a constant
overflow error, and marking the expression invalid if we do.  This is
a good change in any case, as previously we reported the same constant
overflow error multiple times, and now we only report it once.

Fixes GCC PR 78763.

Reviewed-on: https://go-review.googlesource.com/34496

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/expressions.h

[Bug c++/78826] jump bypasses non-POD

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note there might be a rule about non trivial constructors in there too.

[Bug c++/78826] New: jump bypasses non-POD

[aurzenligl at gmail dot com]

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

Bug ID: 78826
   Summary: jump bypasses non-POD
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurzenligl at gmail dot com
  Target Milestone: ---

Compiler seems to break c++98 and c++03 standards by allowing to jump over
non-POD automatic local variable declaration.

// jump_bypasses_non_pod.cpp
struct empty {};
struct non_pod_in_cpp03 : public empty {};
void should_not_compile() {
goto label;
non_pod_in_cpp03 x;
label:
(void)x;
}

If I get the standard right, non-aggregates (types with bases or
private/protected non-static data members) are non-PODs and jumping over them
is illegal:
(C++03 6.7 §3) [stmt.dcl]
(C++03 8.5.1 §1) [dcl.init.aggr]
(C++03 9 §4) [class]

I'd expect that -pedantic compilation would at least issue a warning instead of
compiling ill-formed program silently:
$ g++-6 -Wall -Wextra -std=c++98 -g -pedantic -c jump_bypasses_non_pod.cpp

Problem happens with both kinds of jumps:
- goto to label
- switch to case
Problem reproduces with both std flags:
- -std=c++98
- -std=c++03
Problem reproduces on a wide range of gcc releases:
- gcc version 4.9.4 (Ubuntu 4.9.4-2ubuntu1~14.04.1) 
- gcc version 5.4.1 20160904 (Ubuntu 5.4.1-2ubuntu1~14.04) 
- gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04)

[Bug fortran/78822] [cleanup] replace static char buffers by std:string

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/78764] CPU type option discarded on 32-bit powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Actually, fixed on 5 and 6 as well.  This is a dup of PR71216.  Please
reopen that one if it does not work.

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

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||rin at NetBSD dot org

--- Comment #6 from Segher Boessenkool  ---
*** Bug 78764 has been marked as a duplicate of this bug. ***

[Bug c++/78825] missing error for template partial specialization using template alias type

[mattia.bonaducci at gmail dot com]

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

--- Comment #1 from Maciej Załucki  ---
My first thought was that it's bug introduced with N3651 support
(C++14 variable templates) to GCC 5 and partially fixed in GCC 5.2.

[Bug target/78764] CPU type option discarded on 32-bit powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
This should have been fixed on trunk in r238639, please confirm.

4.8 (and 4.9) are no longer supported.

[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication

[pj at hugeone dot co.uk]

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

--- Comment #2 from Piotr  ---
avr-gcc actually

[Bug c++/78825] New: missing error for template partial specialization using template alias type

[mattia.bonaducci at gmail dot com]

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

Bug ID: 78825
   Summary: missing error for template partial specialization
using template alias type
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattia.bonaducci at gmail dot com
  Target Milestone: ---

With GCC 5.1 it was possible to compile such code without errors of warnings.

---
template 
struct C;

template
using first = T;

template 
struct C  // OK only in 5.1
{
};

int main ()
{
}
---

Before and after 5.1 it yields "partial specialization 'C' does not
specialize any template arguments". By that I assume it was regression fixed in
next version. Now by slightly modifying this code we can still compile it
without any warnings or errors.

---
template 
struct C;

template
using first = T1;

template
using second = T2;

template 
struct C>  // OK on 5.1+
{
};

template 
struct C>  // OK on 5.1+
{
};

int main ()
{
//C> dummy; // error: ambiguous template instantiation
for 'struct C'
}
---
First error we get is when we try to use it. It looks like there is no way of
explicitly pointing to one of this specializations. This problem showed up with
GCC 5 and is still in 6 and 7 snapshot. 

Here's how I checked different compiler versions (-std=c++14 -O0 -Wall -Wextra)
https://godbolt.org/g/1uV80Z

[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Works for me on aarch64-linux-gnu with GCC 5.4 and above:
main:
adrpx1, nvx8
adrpx2, y
mov w0, 0
ldrbw1, [x1, #:lo12:nvx8]
lsl w1, w1, 4
strhw1, [x2, #:lo12:y]
ret

[Bug target/78823] Poor code on PowerPC when moving SFmode values between GPRs and vector registers

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc64-linux-gnu,
   ||powerpc64le-linux-gnu
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-15
  Known to work||4.8.5
   Host||powerpc64-linux-gnu,
   ||powerpc64le-linux-gnu
 Ever confirmed|0   |1
  Build||powerpc64-linux-gnu,
   ||powerpc64le-linux-gnu

--- Comment #1 from Michael Meissner  ---
This has been a bug since GCC 4.9.  GCC 4.8 generated the correct code with
-mcpu=power8.

[Bug c/78824] New: multiple add should in my opinion be optimized to multiplication

[pj at hugeone dot co.uk]

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

Bug ID: 78824
   Summary: multiple add should in my opinion be optimized to
multiplication
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pj at hugeone dot co.uk
  Target Milestone: ---

Hi

Example  (-O3)

volatile uint16_t y;
uint8_t nvx8;

int main(void) {


y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
}

translated to:
y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
  94:   80 91 00 01 lds r24, 0x0100
  98:   28 2f   mov r18, r24
  9a:   30 e0   ldi r19, 0x00   ; 0
  9c:   c9 01   movwr24, r18
  9e:   88 0f   add r24, r24
  a0:   99 1f   adc r25, r25
  a2:   88 0f   add r24, r24
  a4:   99 1f   adc r25, r25
  a6:   82 0f   add r24, r18
  a8:   93 1f   adc r25, r19
  aa:   82 0f   add r24, r18
  ac:   93 1f   adc r25, r19
  ae:   82 0f   add r24, r18
  b0:   93 1f   adc r25, r19
  b2:   82 0f   add r24, r18
  b4:   93 1f   adc r25, r19
  b6:   82 0f   add r24, r18
  b8:   93 1f   adc r25, r19
  ba:   82 0f   add r24, r18
  bc:   93 1f   adc r25, r19
  be:   82 0f   add r24, r18
  c0:   93 1f   adc r25, r19
  c2:   82 0f   add r24, r18
  c4:   93 1f   adc r25, r19
  c6:   82 0f   add r24, r18
  c8:   93 1f   adc r25, r19
  ca:   82 0f   add r24, r18
  cc:   93 1f   adc r25, r19
  ce:   82 0f   add r24, r18
  d0:   93 1f   adc r25, r19
  d2:   82 0f   add r24, r18
  d4:   93 1f   adc r25, r19
  d6:   90 93 02 01 sts 0x0102, r25
  da:   80 93 01 01 sts 0x0101, r24

It should be optimized to multiplication I think.

[Bug fortran/78798] [cleanup] some int-valued functions should be bool

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Looking through gfortran.h, some more candidates which could be converted:

int gfc_at_end (void);
int gfc_at_eof (void);
int gfc_at_bol (void);
int gfc_at_eol (void);

int gfc_check_include (void);
int gfc_define_undef_line (void);

int gfc_wide_is_printable (gfc_char_t);
int gfc_wide_is_digit (gfc_char_t);
int gfc_wide_fits_in_byte (gfc_char_t);

int gfc_generic_intrinsic (const char *);
int gfc_specific_intrinsic (const char *);
int gfc_intrinsic_actual_ok (const char *, const bool);

int gfc_has_vector_index (gfc_expr *);

int gfc_numeric_ts (gfc_typespec *);

int gfc_impure_variable (gfc_symbol *);
int gfc_pure (gfc_symbol *);
int gfc_implicit_pure (gfc_symbol *);
int gfc_elemental (gfc_symbol *);

int gfc_compare_array_spec (gfc_array_spec *, gfc_array_spec *);

int gfc_constant_ac (gfc_expr *);
int gfc_expanded_ac (gfc_expr *);

int gfc_check_digit (char, int);

[Bug target/30026] useless stack movement

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Fixed, but I have no idea when.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[law at redhat dot com]

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

Bug 30119 Summary: libjava testsuite output is erratic and unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119

   What|Removed |Added

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

[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #11 from Jeffrey A. Law  ---
libjava is dead.

[Bug rtl-optimization/29858] regmove has been silently disabled

[law at redhat dot com]

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

Bug 30119 Summary: libjava testsuite output is erratic and unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119

   What|Removed |Added

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

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #14 from John David Anglin  ---
Also seen on hppa-unknownlinux-gnu.

[Bug c/71110] label "caseN" should be warned about

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmalcolm at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from David Malcolm  ---
Thanks for filing this bug.

We already issue a warning for this within -Wall, via -Wunused-label (since
sometime at or before gcc 4.4, I think):

test.c: In function ‘main’:
test.c:18:3: warning: label ‘case2’ defined but not used [-Wunused-label]
   case2:
   ^

I think that if the user accidentally omits the space between the "case" and
the value, they're unlikely to also have a reference to that label name.

Marking this one as resolved.  Feel free to reopen if I'm missing something
here.

[Bug c++/77573] bogus wide string literals in diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
http://en.cppreference.com/w/cpp/language/escape says:
"Hexadecimal escape sequences have no length limit and terminate at the first
character that is not a valid hexadecimal digit."

These are 4-byte wchars, so the value fits.

emit_numeric_escape is called twice, once with 0x12345678, then with 0 for the
implicit terminator.

(gdb) p tbuf
$45 = {text = 0x23e77f0 "xV4\022", asize = 256, len = 8}

(gdb) p tbuf->text[0]
$37 = 120 'x'
(gdb) p tbuf->text[1]
$38 = 86 'V'
(gdb) p tbuf->text[2]
$39 = 52 '4'
(gdb) p tbuf->text[3]
$40 = 18 '\022'

Note that "xV4\022" is 0x12345678:

(gdb) p /x tbuf->text[0]
$46 = 0x78
(gdb) p /x tbuf->text[1]
$47 = 0x56
(gdb) p /x tbuf->text[2]
$48 = 0x34
(gdb) p /x tbuf->text[3]
$49 = 0x12

...and then the terminator:

(gdb) p tbuf->text[4]
$41 = 0 '\000'
(gdb) p tbuf->text[5]
$42 = 0 '\000'
(gdb) p tbuf->text[6]
$43 = 0 '\000'
(gdb) p tbuf->text[7]
$44 = 0 '\000'

So I think that the sequence that's printed is valid.

If I'm reading the following right, internally it's stored as a conversion of a
one-byte-per-char array string to a wchar_t:

(gdb) call debug_tree(t)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x718d5690 precision
32 min  max >
readonly constant
arg 0 
unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x71a17f18>
readonly constant
arg 0 
readonly constant
arg 0 
readonly constant static "xV4\022\000\000\000\000"


(gdb) call debug_tree((tree)0x71a2b560)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x71a17bd0
precision 32 min  max 
pointer_to_this >
DI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x71a17e70
domain 
type_6 DI size  unit size

align 64 symtab 0 alias set -1 canonical type 0x71a17c78
precision 64 min  max >
pointer_to_this >
readonly constant static "xV4\022\000\000\000\000">

The title of this bug is "bogus wide string literals in diagnostics", but the
diagnostic contains a regular string literal, not a wide string literal.

Perhaps we should be printing it as something like;

L"\x12345678\x00"

or somesuch, for such cases.

FWIW, compare with this:

z.C:1:23: error: invalid conversion from ‘const wchar_t*’ to ‘wchar_t’
[-fpermissive]
 constexpr wchar_t s = L"pqrstuvw";
   ^~~
z.C:1:23: error: ‘(wchar_t)((const
wchar_t*)"p\000\000\000q\000\000\000r\000\000\000s\000\000\000t\000\000\000u\000\000\000v\000\000\000w\000\000\000\000\000\000")’
is not a constant expression

[Bug tree-optimization/78154] memcpy et al can be assumed to return non-null

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed by a commit last month.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
(In reply to Franz Sirl from comment #7)
> And on x86_64 a profiledbootstrap with --enable-checking=yes fails like this:

I have just confirmed this by doing the same.  My profiledbootstrap shows the
following warnings:

DiagnosticCount   UniqueFiles
-Wformat-length=  321
-Wimplicit-fallthrough=  58   114
-Wmaybe-uninitialized1065
-Wnonnull1764

With the following unique -Wnonnull instances: 
  cc1plus: warning: argument 1 null where non-null expected [-Wnonnull]
  /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype.c:1760
  /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype.c:1762
  /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype-parse.c:951
  /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype-parse.c:952
  /opt/notnfs/msebor/src/gcc/trunk/gcc/vec.h:1613

The -Wnonnull warnings all look justified to me (as best I can tell), but also
easily avoidable.

[Bug tree-optimization/16427] dead memset not optimized away

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Both cases compile down to simple returns at the tree level now.  I did not
bother to bisect precisely which changes are responsible for fixing this BZ.

[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR

[law at redhat dot com]

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

Bug 16427 Summary: dead memset not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427

   What|Removed |Added

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

[Bug c++/78771] [5/6/7 Regression] ICE when using inherited constructors (instantiate_template_1 in gcc/cp/pt.c:17391)

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 40345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40345=edit
simpler testcase

the deletedness of the template ctor is a red herring.  Also the templatedness
of the base class.  This testcase ices in the same way -- we end up looking for
a clone during the middle of instantiating the non-clone origin.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
(In reply to Segher Boessenkool from comment #3)
> It is a warning (as well as a bootstrap comparison error) on powerpc64-linux.
> You tested on powerpc64le-linux, different animal.

I missed that.  But I'm not able to reproduce the bootstrap comparison error
even on powerpc64-linux (on POWER8).  With the warning fixed my bootstrap just
completed.

[Bug fortran/78798] [cleanup] some int-valued functions should be bool

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Dec 15 20:54:18 2016
New Revision: 243726

URL: https://gcc.gnu.org/viewcvs?rev=243726=gcc=rev
Log:
2016-12-15  Janus Weil  

PR fortran/78798
* gfortran.h (gfc_compare_derived_types,gfc_compare_types,
gfc_compare_interfaces,gfc_has_vector_subscript): Return bool instead
of int.
* interface.c (compare_components): Ditto.
(gfc_compare_union_types): Rename to compare_union_types, declare as
static, return bool.
(gfc_compare_derived_types): Return bool instead of int.
(gfc_compare_types): Ditto.
(compare_type): Ditto.
(compare_rank): Ditto.
(compare_type_rank): Ditto.
(compare_type_rank_if): Ditto.
(count_types_test): Ditto.
(generic_correspondence): Ditto.
(gfc_compare_interfaces): Ditto.
(check_interface0): Ditto.
(check_interface1): Ditto.
(compare_allocatable): Ditto.
(compare_parameter): Ditto.
(gfc_has_vector_subscript): Ditto.
(compare_actual_formal): Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #11 from Jeffrey A. Law  ---
This is effectively the same as 61912 and fixed by the same change under
development.  We'll track via 61912, but expect to use the testcase from this
BZ as well as 61912 in the testsuite.

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

[Bug middle-end/61912] Missed (partial) dead store elimination for structures on GIMPLE

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||petschy at gmail dot com

--- Comment #3 from Jeffrey A. Law  ---
*** Bug 77485 has been marked as a duplicate of this bug. ***

[Bug middle-end/61912] Missed (partial) dead store elimination for structures on GIMPLE

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
So testing this with my improvements to DSE, we discover that the first 12
bytes and the last 4 bytes of the CONSTRUCTOR assignment are dead.  Leaving
just 4 bytes to be handled by the CONSTRUCTOR assignment.Prior to DSE this
looked like:

  info = {};
  info.prec = prec_11(D);
 [ ... more explicit assignments ... ]

With the DSE improvements it turns into;


  MEM[(char[4] *) + 12B] = {};
  info.prec = prec_11(D);
[ more explicit assignment follow. ]

Note how we turned the full CONSTRUCTOR into one that starts at byte offset 12
and just writes 4 bytes.

We could have started the CONSTRUCTOR at byte 13 instead of byte 12, as the
first 8 single bit fields are assigned explicitly.  The code detects this
properly, but explicitly avoids trimming to an odd start byte so as not to
totally muck up alignments.

[Bug c++/64380] Missed optimization: smarter dead store elimination in dtors

[law at redhat dot com]

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

--- Comment #1 from Jeffrey A. Law  ---
So the missed dead stores are due to DSE's inability to walk through the loop
in ReleaseAll.  As a result stores occurring prior to that loop can't be
discovered as dead.

For reference, here's an example that's already been partially DSE'd:

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  # .MEM_3 = VDEF <.MEM_1(D)>
  f_2(D)->D.2321.b0 = 192;
  # .MEM_4 = VDEF <.MEM_3>
  f_2(D)->m1 = 42;
  # .MEM_18 = VDEF <.MEM_4>
  f_2(D)->m1 = 1;
  # .MEM_19 = VDEF <.MEM_18>
  f_2(D)->m2 = 2;
  # VUSE <.MEM_19>
  n_8 = f_2(D)->nodes;
  if (n_8 == 0B)
goto ; [7.50%]
  else
goto ; [92.50%]
;;succ:   4
;;3

;;   basic block 3, loop depth 1
;;pred:   3
;;2
  # n_12 = PHI 
  # .MEM_21 = PHI <.MEM_20(3), .MEM_19(2)>
  # VUSE <.MEM_21>
  t_10 = n_12->next;
  # .MEM_20 = VDEF <.MEM_21>
  operator delete (n_12, 16);
  if (t_10 == 0B)
goto ; [7.50%]
  else
goto ; [92.50%]
;;succ:   4
;;3

;;   basic block 4, loop depth 0
;;pred:   3
;;2
  # .MEM_14 = PHI <.MEM_20(3), .MEM_19(2)>
  # .MEM_7 = VDEF <.MEM_14>
  MEM[(struct  &)f_2(D)] ={v} {CLOBBER};
  # .MEM_5 = VDEF <.MEM_7>
  operator delete (f_2(D), 32);
  # VUSE <.MEM_5>
  return;
;;succ:   EXIT

}

We'd like to discover the stores in bb2 as dead.  Let's look at f2->m2 = 2
first.  MEM_19 is used by the PHI in BB3.  So we'd have to walk through the
loop following the memory objects, eventually hoping to get to BB4 where we
discover the object dies.

DSE gets very careful walking through loops and thus is unable to handle this
particular case.

[Bug fortran/78662] [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  ---
Status. This is one of those where I was looking at the solution and did not
see it for a while. Then it pops into view. The strings are stored with the
double quotes and passed that way to the write routines. For these strings we
have a special write function that removes them as the string is written. We
need to do likewise as we build the iotype format string.

Patch is in the works.

[Bug c++/77585] g++ incorrectly decides that member function is called without object in generic lambda

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed on trunk

[Bug c++/77585] g++ incorrectly decides that member function is called without object in generic lambda

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec 15 19:50:25 2016
New Revision: 243723

URL: https://gcc.gnu.org/viewcvs?rev=243723=gcc=rev
Log:
PR c++/77585
* pt.c (instantiate_decl): Push to class scope lambda resides
within when instantiating a generic lambda function.

PR c++/77585
* g++.dg/cpp1y/pr77585.C: New.

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

[Bug c++/77829] Bad fix-it for nested-name-specifier

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Has some similarities with PR c++/78656.

[Bug target/78823] New: Poor code on PowerPC when moving SFmode values between GPRs and vector registers

[meissner at gcc dot gnu.org]

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

Bug ID: 78823
   Summary: Poor code on PowerPC when moving SFmode values between
GPRs and vector registers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40344=edit
Sample test file.

The code for moving SFmode values between GPRs and vector registers can be
improved in ISA 2.07 (-mcpu=power8) and ISA 3.0 (-mcpu=power9).

Right now, using a simple test case with a union, -mcpu=power8 generates a
store and load to move a SFmode value from a vector register to a general
purpose register.  However, some code does generate the appropriate moves.

Going the other way, seems to generate the appropriate instructions.

Using the same simple test case on -mcpu=power9, store/load is used in both
cases.

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
   [0.00%]:
  MEM[(char[170] *)& + 30B] = {};
  .buf[0] = 48;
[ ... ]

[Bug target/78639] [7 Regression] Power9 bad code generation for cactusADM benchmark

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 243206.

[Bug target/78658] powerpc64le: ICE with -mcpu=power9 -Og

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Fixed in subversion id 243320.

[Bug driver/78787] O Color, Where Art Thou? (with -flto)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> Created attachment 40343 [details]
> Hack to debug diagnostic-color.c

$ ./xgcc -B. -O2 -Wall -Wextra -flto /home/david/coding-3/gcc-git-clean/src/z.c
should_colorize: true (isatty (stderr))
should_colorize: true (isatty (stderr))
/home/david/coding-3/gcc-git-clean/src/z.c: In function ‘main’:
/home/david/coding-3/gcc-git-clean/src/z.c:3:27: warning: unused parameter
‘argv’ [-Wunused-parameter]
 int main (int argc, char *argv[])
   ^~~~
should_colorize: false (!isatty (stderr))
should_colorize: false (!isatty (stderr))
should_colorize: false (!isatty (stderr))
should_colorize: false (!isatty (stderr))
/home/david/coding-3/gcc-git-clean/src/z.c: In function ‘main’:
/home/david/coding-3/gcc-git-clean/src/z.c:5:3: warning: ‘__builtin_strcpy’
writing 4 bytes into a region of size 1 overflows the destination
[-Wstringop-overflow=]
   __builtin_strcpy (d, argc < 3 ? "123" : "456789");
   ^

So it appears that lto's stderr is not directly connected to a tty, and hence
there's no colorization by default.

[Bug driver/78787] O Color, Where Art Thou? (with -flto)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Created attachment 40343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40343=edit
Hack to debug diagnostic-color.c

[Bug fortran/78718] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1427

[jim.macarthur at codethink dot co.uk]

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

--- Comment #3 from Jim MacArthur  ---
It looks to me like the assertion failure is because the symbol in the argument
expression doesn't have the attr.referenced bit set. resolve_actual_arglist
replaces the symtree in the 'z' expression when it finds the 'z' in the parent
namespace:

  e->symtree = parent_st;   /* Point to the right thing.  */

But this new symtree's symbol doesn't have attr.referenced set, unlike the
symtree it's replacing. You can copy the old referenced bit across to make it
work, but I've no idea yet what the correct solution is.

[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Run-time testcase:

__attribute__((noinline, noclone)) void
foo (int argc)
{
  if (argc <= 0 || argc > 3)
return;

  switch (argc)
{
case 1:
case 3:
  if (argc != 3)
__builtin_abort ();
  break;
case 2:
  asm ("");
  break;
default:
  __builtin_abort ();
}
}

int
main (void)
{
  foo (3);
}

[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

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

--- Comment #11 from Bill Seurer  ---
I just verified that with r243693 it works on power.  Thanks!

[Bug preprocessor/78811] [7 Regression] raw-string-6.c testsuite failure

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Sorry for the breakage; should be fixed by r243721.  Marking as resolved.

[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Thu Dec 15 18:05:05 2016
New Revision: 243721

URL: https://gcc.gnu.org/viewcvs?rev=243721=gcc=rev
Log:
Fix use-after-free lexing unterminated raw strings (PR preprocessor/78811)

gcc/ChangeLog:
PR preprocessor/78680
PR preprocessor/78811
* input.c (struct selftest::lexer_test): Add field
m_implicitly_expect_EOF.
(selftest::lexer_error_sink): New class.
(selftest::lexer_error_sink::s_singleton): New global.
(selftest::lexer_test::lexer_test): Initialize new field
"m_implicitly_expect_EOF".
(selftest::lexer_test::~lexer_test): Conditionalize the
check for the EOF token on the new field.
(selftest::test_lexer_string_locations_raw_string_unterminated):
New function.
(selftest::input_c_tests): Call the new test.

libcpp/ChangeLog:
PR preprocessor/78680
PR preprocessor/78811
* lex.c (_cpp_lex_direct): Only determine the end-location of
the token and build a range for non-reserved start locations.
Do not do it for EOF tokens.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug preprocessor/78811] [7 Regression] raw-string-6.c testsuite failure

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Thu Dec 15 18:05:05 2016
New Revision: 243721

URL: https://gcc.gnu.org/viewcvs?rev=243721=gcc=rev
Log:
Fix use-after-free lexing unterminated raw strings (PR preprocessor/78811)

gcc/ChangeLog:
PR preprocessor/78680
PR preprocessor/78811
* input.c (struct selftest::lexer_test): Add field
m_implicitly_expect_EOF.
(selftest::lexer_error_sink): New class.
(selftest::lexer_error_sink::s_singleton): New global.
(selftest::lexer_test::lexer_test): Initialize new field
"m_implicitly_expect_EOF".
(selftest::lexer_test::~lexer_test): Conditionalize the
check for the EOF token on the new field.
(selftest::test_lexer_string_locations_raw_string_unterminated):
New function.
(selftest::input_c_tests): Call the new test.

libcpp/ChangeLog:
PR preprocessor/78680
PR preprocessor/78811
* lex.c (_cpp_lex_direct): Only determine the end-location of
the token and build a range for non-reserved start locations.
Do not do it for EOF tokens.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug fortran/78822] New: [cleanup] replace static char buffers by std:string

[janus at gcc dot gnu.org]

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

Bug ID: 78822
   Summary: [cleanup] replace static char buffers by std:string
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Several functions in interface.c use static-size char buffers for constructing
error messages, e.g.:

* gfc_compare_interfaces
* gfc_check_result_characteristics
* gfc_check_dummy_characteristics#
* ...

It would be more efficient to replace those by std::string, in order to
allocate the memory dynamically as needed (and only if needed at all).

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

[ian at airs dot com]

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

--- Comment #8 from Ian Lance Taylor  ---
Here is a test case that recreates the problem.

package p

import (
"unsafe"
)

func F() int {
if unsafe.Sizeof(0) == 8 {
return 8
}
return 0
}

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The problem is that the hoisting code seems to assume the hoisting would be
performed at the end of a bb, but that is not what insert_insn_end_basic_block
will then actually do.  But by the time insert_insn_end_basic_block is called,
it is too late to punt or find another bb to hoist it to.
compute_transp only analyzes transparency across the whole bb (to my surprise,
it considers all calls as potentially clobbering MEMs, not just non-const/pure
functions).
So I think we want to have some predicate for what insert_insn_end_basic_block
does to emit before the end of bb while searching for which bb to hoist to, and
if that predicate is true, if it is a CALL (non-const/pure?) then not consider
that bb for expressions containing MEMs (dunno if jumps could clobber MEMs
too).
Or just check for this and occrs_to_hoist.release (); if it happens in the
if (hoistable > 1 && dbg_cnt (hoist_insn)) block or so?

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Looking at the gengtype.c case, I think it is quite common case.
static inline const char*
get_input_file_name (const input_file *inpf)
{
  if (inpf)
  return inpf->inpname;
  return NULL;
}

const char *
get_file_srcdir_relative_path (const input_file *inpf)
{
  const char *f = get_input_file_name (inpf);
  if (strlen (f) > srcdir_len

Of course, if somebody calls get_file_srcdir_relative_path with NULL argument,
it will mean UB in strlen, but that still does not mean that strlen is ever
called with NULL.  The conditional in the first function might be just because
it is used in multiple places, in some where it allows NULL arguments, in
others where it doesn't.
Warning about if you ever hit this spot in the source, it will be always UB is
sometimes useful.  But that is not the case here, the same source location is
represented by 2 or more calls and it is just one of those that the optimizers
can't prove is unreachable, but the user can know is impossible.  Strlen would
segfault anyway if it was ever true.

[Bug target/71321] [6/7 Regression] x86: worse code for uint8_t % 10 and / 10

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #4 from Bernd Schmidt  ---
I have some ideas. Investigating...

[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 15 15:11:05 2016
New Revision: 243693

URL: https://gcc.gnu.org/viewcvs?rev=243693=gcc=rev
Log:
PR middle-end/78540
* gcc.dg/pr78540.c: Add -w to dg-options.

PR target/77834
* gcc.dg/pr77834.c: Add -w to dg-options.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr77834.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78540.c

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 15 15:11:05 2016
New Revision: 243693

URL: https://gcc.gnu.org/viewcvs?rev=243693=gcc=rev
Log:
PR middle-end/78540
* gcc.dg/pr78540.c: Add -w to dg-options.

PR target/77834
* gcc.dg/pr77834.c: Add -w to dg-options.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr77834.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78540.c

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Note, users that want this to be diagnosed reliably already can use
-fsanitize={returns-,}nonnull-attribute
So I think it is better to warn only about the obvious cases with very low
false positive rate, and leave the rest to the runtime.  Because there is
really nothing wrong on the testcases from profiledbootstrap (which is meant to
be supported without --disable-werror), and more importantly it is hard to
figure out what actually might be wrong and how to work around the false
positives.
The
PR bootstrap/78817
* vec.h (vec::quick_grow_cleared): Assert
postcondition.
( vec::safe_grow_cleared): Ditto.   
patch looks like alchemy, slows things actually down (and will not help with
--disable-checking anyway).

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I think that proves the warning is done in a bad place, a warning with so many
false positives is something that will push users away from gcc (or in the
better case they'll just disable it).

I think much better would be to warn soon after IPA, say after ccp2 pass, where
we have already propagated constants after inlining, but where optimizations
like jump threading have not been performed yet.  Or move the warning out of
-Wall, ideally out of -Wextra too.  Or have 2 levels, one where it warns after
ccp2 (and which is enabled in -Wall or -Wextra), and another one where it
instead warns late, but has known high false positive rate.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
trippels@gcc2-power8 linux % cat sm_ftl.i
int sm_read_sector_zone;
int *sm_read_sector_buffer = _read_sector_zone;
int sm_read_sector() {
  __builtin_memset(sm_read_sector_buffer, 0, 1);
again:
  if (sm_read_sector_zone)
if (!sm_read_sector_buffer)
  return 0;
  goto again;
}
void sm_init_zone() {
  sm_read_sector();
  sm_read_sector();
}

trippels@gcc2-power8 linux % gcc -c -Wall -O2 sm_ftl.i
trippels@gcc2-power8 linux % gcc -c -Wall -O3 sm_ftl.i
sm_ftl.i: In function ‘sm_init_zone’:
sm_ftl.i:4:3: warning: argument 1 null where non-null expected [-Wnonnull]
   __builtin_memset(sm_read_sector_buffer, 0, 1);
   ^
sm_ftl.i:4:3: note: in a call to built-in function ‘__builtin_memset’

[Bug libstdc++/59170] pretty printers: end iterator invalid pointer

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
I've added some more checks for non-debug iterators.

The only thing remaining is to add checks for debug iterators to detect when
they are past-the-end.

[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++

[linux at carewolf dot com]

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

--- Comment #15 from Allan Jensen  ---
Yes, the patch works and it also evaluates at compile time.

[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org ---
Closing for real.

[Bug libstdc++/59170] pretty printers: end iterator invalid pointer

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Thu Dec 15 14:13:36 2016
New Revision: 243692

URL: https://gcc.gnu.org/viewcvs?rev=243692=gcc=rev
Log:
PR59170 make pretty printers check for singular iterators

PR libstdc++/59170
* python/libstdcxx/v6/printers.py (StdListIteratorPrinter.to_string)
(StdSlistIteratorPrinter.to_string, StdVectorIteratorPrinter.to_string)
(StdRbtreeIteratorPrinter.to_string)
(StdDequeIteratorPrinter.to_string): Add check for value-initialized
iterators.
* testsuite/libstdc++-prettyprinters/simple.cc: Test them.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc

[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Dec 15 14:07:51 2016
New Revision: 243691

URL: https://gcc.gnu.org/viewcvs?rev=243691=gcc=rev
Log:
2016-12-15  Janus Weil  

PR fortran/78800
* interface.c (compare_allocatable): Avoid additional errors on bad
class declarations.
(compare_parameter): Put the result of gfc_expr_attr into a variable,
in order to avoid calling it multiple times. Exit early on bad class
declarations to avoid ICE.

2016-12-15  Janus Weil  

PR fortran/78800
* gfortran.dg/unlimited_polymorphic_27.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_27.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #2 from janus at gcc dot gnu.org ---
Fixed with r243691. Closing.

[Bug libstdc++/59161] GDB pretty printers: iterator->reference not printed

[palves at redhat dot com]

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

--- Comment #12 from Pedro Alves  ---
> So I think the libstdc++ part is fixed, 

Thanks.  TBC, given the pointer example in comment #9, I think GDB's implicit
use of options.addressprint=off for pretty printers is a clear GDB bug.  I
think GDB should change here, somehow.

> do we want a GDB bug to consider 
> changing how reference members are displayed? (I think printing the value as 
> well as the address makes sense).

Given we don't auto-deref pointers in structs either, I'm a bit undecided.
But filing a bug might be good, to see if others have opinions.  I'll take care
of it.

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
I've forced the relevant printers to convert to a string explicitly, so now you
always get the address, which seems better than {ref = }

So I think the libstdc++ part is fixed, do we want a GDB bug to consider
changing how reference members are displayed? (I think printing the value as
well as the address makes sense).

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu Dec 15 13:25:22 2016
New Revision: 243690

URL: https://gcc.gnu.org/viewcvs?rev=243690=gcc=rev
Log:
PR59161 make pretty printers always return strings

PR libstdc++/59161
* python/libstdcxx/v6/printers.py (StdListIteratorPrinter.to_string)
(StdSlistIteratorPrinter.to_string, StdVectorIteratorPrinter.to_string)
(StdRbtreeIteratorPrinter.to_string, StdDequeIteratorPrinter.to_string)
(StdDebugIteratorPrinter.to_string): Return string instead of
gdb.Value.
* testsuite/libstdc++-prettyprinters/59161.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/59161.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug fortran/78797] It is time perhaps to implement -std=f2015

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to janus from comment #6)
> Ok. Btw, the draft version of the F15 standard linked from the gfortran wiki
> is:
> 
> http://j3-fortran.org/doc/year/15/15-007.pdf
> 
> (from December 2014). Is this the last version, or this there a more recent
> one?

Answering that myself, I just found:

http://j3-fortran.org/doc/year/16/16-007r1.pdf

[Bug fortran/78797] It is time perhaps to implement -std=f2015

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #5)
> I do apologise, it seems that Mr Reid did not do his usual update. We
> will have to work from the draft standard itself.

Ok. Btw, the draft version of the F15 standard linked from the gfortran wiki
is:

http://j3-fortran.org/doc/year/15/15-007.pdf

(from December 2014). Is this the last version, or this there a more recent
one?

[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[sirl at gcc dot gnu.org]

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

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #7 from Franz Sirl  ---
And on x86_64 a profiledbootstrap with --enable-checking=yes fails like this:

../../gcc/gengtype.c: In function 'const char*
get_file_srcdir_relative_path(const input_file*)':
../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null expected
[-Werror=nonnull]
   if (strlen (f) > srcdir_len
   ~~~^~~
In file included from
/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/cstring:42:0,
 from ../../gcc/system.h:235,
 from ../../gcc/gengtype.c:26:
/usr/include/string.h:394:15: note: in a call to function 'size_t strlen(const
char*)' declared here
 extern size_t strlen (const char *__s)
   ^~
../../gcc/gengtype.c:1762:18: error: argument 1 null where non-null expected
[-Werror=nonnull]
   && strncmp (f, srcdir, srcdir_len) == 0)
  ^~~
In file included from
/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/cstring:42:0,
 from ../../gcc/system.h:235,
 from ../../gcc/gengtype.c:26:
/usr/include/string.h:143:12: note: in a call to function 'int strncmp(const
char*, const char*, size_t)' declared here
 extern int strncmp (const char *__s1, const char *__s2, size_t __n)
^~~
cc1plus: all warnings being treated as errors
Makefile:2596: recipe for target 'build/gengtype.o' failed
make[3]: *** [build/gengtype.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm fsf-funding.pod gcov.pod cpp.pod gfdl.pod gpl.pod gccgo.pod gfortran.pod
gcc.pod gcov-tool.pod
make[3]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/gcc'
Makefile:4728: recipe for target 'all-stagefeedback-gcc' failed
make[2]: *** [all-stagefeedback-gcc] Error 2
make[2]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux'
Makefile:24232: recipe for target 'stagefeedback-bubble' failed
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux'
Makefile:24251: recipe for target 'profiledbootstrap' failed
make: *** [profiledbootstrap] Error 2

[Bug middle-end/48888] Creating a copy variable simplify assembly - i686-pc-linux-gnu

[etienne_lorrain at yahoo dot fr]

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

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

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

--- Comment #2 from etienne_lorrain at yahoo dot fr ---
Problem no more visible in  g++ (GCC-Explorer-Build) 7.0.0 20161113
(experimental), indirect function call not un-necessarily copied to %edx before
calling *edx, closing.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[wilco at gcc dot gnu.org]

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

--- Comment #12 from wilco at gcc dot gnu.org ---
(In reply to wilco from comment #10)
> (In reply to Jan Hubicka from comment #9)
> > Created attachment 40217 [details]
> > predict
> > 
> > Hi,
> > here is patch adding the polymorphic case, too.
> > 
> > Honza
> 
> Looks good - gap still improves by 12%, SPECINT2k by 0.5%, SPECFP2k flat. So
> that fixes this issue.

I also ran SPEC2006 which didn't show any differences.(In reply to Martin Liška
from comment #11)
> I'm planning to run SPEC benchmarks late this week to find a proper value
> for the new predictor.

Any news on that? I ran SPEC2006 as well with the suggested values, and this
didn't show any differences.

[Bug middle-end/39456] Functions/variables of a file in different named sections

[etienne_lorrain at yahoo dot fr]

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

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

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

--- Comment #5 from etienne_lorrain at yahoo dot fr ---
Fixed (string concat into __attribute__((section("pre" "fix"))) ) on  g++
(GCC-Explorer-Build) 7.0.0 20161113 (experimental), result of:

void fct2 (void) __attribute__((__section__("sect1_" "fct2")));
void fct2 (void) { return; }

is:

.sectionsect1_fct2,"ax",@progbits
.p2align 4,,15
.globl  fct2()
.type   fct2(), @function
fct2():
.LFB0:
.file 1 "/tmp/gcc-explorer-compiler1161115-73-1xzfvi6/example.cpp"
.loc 1 2 0
.cfi_startproc
.loc 1 2 0
rep ret

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

[palves at redhat dot com]

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

--- Comment #9 from Pedro Alves  ---
> Sounds like Paul's original patch may have introduced an undesired 
> conflation.  AFAICS, options.addressprint's exists to implement "set print 
> address on/off", which had for original motivation, from the manual:

> Let's also take a look at what happens if you bypass the printer, with /r:

> (gdb) set print address off 
> (gdb) p /r it
> $6 = {_M_current = }
> (gdb) p /r it._M_current
> $7 = (C *) 
> (gdb) p /r *it._M_current 
> $8 = {ref = }
> (gdb) p /r it._M_current.ref
> $9 = (int &) 1

BTW, from the above, we can tell that the original problem with the printer is
not restricted to references (as per the subject).  Note above we skipped
printing the addresses of pointers, as expected due to "set print address off".

So if we tweak the original test to make "ref" a pointer instead:

#include 
class C {
public:
  int *ref;
  C(int *ref_):ref(ref_) {}
};
int main() {
  int *d(nullptr);
  std::vector vec({d});
  for (auto it=vec.begin();it!=vec.end();++it) {
it->ref; // line 11
__attribute__((unused)) C *gdb_stub(&*it);
  }
}

we get the same odd result:

(gdb) p it
$1 = {ref = }

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-15
   Target Milestone|--- |5.5
Summary|Wrong code generation due   |[5/6/7 Regression] Wrong
   |to hoisting memory load |code generation due to
   |across function call|hoisting memory load across
   ||function call
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
But in the end it actually is a regression that started r166555 (previously it
has been latent).

Slightly adjusted testcase:
struct T
{
  bool a;
  T () : a (false) {}
  ~T () { if (!a) __builtin_abort (); }
};

__attribute__((noinline))
void
test (T )
{
  x.a = true;
}

int
main ()
{
  T T;
  test (T);
}

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

[palves at redhat dot com]

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

--- Comment #8 from Pedro Alves  ---
Sounds like Paul's original patch may have introduced an undesired conflation. 
AFAICS, options.addressprint's exists to implement "set print address on/off",
which had for original motivation, from the manual:

 You can use @samp{set print address off} to eliminate all machine
 dependent displays from the @value{GDBN} interface.  For example, with
 @code{print address off}, you should get the same text for backtraces on
 all machines---whether or not they involve pointer arguments.

[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Print-Settings.html

With that in mind, skipping the address on references seems to make as much
sense as skipping it on pointers.


Let's also take a look at what happens if you bypass the printer, with /r:

 (gdb) set print address on
 (gdb) p /r it
 $2 = {_M_current = 0x614c20}
 (gdb) p /r it._M_current 
 $3 = (C *) 0x614c20
 (gdb) p /r *it._M_current 
 $4 = {ref = @0x7fffd908}
 (gdb) p /r it._M_current.ref
 $5 = (int &) @0x7fffd908: 1

 (gdb) set print address off 
 (gdb) p /r it
 $6 = {_M_current = }
 (gdb) p /r it._M_current
 $7 = (C *) 
 (gdb) p /r *it._M_current 
 $8 = {ref = }
 (gdb) p /r it._M_current.ref
 $9 = (int &) 1

Particularly, note how:

 (gdb) p /r *it._M_current 
 $4 = {ref = @0x7fffd908}

doesn't print the value of the reference field, while if you print it directly,
it's printed:

 (gdb) p /r it._M_current.ref
 $5 = (int &) @0x7fffd908: 1

I wonder whether we should change gdb to print it, like:

 (gdb) p /r *it._M_current 
 $1 = {ref = (int &) @0x7fffd908: 1}

and then with "print address off", you'd get:

 (gdb) p /r *it._M_current 
 $1 = {ref = (int &) 1}

But that question should be answered independently from the pretty printer
question.  I.e., what do people that debug C++ programs would find the most
useful default behavior to be, without pretty printers in the picture.  (Not
enough C++ references in GDB's own codebase yet for me to have a clear opinion
yet.  :-) )

[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates

[etienne_lorrain at yahoo dot fr]

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

Bug 24177 Summary: function returning structure produce very long/slow assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177

   What|Removed |Added

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

[Bug tree-optimization/24177] function returning structure produce very long/slow assembly

[etienne_lorrain at yahoo dot fr]

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

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

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

--- Comment #2 from etienne_lorrain at yahoo dot fr ---
Closing, code generated by g++ (GCC-Explorer-Build) 7.0.0 20161113
(experimental) from the source is now:
fct2():
subl$40, %esp
leal12(%esp), %eax
movl$1, 12(%esp)
movl$2, 16(%esp)
movl$3, 20(%esp)
movl$4, 24(%esp)
pushl   %eax
callfct3(str*)
addl$44, %esp
ret

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[etienne_lorrain at yahoo dot fr]

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

--- Comment #42 from etienne_lorrain at yahoo dot fr ---
Separate Bug 78821 has been successfully created following comment 41

[Bug c/78821] New: GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[etienne_lorrain at yahoo dot fr]

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

Bug ID: 78821
   Summary: GCC7: Copying whole 32 bits structure field by field
not optimised into copying whole 32 bits at once
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

Compiling (ia32, -O2) a function to copy whole structure is optimised on GCC7
pre-release (g++ (GCC-Explorer-Build) 7.0.0 20161113 (experimental)):

struct S
{
  char a, b, c, d;
} u, v;

void fct (void) {
  u = v;
}

leads to:
fct():
movlv, %eax
movl%eax, u
ret

But other ways to copy the structure are not optimised, both:
void fct (void) {
  u = (struct S){v.a, v.b, v.c, v.d};
}
and:
void fct (void) {
  u.a = v.a;
  u.b = v.b;
  u.c = v.c;
  u.d = v.d;
}

leads to:
movzbl  v, %eax
movb%al, u
movzbl  v+1, %eax
movb%al, u+1
movzbl  v+2, %eax
movb%al, u+2
movzbl  v+3, %eax
movb%al, u+3

[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Let me have a look.

[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-15
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
This behaviour effectively means pretty printers for generic C++ types must
never return gdb.Value from to_string() because they have no idea if GDB's
default stringification will be sane. An optional can't just return the T,
and Wrapper can't just return the X.

If the only case that's a problem is for reference members, then it seems
sensible to ignore the options.addressprint setting for references. Printing
{ref = } instead of {ref = @0x7fffd73c} seems like it's never useful.

[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/78819] New: [7 Regression] Wrong code with VRP caused by register assertions along default switch labels

[marxin at gcc dot gnu.org]

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

Bug ID: 78819
   Summary: [7 Regression] Wrong code with VRP caused by register
assertions along default switch labels
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

Started with r238761, following test-case behaves wrongly:

$ cat /tmp/testcase.c 
#include 
#include 

int main(unsigned argc, char **argv)
{
  if (argc <= 0)
return 0;
  if (argc > 3)
return 0;

  switch (argc)
  {
case 1:
case 3:
  fprintf (stderr, "value: %d\n", argc);
  break;
case 2:
  fprintf (stderr, "value: %d\n", argc);
  break;
default:
  abort();
  }

  return 1;
}

$ ./xgcc -B. /tmp/testcase.c -O0 -fdump-tree-optimized && ./a.out  1 1
value: 3
$ ./xgcc -B. /tmp/testcase.c -O2 -fdump-tree-optimized && ./a.out  1 1
value: 1

This miscompilation is detected by Python-2.7.12 package, that fails in
test_epoll test-case.

Thanks,
Martin