[Bug c/79969] C FE emits locus of forward enum declaration rather than definition into debug info

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
was the corresponding change for structs.

[Bug c/79969] C FE emits locus of forward enum declaration rather than definition into debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c/79969] New: C FE emits locus of forward enum declaration rather than definition into debug info

[jakub at gcc dot gnu.org]

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

Bug ID: 79969
   Summary: C FE emits locus of forward enum declaration rather
than definition into debug info
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

enum ENUMTAG;

enum ENUMTAG
{
  B = 1,
  C = 2
};

void
bar (void)
{
  enum ENUMTAG a = C;
}

The C FE emits DW_AT_decl_line 1 on the DW_TAG_enumerator_type rather than 3. 
The C++ FE with added say : int on line 1 and 3 uses line 3.

[Bug fortran/79968] New: diagnostics: merge similar diagnostics containing -fdec-structure

[roland.illig at gmx dot de]

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

Bug ID: 79968
   Summary: diagnostics: merge similar diagnostics containing
-fdec-structure
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

The file fortran/decl.c contains several of these diagnostics:

  gfc_error ("STRUCTURE at %C is a DEC extension, enable with "
 "-fdec-structure");

If these were written as follows, it would reduce work for the i18n
translators, as well as eliminate any chance of introducing typos.

  gfc_error ("%s at %C is a DEC extension, enable with "
 "%<-fdec-structure%>",
 "STRUCTURE");

This should basically be a textual search-and-replace for all occurrences of
"is a DEC extension".

[Bug c++/79865] ICE calling member function with template parameter from generic lambda

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-09
 CC||msebor at gcc dot gnu.org
  Known to work||7.0
Summary|Crash when calling member   |ICE calling member function
   |function with template  |with template parameter
   |parameter from generic  |from generic lambda
   |lambda  |
 Ever confirmed|0   |1
  Known to fail||6.3.1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of 6-branch.  Mainline compiles the test case
successfully.

t.C: In lambda function:
t.C:18:30: internal compiler error: Segmentation fault
 crashIt(); // Here's the crash!
 ~^~
0x10ba55c crash_signal
/src/gcc/6-branch/gcc/toplev.c:333
0x786f7a contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/src/gcc/6-branch/gcc/tree.h:3126
0xce390d size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
/src/gcc/6-branch/gcc/fold-const.c:1750
0xd88454 gimplify_compound_lval
/src/gcc/6-branch/gcc/gimplify.c:2090
0xdabe02 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/src/gcc/6-branch/gcc/gimplify.c:10331
0xd88e0b gimplify_arg(tree_node**, gimple**, unsigned int)
/src/gcc/6-branch/gcc/gimplify.c:2322
0xd8a0af gimplify_call_expr
/src/gcc/6-branch/gcc/gimplify.c:2539
0xdabea9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/src/gcc/6-branch/gcc/gimplify.c:10350
0xd95d84 gimplify_stmt(tree_node**, gimple**)
/src/gcc/6-branch/gcc/gimplify.c:5687
0xd9548d gimplify_cleanup_point_expr
/src/gcc/6-branch/gcc/gimplify.c:5463
0xdad768 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/src/gcc/6-branch/gcc/gimplify.c:10744
0xd95d84 gimplify_stmt(tree_node**, gimple**)
/src/gcc/6-branch/gcc/gimplify.c:5687
0xd84e94 gimplify_bind_expr
/src/gcc/6-branch/gcc/gimplify.c:1142
0xdacc5f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/src/gcc/6-branch/gcc/gimplify.c:10578
0xd95d84 gimplify_stmt(tree_node**, gimple**)
/src/gcc/6-branch/gcc/gimplify.c:5687
0xd84e94 gimplify_bind_expr
/src/gcc/6-branch/gcc/gimplify.c:1142
0xdacc5f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/src/gcc/6-branch/gcc/gimplify.c:10578
0xd95d84 gimplify_stmt(tree_node**, gimple**)
/src/gcc/6-branch/gcc/gimplify.c:5687
0xdb00ee gimplify_body(tree_node*, bool)
/src/gcc/6-branch/gcc/gimplify.c:11525
0xdb098a gimplify_function_tree(tree_node*)
/src/gcc/6-branch/gcc/gimplify.c:11681
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #12 from Pedro Alves  ---
TBC, the reason I filed this, is because GDB had an incorrect use like that
that survived for a few months:

 https://sourceware.org/ml/gdb-patches/2016-11/msg00933.html

until someone compiled GDB with clang:

 https://sourceware.org/bugzilla/show_bug.cgi?id=21206#c6

I can only imagine how many more incorrect uses are out there.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #11 from Pedro Alves  ---
> All the interesting calls here are undefined.

I meant that the one pointed out is undefined even without the nonnull
attribute.  I.e., it's not a use case that justifies supporting nonnull(1) on
non-members.  The others are only undefined due to the nonnull attribute.
Actually, I'd think that G++ should warn/error for that "((A*)0)->f();" case as
if the user that specified nonnull(1), even if the user hadn't.  I.e.,
implicitly add the nonnull(1) on all non-static methods.

> 
> The point of the example is to highlight that the nonnull attribute on the
> typedef
> 
>   typedef void F (void*) __attribute__ ((__nonnull__ (1)));
> 
> is interpreted differently depending on how the typedef is used.  While in
> most cases the number refers to the first void* argument, when it's used to
> declare a member function it refers to the implicit this argument.  If
> attribute((nonnull(1))) is to be rejected on non-static member function
> declarations as you suggest this seems like a case worth keeping in mind.

Yes, but that's not specific to the implicit this argument.  That's true for
_all_ arguments.  Change the prototype to:

  typedef void F (int, void*) __attribute__ ((__nonnull__ (2)));

and now when F is used as type of a class method, if the nonnull argument
number is reevaluated, nonnull(2) applies to the "int", which would be an
error, because that's not a pointer parameter.  Interestingly, seems like
neither G++ nor clang error in that case:

$ cat nonnull2.cc
typedef void F (int, void*) __attribute__ ((__nonnull__ (2)));

struct A
{
  F foo;
};

void foo ()
{
  A a;

  ((A *) 0)->foo (0, &a);
  ((A *) 0)->foo (1, 0);
  ((A *) 0)->foo (0, 0);
  a.foo (0, &a);
  a.foo (0, 0);
}
$ /opt/gcc/bin/g++ -O2 -c -Wall -Wextra -Wpedantic nonnull2.cc 
(nothing)
$ clang++ -O2 -c -Wall -Wextra -Wpedantic nonnull2.cc 
(nothing)

So I'm not sure what's the logic that dictates when and how are nonnull
argument numbers reevaluated in the method typedef case.  Looks like the
nonnull attribute is discarded above.  But in your case with nonnull(1), it
isn't.  ??!

Note that adding back the nonnull attribute like this:

struct A
{
- F foo;
+ F __attribute__ ((__nonnull__ (3))) foo;
};

makes both G++ and clang complain again as expected:

nonnull2.cc:13:23: warning: null argument where non-null required (argument 3)
[-Wnonnull]
   ((A *) 0)->foo (1, 0);
   ^
nonnull2.cc:14:23: warning: null argument where non-null required (argument 3)
[-Wnonnull]
   ((A *) 0)->foo (0, 0);
   ^
nonnull2.cc:16:14: warning: null argument where non-null required (argument 3)
[-Wnonnull]
   a.foo (0, 0);
  ^

> 
> The call to A::g in the test case is meant to demonstrate that simply
> printing "null argument where non-null required (argument 1)" in the
> diagnostic may not be sufficient to identify which argument is being
> referred to.  

I agree.

> The fact that the caret doesn't point at the argument only
> makes it that much more difficult (and underscores the importance of
> referring to the argument more clearly, e.g., by printing "the this pointer"
> instead of "argument 1" or something like that).

Definitely agreed.  For the other arguments, underlining the parameter in
question, as in clang's output shown in comment 7 makes it much simpler to
grok, IMO:

nonnull.cc:5:51: warning: '__nonnull__' attribute only applies to pointer
arguments [-Wignored-attributes]
  void foo (int, const char *arg) __attribute__ ((__nonnull__ (2)));
~~~

> Here's a slightly different example that should make that clear:

Understood and agreed.

[Bug driver/79882] Lack of bounds checking on -ftemplate-depth argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-09
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71905
 Ever confirmed|0   |1
  Known to fail||4.1.3, 4.2.2, 4.3.2, 4.6.0,
   ||5.3.0, 6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  GCC uses an int to represent numeric option arguments.  See also
bug 71905 for other (arguably more serious) manifestations of the same problem.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic -ftemplate-depth=4294967296 t.C
template 
void f () { f(); }

template void f<123>();
t.C:4:22: fatal error: template instantiation depth exceeds maximum of 0 (use
-ftemplate-depth= to increase the maximum)
 template void f<123>();
  ^
compilation terminated.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
All the interesting calls here are undefined.

The point of the example is to highlight that the nonnull attribute on the
typedef

  typedef void F (void*) __attribute__ ((__nonnull__ (1)));

is interpreted differently depending on how the typedef is used.  While in most
cases the number refers to the first void* argument, when it's used to declare
a member function it refers to the implicit this argument.  If
attribute((nonnull(1))) is to be rejected on non-static member function
declarations as you suggest this seems like a case worth keeping in mind.

The call to A::g in the test case is meant to demonstrate that simply printing
"null argument where non-null required (argument 1)" in the diagnostic may not
be sufficient to identify which argument is being referred to.  The fact that
the caret doesn't point at the argument only makes it that much more difficult
(and underscores the importance of referring to the argument more clearly,
e.g., by printing "the this pointer" instead of "argument 1" or something like
that).

Here's a slightly different example that should make that clear:

$ cat t.C && gcc -O2 -S -Wall -Wextra -Wpedantic t.C
typedef void F (void*, void*) __attribute__ ((nonnull));

struct A {
  F f;
  static F g;
};

void foo (A *p, A *q, A *r)
{
  p->f (q, r);   // argument 1 is the implicit this here...
  r->g (p, r);   // ...but the first argument here
}

void bar ()
{
  A *a = 0, b, c;
  foo (a, &b, &c);
}
t.C: In function ‘void bar()’:
t.C:10:8: warning: argument 1 null where non-null expected [-Wnonnull]
   p->f (q, r);   // argument 1 is the implicit this here...
   ~^~
t.C:4:5: note: in a call to function ‘void A::f(void*, void*)’ declared here
   F f;
 ^
t.C:11:8: warning: argument 1 null where non-null expected [-Wnonnull]
   r->g (p, r);   // ...but the first argument here
   ~^~
t.C:5:12: note: in a call to function ‘static void A::g(void*, void*)’ declared
here
   static F g;
^

[Bug c++/79797] [5/6 Regression] ICE with NSDMI, this pointer and constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE with |[5/6 Regression] ICE with
   |NSDMI, this pointer  and|NSDMI, this pointer  and
   |constexpr   |constexpr

--- Comment #4 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/79797] [5/6/7 Regression] ICE with NSDMI, this pointer and constexpr

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Mar  9 01:01:18 2017
New Revision: 245986

URL: https://gcc.gnu.org/viewcvs?rev=245986&root=gcc&view=rev
Log:
PR c++/79797 - ICE with self-reference in array DMI.

* constexpr.c (lookup_placeholder): Split out...
(cxx_eval_constant_expression): ...from here.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #9 from Pedro Alves  ---
>  ((A*)0)->g (p)

This is undefined behavior.  We forced the world to fix code like that in the
GCC 6 release cycle: https://gcc.gnu.org/gcc-6/changes.html

At best, I'd suggest degrading the error on implicit this nonnull(1) to a
warning iff compiling with -fno-delete-null-pointer-checks.  But I don't think
we really should need to cater to that.  FWIW.

[Bug c++/79967] New: ICE on non-type template argument declared noreturn

[msebor at gcc dot gnu.org]

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

Bug ID: 79967
   Summary: ICE on non-type template argument declared noreturn
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following (presumably) ill-formed program triggers an ICE.  It doesn't
appear to be a regression.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
template 
struct A
{
  int g () { f (); }
};

void f ();

void g (A a) { a.g (); }


t.C:1:31: internal compiler error: Segmentation fault
 template 
   ^
0x11be4aa crash_signal
/src/gcc/trunk/gcc/toplev.c:337
0x850518 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/src/gcc/trunk/gcc/cp/decl.c:11408
0x9844eb cp_parser_template_parameter
/src/gcc/trunk/gcc/cp/parser.c:15148
0x983882 cp_parser_template_parameter_list
/src/gcc/trunk/gcc/cp/parser.c:14707
0x99a591 cp_parser_explicit_template_declaration
/src/gcc/trunk/gcc/cp/parser.c:26535
0x99a6c0 cp_parser_template_declaration_after_export
/src/gcc/trunk/gcc/cp/parser.c:26569
0x98383a cp_parser_template_declaration
/src/gcc/trunk/gcc/cp/parser.c:14671
0x97fbfd cp_parser_declaration
/src/gcc/trunk/gcc/cp/parser.c:12445
0x97f958 cp_parser_declaration_seq_opt
/src/gcc/trunk/gcc/cp/parser.c:12372
0x96e794 cp_parser_translation_unit
/src/gcc/trunk/gcc/cp/parser.c:4366
0x9bece8 c_parse_file()
/src/gcc/trunk/gcc/cp/parser.c:38423
0xb720d6 c_common_parse_file()
/src/gcc/trunk/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
Consider the following test case.  If the decision is to allow A::g, it would
be helpful if the warning on calls to it made it clear which argument it's
referring to: the implicit this or the same argument 1 as that in the calls to
the other two functions.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
typedef void F (void*) __attribute__ ((__nonnull__ (1)));

F f;

struct A
{
  F g;
  static F h;
};

void foo (void *p)
{
  f (0);

  ((A*)0)->g (p);

  A::h (0);
}
t.C: In function ‘void foo(void*)’:
t.C:13:7: warning: null argument where non-null required (argument 1)
[-Wnonnul]
   f (0);
   ^
t.C:15:16: warning: null argument where non-null required (argument 1)
[-Wnonnull]
   ((A*)0)->g (p);
^
t.C:17:10: warning: null argument where non-null required (argument 1)
[-Wnonnull]
   A::h (0);
  ^

[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-08
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
I'm able to reproduce the issue seen in comment #0; am investigating.

[Bug target/79928] nds32: misspelled diagnostic: not support -fpic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in 245982.

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Mar  8 23:29:42 2017
New Revision: 245982

URL: https://gcc.gnu.org/viewcvs?rev=245982&root=gcc&view=rev
Log:
PR target/79928 - nds32: misspelled diagnostic: not support -fpic

Verified by building an nds32be-elf cross-compiler.

gcc/ChangeLog
* config/nds32/nds32.c (nds32_option_override): 


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

[Bug target/79928] nds32: misspelled diagnostic: not support -fpic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in 245982.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #7 from Pedro Alves  ---
Funny enough, clang 3.7 (don't have more recent handy), warns in that case,
while it errors on the "this" arg:

nonnull.cc:3:39: error: '__nonnull__' attribute is invalid for the implicit
this argument
  A (const char *arg) __attribute__ ((__nonnull__ (1)));
  ^~
nonnull.cc:4:46: error: '__nonnull__' attribute is invalid for the implicit
this argument
  void foo (const char *arg) __attribute__ ((__nonnull__ (1)));
 ^~
nonnull.cc:5:51: warning: '__nonnull__' attribute only applies to pointer
arguments [-Wignored-attributes]
  void foo (int, const char *arg) __attribute__ ((__nonnull__ (2)));
~~~   ^~
1 warning and 2 errors generated.

So nobody's consistent.  :-)

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #6 from Pedro Alves  ---
I remembered to check what does G++ say when you apply the nonnull to a
non-pointer argument.  We get a hard error:

$ /opt/gcc/bin/g++ nonnull.cc -o nonnull -c
nonnull.cc:5:67: error: nonnull argument references non-pointer operand
(argument 1, operand 2)
   void foo (int, const char *arg) __attribute__ ((__nonnull__ (2)));
   ^

I think this sets precedent for a hard error on the implicit "this" argument.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
For my s390x-linux fails to bootstrap with:
../../../libgfortran/generated/maxval_i16.c: In function 'maxval_i16':
../../../libgfortran/generated/maxval_i16.c:198:1: internal compiler error:
Max. number of generated reload insns per insn is achieved (90)
and
../../../../libsanitizer/ubsan/ubsan_diag.cc: In function 'void
RenderText(__sanitizer::InternalScopedString*, const char*, const
__ubsan::Diag::Ar
g*)':
../../../../libsanitizer/ubsan/ubsan_diag.cc:219:1: internal compiler error:
Max. number of generated reload insns per insn is achieved (90)
Bootstrap worked in r245735, so it is a new regression.
Can attach preprocessed sources in the morning, but if it is the same issue it
might be waste of time.

[Bug ipa/79966] New: [6/7 Regression] run time more than twice slower when using -fipa-cp-clone

[dominiq at lps dot ens.fr]

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

Bug ID: 79966
   Summary: [6/7 Regression] run time more than twice slower when
using -fipa-cp-clone
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

Created attachment 40927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40927&action=edit
reduced test from pr79930

This PR is a sequel of pr79930. On gcc6 and trunk (7.0) the run time is more
than twice slower when the attached test is compiled with -fipa-cp-clone in
addition to -O2 -fpeel-loops -finline-functions:

% gfca sum_xy.f90 -O2 -fpeel-loops -finline-functions
% ./a.out
 Using SUM, time:  9.28960443E-02
 sum =  -19609.087488337318 
% gfca sum_xy.f90 -O2 -fpeel-loops -fipa-cp-clone -finline-functions
% ./a.out
 Using SUM, time: 0.264802039
 sum =  -56108.398701889098 
% gfc6 sum_xy.f90 -O2 -fpeel-loops -finline-functions
% ./a.out
 Using SUM, time:  9.48660374E-02
 sum =  -27582.388828175150 
% gfc6 sum_xy.f90 -O2 -fpeel-loops -fipa-cp-clone -finline-functions
% ./a.out
 Using SUM, time: 0.279235005
 sum =  -37131.668569316826 
% gfc5 sum_xy.f90 -O2 -fpeel-loops -finline-functions
% ./a.out
 Using SUM, time: 0.106678963
 sum =   6552.5940282615447 
% gfc5 sum_xy.f90 -O2 -fpeel-loops -fipa-cp-clone -finline-functions
% ./a.out
 Using SUM, time: 0.104918003
 sum =   28692.268429922191 

gfca is trunk at r245974, gfc6 is 6.3.1 at r245745, and gfc5 is 5.4.1 at
r245752.

Looking at my archives it seems that the regression appeared un gcc5 before
branching, but has been reverted since, while always being in the gcc6 branch.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
One part of the problem is that v[v.size()] isn't necessarily out of bounds (in
the -Warray-bounds sense) because v.size() <= v.capacity().  At a minimum,
though, v[v.size()] is an uninitialized read (in the -Wuninitialized sense),
but GCC can't tell that from just f1's definition.  For a checker to diagnose
this problem it would need be taught about std::vector.  Not only that, because
vector is represented using pointers (begin, end, end-of-storage), GCC would
probably also need be taught about pointer relationships (i.e., that begin <=
end <= end-of-storage always holds).  Basically support some form of pointer
ranges.  That would be a great feature to have (not just for vectors) but I
don't have the impression anyone is working on it.  (The alternative to pointer
ranges is to implement some sort of a pattern checker for containers as
suggested in comment #4.  Such checkers are usually the province of static
analyzers.  I'm not aware of a precedent for something like that in GCC.)

[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Note that arm-netbsdelf is failing selftest due to a GC issue as well.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
I still can not reproduce it but I hope the fix for PR 79949 will be also a fix
for this PR.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
The fix will be ready tomorrow.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
I've reproduced it and started to work on it.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Yes, they chose to only do SSE2 and nothing else by default (and need to use
special clauses otherwise).  We chose to do SSE2, AVX, AVX2, AVX512F.  Of
course only for exported functions, for TU local ones it is just whatever arch
you optimize for.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
(In reply to Jakub Jelinek from comment #4)
> Yeah, and that is needed for ABI reasons.
> In this case it doesn't seem to be missing AVX2 support, but missing AVX512F
> support.
> Anyway, just upgrade your binutils, or avoid using !$omp declare simd.

Interesting.

The Intel compiler does not have this issue when this arch is selected.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Jakub Jelinek  ---
Yeah, and that is needed for ABI reasons.
In this case it doesn't seem to be missing AVX2 support, but missing AVX512F
support.
Anyway, just upgrade your binutils, or avoid using !$omp declare simd.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Harald Anlauf from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Your binutils does not support AVX-2 ...
> 
> No, it does not.   As I wrote, it's a dated machine.
> 
> But for -march=core2 there should be no AVX instructions anyway.

>!$omp declare simd(add)

Causes all simd variants to be created IIRC.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[anlauf at gmx dot de]

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

--- Comment #2 from Harald Anlauf  ---
(In reply to Andrew Pinski from comment #1)
> Your binutils does not support AVX-2 ...

No, it does not.   As I wrote, it's a dated machine.

But for -march=core2 there should be no AVX instructions anyway.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Your binutils does not support AVX-2 ...

[Bug fortran/79965] New: [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[anlauf at gmx dot de]

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

Bug ID: 79965
   Summary: [7 Regression] OpenMP simd, invalid instructions on
ia32 core2
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de
  Target Milestone: ---

Created attachment 40926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40926&action=edit
gfc-trunk -fopenmp gfcbug139.f90 -c -march=core2 -S -fverbose-asm

Hi,

the following code leads to invalid instructions on a dated machine
(arch=core2):

% cat gfcbug139.f90
pure real function add(a,b)
!$omp declare simd(add)
  real ,intent(in) :: a,b
  add=a+b
end function add

% gfc-trunk --version | head -1
GNU Fortran (GCC) 7.0.1 20170308 (experimental)

% gfc-trunk -fopenmp gfcbug139.f90 -c -march=core2
/tmp/cckyPHXa.s: Assembler messages:
/tmp/cckyPHXa.s:346: Error: no such instruction: `vmovdqu32 %zmm0,-192(%ebp)'
/tmp/cckyPHXa.s:347: Error: no such instruction: `vmovdqa64 %zmm1,%zmm0'
/tmp/cckyPHXa.s:348: Error: no such instruction: `vmovdqu32 %zmm0,-128(%ebp)'
/tmp/cckyPHXa.s:366: Error: bad register name `%zmm0'
/tmp/cckyPHXa.s:398: Error: no such instruction: `vmovdqu32 %zmm0,-192(%ebp)'
/tmp/cckyPHXa.s:399: Error: no such instruction: `vmovdqa64 %zmm1,%zmm0'
/tmp/cckyPHXa.s:400: Error: no such instruction: `vmovdqu32 %zmm0,-128(%ebp)'
/tmp/cckyPHXa.s:425: Error: bad register name `%zmm0'

See also attachment for the generated assembler.

[Bug c++/79797] [5/6/7 Regression] ICE with NSDMI, this pointer and constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Most of the warnings are gone due to the patch. These are the remaining ones:

libgfortran/generated/reshape_c16.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_c4.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_c8.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_i16.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_i4.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_i8.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_r16.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_r4.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_r8.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/intrinsics/execute_command_line.c:162:16: warning: ‘estat’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/intrinsics/execute_command_line.c:191:16: warning: ‘estat’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/intrinsics/reshape_generic.c:253:21: warning: ‘sstride[0]’ may be
used uninitialized in this function [-Wmaybe-uninitialized]

[Bug target/79395] Compile error with -mcpu=power9 and __builtin_vec_vcmpne_p

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kelvin at gcc dot gnu.org ---
Submitted patch resolves this issue.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Created attachment 40925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40925&action=edit
Patch to fix the libfortran issue

Based on Comment#6, this is a patch for the libfortran issue.
I am currently regression-testing.

Does this work for the libfortran issues?

[Bug target/79964] New: Cortex A53 codegen still not optimal

[tulipawn at gmail dot com]

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

Bug ID: 79964
   Summary: Cortex A53 codegen still not optimal
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Two data points:

- the integer benchmark from PR79665 runs about 7% slower with -mcpu=cortex-a53
vs other targets, equalling generic codegen. It was still indistinguishable on
20170220, so the regression must have happened shortly after as per PR79665#c13

- c-ray again, wherein dispensing with -mfix-cortex-a53-843419 removes the
handicap, but e.g. A57 codegen produces the best result ever on this machine:

http://openbenchmarking.org/result/1703089-RI-1703040RI07

Coming from a Cortex A53 with 32kB of L1 cache.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #5 from Pedro Alves  ---
> We certainly should allow __attribute__((nonnull)) on methods, even when that 
> > includes nonnull (implicit) also for this. 

Yes, agreed, with implicit nonnull with no specified argument.

For the case of specifying an argument number with nonnull(N), I don't find the
error weird at all, because "this" can never be NULL.  Even without the
attribute, the compiler is already free to assume that.  Calling a method via a
null pointer is undefined behavior.  So __attribute__((nonnull(1))) on a
non-static method is _always_ a bug.

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This changed with r217250 aka DR1558 change.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
We certainly should allow __attribute__((nonnull)) on methods, even when that
includes nonnull (implicit) also for this.  I find error on that weird, there
is nothing wrong specifying that this is non-null, so perhaps just warning (but
question is how to call it and under which of -Wall/-W or none of that enable
it).

[Bug c/79940] [6 Regression] OpenMP pragma - internal compiler error with taskloop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] OpenMP |[6 Regression] OpenMP
   |pragma - internal compiler  |pragma - internal compiler
   |error with taskloop |error with taskloop

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

[Bug target/79909] ICE error: invalid rtl sharing found in the insn on ppc64le

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 CC||pthaugen at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Pat Haugen  ---
Confirmed.

Reduced testcase.

// g++ -S -O1 -mxl-compat test.C
typedef float td __attribute__ ((mode (TD)));
td b, c, d, e, f, g;
void h (td, td, td, td, td, td);
void i ()
{
  h (e, b, f, c, g, d);
}

[Bug target/79963] New: vec_eq_any extracts wrong CR bit when compiling with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

Bug ID: 79963
   Summary: vec_eq_any extracts wrong CR bit when compiling with
-mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: meissner at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-* power9

Tested with trunk 245979:

gcc/xgcc -Bgcc ../trunk/gcc/testsuite/gcc.target/powerpc/altivec-12.c -maltivec
-lm -g -o ./altivec-12.exe

In test testsuite/gcc.target/powerpc/altivec-12.c line 50:

   CHECK_IF (vec_any_eq (h, addf1));

For power9 we generate this code:

.L17:
.loc 1 50 0 is_stmt 1
addis 9,2,.LC1@toc@ha
ld 9,.LC1@toc@l(9)
lxv 12,0(9)
addis 9,2,addf1@toc@ha
addi 9,9,addf1@toc@l
lxv 0,0(9)
xvcmpeqsp. 0,12,0
mfcr 9,2
rlwinm 9,9,25,1
xori 9,9,0x1
extsw 9,9
cmpdi 7,9,0
bne 7,.L18
.loc 1 50 0 is_stmt 0 discriminator 1
bl abort

In gdb I can see that h and addf1 are equal after loading, and the comparison
is correct, however we are extracting the wrong bit from the cr with the
rlwinm.

For power8 we generate this code:

.L17:
.loc 1 50 0 is_stmt 1
addis 9,2,.LC1@toc@ha
ld 9,.LC1@toc@l(9)
lxvd2x 0,0,9
xxpermdi 12,0,0,2
addis 9,2,addf1@toc@ha
addi 9,9,addf1@toc@l
lxvd2x 0,0,9
xxpermdi 0,0,0,2
xvcmpeqsp. 0,12,0
mfcr 9,2
rlwinm 9,9,27,1
xori 9,9,0x1
extsw 9,9
cmpdi 7,9,0
bne 7,.L18
.loc 1 50 0 is_stmt 0 discriminator 1
bl abort

which runs correctly.

[Bug rtl-optimization/79806] [5/6/7 Regression] ICE error: unable to find a register to spill (in assign_by_spills, at lra-assigns.c:1457)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  ---
I'm tempted to classify this as unsupported. The testcase reserves edx, and the
alloca call includes a division operation which requires edx. Without
optimization, it remains until register allocation.

Global registers are somewhat fragile, and I think it's not worth it trying to
fix this. I'd put this at P4 at most.

[Bug translation/79618] prevent missing space in multiline string literals

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Good idea.

We can't do it at run-time from inside the diagnostics subsystem, as the
line-breaking information is lost when the literal is compiled.

So from an implementation POV, I believe this would have to happen inside
xgettext when it scans the sources to create .pot files, so that it can enforce
one of the variants described in comment #1 (presumably as a new --check option
to xgettext).

In theory, we could do it with a compiler plugin that detects such strings, but
given that xgettext is scanning the strings already, presumably this would be
better implemented as an xgettext test.

Alternatively, I guess we could implement some kind of preprocessing hack to
run when generating the .pot files, but presumably other projects would find
this useful, so it seems to make more sense as an xgettext feature.

[Bug c++/79900] [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  8 17:21:06 2017
New Revision: 245980

URL: https://gcc.gnu.org/viewcvs?rev=245980&root=gcc&view=rev
Log:
PR c/79940
* gimplify.c (gimplify_omp_for): Replace index var in outer
taskloop statement with an artificial variable and add
OMP_CLAUSE_PRIVATE clause for it.

* testsuite/libgomp.c/pr79940.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr79940.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On March 8, 2017 4:43:05 PM GMT+01:00, "marxin at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956
>
>--- Comment #7 from Martin Liška  ---
>I can also see profiledbootstrap failure in:
>
>.././../gcc/simplify-rtx.c:6021:12: error: ‘result_s’ may be used
>uninitialized
>in this function [-Werror=maybe-uninitialized]
> return result_s;
>^~~~
>
>It worked with a revision from 3.3.2017, is it the same issue as seen
>by
>Markus?

I've run into this as well but it's slightly non reproducible (repeating the
compile command sometimes works, sometimes not).  From analyzing it looked
similar and/or threading related.

Richard.

[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681

[lopezibanez at gmail dot com]

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

--- Comment #5 from Manuel López-Ibáñez  ---
The first one seems the right approach. It will also fix a number of
similar bugs in one go.The second one seems more fragile and it doesn't
help in decoupling ME from FE more than the first.

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #2 from Pat Haugen  ---
Reduced testcase.

pthaugen@pike:~/temp/creduce$ cat junk.cpp
typedef int V4i __attribute__((vector_size(16)));
void a(V4i ) {
  vector int b;
  a(b);
}

pthaugen@pike:~/temp/creduce$ ~/install/gcc/trunk/bin/g++ -S junk.cpp
junk.cpp: In function ‘void a(V4i)’:
junk.cpp:4:6: internal compiler error: canonical types differ for identical
types __vector(4) int and V4i {aka __vector(4) int}
   a(b);
  ^
0x1038318b comptypes(tree_node*, tree_node*, int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/typeck.c:1433
0x1019524f standard_conversion
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/call.c:1187
0x101a6af3 implicit_conversion
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/call.c:1839
...

[Bug c++/79962] New: [7 Regression] ICE nonnull_check_p on a function template with a type-dependent attribute nonnull

[msebor at gcc dot gnu.org]

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

Bug ID: 79962
   Summary: [7 Regression] ICE nonnull_check_p on a function
template with a type-dependent attribute nonnull
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Today's top of trunk fails with an ICE on the following test case.  r245606
compiles the test case successfully so this is a recent regression.

$ cat t.C && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc  -S -Wall
-Wextra -Wnonnull t.C
template 
void f (typename T::U) __attribute__ ((__nonnull__ (T::i)));

struct S { enum { i = 1 }; typedef void* U; };

void g ()
{
  f(0);
}

t.C: In function ‘void g()’:
t.C:8:9: internal compiler error: in nonnull_check_p, at
c-family/c-common.c:5423
   f(0);
 ^
0xb1ee7d nonnull_check_p
/ssd/src/gcc/git/gcc/c-family/c-common.c:5423
0xb1e843 check_function_nonnull
/ssd/src/gcc/git/gcc/c-family/c-common.c:5301
0xb1f811 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**)
/ssd/src/gcc/git/gcc/c-family/c-common.c:5661
0x7ea3b0 build_over_call
/ssd/src/gcc/git/gcc/cp/call.c:7917
0x7dbc4b build_new_function_call(tree_node*, vec**, bool, int)
/ssd/src/gcc/git/gcc/cp/call.c:4278
0xa0f3a4 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/ssd/src/gcc/git/gcc/cp/semantics.c:2441
0x94c8f0 cp_parser_postfix_expression
/ssd/src/gcc/git/gcc/cp/parser.c:6994
0x94efe2 cp_parser_unary_expression
/ssd/src/gcc/git/gcc/cp/parser.c:8102
0x94fe35 cp_parser_cast_expression
/ssd/src/gcc/git/gcc/cp/parser.c:8780
0x94ff23 cp_parser_binary_expression
/ssd/src/gcc/git/gcc/cp/parser.c:8882
0x950c40 cp_parser_assignment_expression
/ssd/src/gcc/git/gcc/cp/parser.c:9170
0x950fdb cp_parser_expression
/ssd/src/gcc/git/gcc/cp/parser.c:9337
0x9542f8 cp_parser_expression_statement
/ssd/src/gcc/git/gcc/cp/parser.c:10885
0x953c69 cp_parser_statement
/ssd/src/gcc/git/gcc/cp/parser.c:10701
0x954847 cp_parser_statement_seq_opt
/ssd/src/gcc/git/gcc/cp/parser.c:11027
0x954742 cp_parser_compound_statement
/ssd/src/gcc/git/gcc/cp/parser.c:10981
0x968239 cp_parser_function_body
/ssd/src/gcc/git/gcc/cp/parser.c:21430
0x968402 cp_parser_ctor_initializer_opt_and_function_body
/ssd/src/gcc/git/gcc/cp/parser.c:21466
0x971791 cp_parser_function_definition_after_declarator
/ssd/src/gcc/git/gcc/cp/parser.c:26254
0x971595 cp_parser_function_definition_from_specifiers_and_declarator
/ssd/src/gcc/git/gcc/cp/parser.c:26166
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Yes, improving the docs would be a start. Issuing a warning like Clang does
would be ideal.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

--- Comment #2 from Pedro Alves  ---
Yeah, I think it's too late, and it'd cause trouble with compatibility with
clang.

Note that the documentation for the attribute(format)

says:

"Since non-static C++ methods have an implicit this argument, the arguments of
such methods should be counted from two, not one, when giving values for
string-index and first-to-check."

but the documentation for the nonnull attribute doesn't say anything about it. 
Maybe that bit could be factored out somehow, or copied, or xrefed.

[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Adding Richi to ask him for a smart advise :)

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
IMHO it would be much, much better if the implicit 'this' wasn't counted and
nonnull(1) referred to 'arg' but maybe it's too late to change that.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to David Binderman from comment #4)
> > Anyway, I think some progress could be made by finding the pattern
> > 
> > for (something = 0; something <= somethingElse.size(); ++ something)
> > 
> > at compile time, which is what the  static analyser 'cppcheck' seems to be
> > doing.
> 
> That's what I said, it would have to be a special case built in to the
> front-end.

And it has to be a lot smarter than that, as there's nothing wrong with:

  for (unsigned i = 0; i <= v.size(); ++i)
std::cout << i;

It's only a problem if you do v[i] when i == v.size()

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to David Binderman from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > And for this example it's possible that g(int) modifies the vector that the
> > reference v is bound to
> 
> I doubt g can modify v.


Of course it can:


#include 

std::vector v;

void g(int i) {
  std::cout << i << '\n';
  if (i < 5)
v.push_back(i + 5);
}

int main()
{
  v = { 1, 10 };
  f1(v);
}

This is entirely valid. If linked to your code in comment 0 it has undefined
behaviour but that's because of your i <= size() not because of this code.



> Anyway, I think some progress could be made by finding the pattern
> 
> for (something = 0; something <= somethingElse.size(); ++ something)
> 
> at compile time, which is what the  static analyser 'cppcheck' seems to be
> doing.

That's what I said, it would have to be a special case built in to the
front-end.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
I can also see profiledbootstrap failure in:

.././../gcc/simplify-rtx.c:6021:12: error: ‘result_s’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
 return result_s;
^~~~

It worked with a revision from 3.3.2017, is it the same issue as seen by
Markus?

[Bug c++/79961] New: Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

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

Bug ID: 79961
   Summary: Should diagnose when '__nonnull__' attribute is
applied to implicit this argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

struct A
{
  A (const char *arg) __attribute__ ((__nonnull__ (1)));
  void foo (const char *arg) __attribute__ ((__nonnull__ (1)));
};

Above, nonnull(1) should have been nonnull(2), since argument 1 is the implicit
"this" pointer (which is always non-NULL anyway).

Unfortunately, G++ fails to help find the bug.

With GNU C++14 (GCC) version 7.0.1 20170307 (experimental):

 $ /opt/gcc/bin/g++ nonnull.cc -o nonnull -g3 -O2 -c -Wall -Wextra
 (no warnings)

Note Clang 3.7:

 $ clang++ nonnull.cc -o nonnull -c
 nonnull.cc:3:39: error: '__nonnull__' attribute is invalid for the implicit
this argument
   A (const char *arg) __attribute__ ((__nonnull__ (1)));
   ^~
 nonnull.cc:4:46: error: '__nonnull__' attribute is invalid for the implicit
this argument
   void foo (const char *arg) __attribute__ ((__nonnull__ (1)));
  ^~
 2 errors generated.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Oops, that was the previous diff, I meant to paste this (which constrains the
__enable_if_has_tuple_size to only be used when _Tp has no cv-quals, so we
avoid ambiguities):

--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct tuple_size;

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2313. tuple_size should always derive from integral_constant
   // 2770. tuple_size specialization is not SFINAE compatible
-  template
-struct __tuple_size_cv_impl { };

-  template
-struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
-: integral_constant::value> { };
+  template::type,
+  typename = typename enable_if::value>::type,
+  size_t = tuple_size<_Tp>::value>
+using __enable_if_has_tuple_size = _Tp;

-  // _GLIBCXX_RESOLVE_LIB_DEFECTS
-  // 2313. tuple_size should always derive from integral_constant
   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   /// Gives the type of the ith element of a given tuple type.
   template

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
This works around the ambiguity that PR 79960 describes:

--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct tuple_size;

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2313. tuple_size should always derive from integral_constant
   // 2770. tuple_size specialization is not SFINAE compatible
-  template
-struct __tuple_size_cv_impl { };

-  template
-struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
-: integral_constant::value> { };
+  template::value>
+using __enable_if_has_tuple_size = _Tp;

-  // _GLIBCXX_RESOLVE_LIB_DEFECTS
-  // 2313. tuple_size should always derive from integral_constant
   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   /// Gives the type of the ith element of a given tuple type.
   template

I think this might be a workable solution.

If we don't like it for C++14 we could conditionally use it just for C++17 for
now.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[palves at redhat dot com]

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

--- Comment #48 from Pedro Alves  ---
GDB is released separately from binutils though, and GDB 8.0 is going to branch
very soon.  IWBN to have this in the binutils-gdb repo by then.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to Jonathan Wakely from comment #3)
> And for this example it's possible that g(int) modifies the vector that the
> reference v is bound to

I doubt g can modify v.

Anyway, I think some progress could be made by finding the pattern

for (something = 0; something <= somethingElse.size(); ++ something)

at compile time, which is what the  static analyser 'cppcheck' seems to be
doing.

$ ~/cppcheck/trunk/cppcheck mar7a.cc
[mar7a.cc:22]: (error) Array 'a[10]' accessed at index 10, which is out of
bounds.
[mar7a.cc:12]: (error) When i==v.size(), v[i] is out of bounds.
$ 

No work required at run time, AFAIK.

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
It's possible this isn't a bug, and the partial specializations need to be
constrained to avoid the ambiguity (although both Clang trunk and EDG accept
the unconstrained cases, but Clang 3.x fails similarly to G++).

This works with any G++ version:

using size_t = decltype(sizeof(0));

struct true_type { static constexpr bool value = true; };
struct false_type { static constexpr bool value = false; };

template struct enable_if { };
template<> struct enable_if { using type = void; };
template using disable_if = typename enable_if::type;

template struct is_const : false_type { };
template struct is_const : true_type { };
template struct is_volatile : false_type { };
template struct is_volatile : true_type { };

template struct tuple_size;

template::value>
  using __has_tuple_size = T;

template
struct tuple_size>>> {
  static constexpr size_t value = tuple_size::value;
};

template
struct tuple_size>>> {
  static constexpr size_t value = tuple_size::value;
};

template
struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple { };
template struct tuple_size> {
  static constexpr size_t value = sizeof...(T);
};

static_assert( tuple_size>::value == 0, "" );  // OK
static_assert( tuple_size>::value == 0, "" ); // OK
static_assert( tuple_size>::value == 0, "" ); // OK

[Bug target/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 40924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40924&action=edit
gcc48-pr70549.patch

Bernd came up with this untested fix.  Isn't that something that should be done
on the trunk too?
Side note, the i386 backend has r <- F alternative in movsf and in that case
just converts the floating point SFmode constant into integer.  If aarch64
isn't able to set GPRs from arbitrary 32-bit constants, perhaps you could have
some constraint that would represent just the SFmode const_double operands that
after converting them into their memory representation can be loaded into a
register using a single insn.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

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

--- Comment #47 from Markus Trippelsdorf  ---
(In reply to Avi Kivity from comment #46)
> Hopefully, the fix can be propagated to gdb's demangler soon.

Unfortunately binutils 2.28 was released a few days ago.
The next release will be in August and will include the fix.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[a...@cloudius-systems.com]

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

--- Comment #46 from Avi Kivity  ---
Hopefully, the fix can be propagated to gdb's demangler soon.

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> These all fail for the same reason, and I think it's a FE bug.

Reported as PR 79960 (seems to be a regression since 4.9)

[Bug c++/79960] New: [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[redi at gcc dot gnu.org]

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

Bug ID: 79960
   Summary: [5/6/7 Regression] Class template partial
specializations for const volatile types don't match
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

using size_t = decltype(sizeof(0));

template struct tuple_size;

template::value>
  using __has_tuple_size = T;

template struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple { };
template struct tuple_size> {
  static constexpr size_t value = sizeof...(T);
};

static_assert( tuple_size>::value == 0, "" );  // OK
static_assert( tuple_size>::value == 0, "" ); // OK
static_assert( tuple_size>::value == 0, "" ); // FAIL



GCC trunk fails to match the specialization:

cv.cc:27:50: error: ambiguous template instantiation for ‘struct
tuple_size >’
 static_assert( tuple_size>::value == 0, "" ); // FAIL
  ^~
cv.cc:8:29: note: candidates are: template struct
tuple_size<__has_tuple_size > [with T = volatile tuple<>]
 template struct tuple_size> {
 ^
cv.cc:12:29: note: template struct
tuple_size<__has_tuple_size > [with T = const tuple<>]
 template struct tuple_size> {
 ^~~~
cv.cc:16:29: note: template struct
tuple_size<__has_tuple_size > [with T = tuple<>]
 template struct tuple_size> {
 ^~
cv.cc:27:52: error: incomplete type ‘tuple_size >’ used
in nested name specifier
 static_assert( tuple_size>::value == 0, "" ); // FAIL
^

[Bug c/79959] New: -Wimplicit-fallthrough doesn't recognize some more complex exit cases

[peter at eisentraut dot org]

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

Bug ID: 79959
   Summary: -Wimplicit-fallthrough doesn't recognize some more
complex exit cases
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at eisentraut dot org
  Target Milestone: ---

gcc-7 (Homebrew GCC 7-20170305_1) 7.0.1 20170305 (experimental)

Code:

#include 

int
main(int argc, char **argv)
{
switch (argc)
{
case 1:
do { if (__builtin_constant_p(20) && (20) >= 20) abort(); }
while(0);
default:
return 0;
}
}

gcc-7 -Wimplicit-fallthrough -O2 -c test.c
test.c: In function 'main':
test.c:9:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
   do { if (__builtin_constant_p(20) && (20) >= 20) abort(); } while(0);

I would expect no warning here.

This concoction is a macro expansion that intends to communicate "noreturn"
based on some constant argument value, and that generally works well for
avoiding uninitialized variable warnings and things like that, so the control
flow analysis is smart enough to recognize that this is an unconditional exit. 
But the fallthrough analysis doesn't appear to be that smart.  It only detects
a plain abort() or something like that.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
No, no change. I think we need to change the tuple_size specializations
to be incomplete when tuple_size is incomplete, even though that appears to
contradict the changes made by lwg 2770.

--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct tuple_size;

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2313. tuple_size should always derive from integral_constant
   // 2770. tuple_size specialization is not SFINAE compatible
-  template
-struct __tuple_size_cv_impl { };

-  template
-struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
-: integral_constant::value> { };
+  template::value>
+using __enable_if_has_tuple_size = _Tp;

-  // _GLIBCXX_RESOLVE_LIB_DEFECTS
-  // 2313. tuple_size should always derive from integral_constant
   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   /// Gives the type of the ith element of a given tuple type.
   template

But this also affects C++11 mode, so I'm still trying to understand all the
consequences of such a change. At the least, some tests need changing:


FAIL: 20_util/pair/astuple/astuple.cc (test for excess errors)
FAIL: 20_util/tuple/cv_tuple_size.cc (test for excess errors)
UNRESOLVED: 20_util/tuple/cv_tuple_size.cc compilation failed to produce
executable
FAIL: 20_util/tuple/tuple_size.cc (test for excess errors)
FAIL: 23_containers/array/tuple_interface/tuple_size.cc (test for excess
errors)

These all fail for the same reason, and I think it's a FE bug.

[Bug c++/79957] [C++] Zero-length array function parameters in templates should cause warning/substituion failure in pedantic mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I think the policy is that SFINAE contexts are always pedantic.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And for this example it's possible that g(int) modifies the vector that the
reference v is bound to, so the size could even change on every loop iteration.
So if we added some runtime checks to std::vector (maybe only enabled for
_FORTIFY_SOURCE) then the size() would need to be reloaded on every loop
iteration, it couldn't be hoisted out of the loop. So that also suggests it
would have to be a special case handled by the front end, just for
std::vector::size()

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The C++ front-end could be taught about std::vector::size() as a special case,
but that would only help that special case, it wouldn't help for
std::deque::size(), or boost::vector::size() or other types.

[Bug demangler/67264] Infinite recursion of demangler on fuzzed input

[trippels at gcc dot gnu.org]

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

Bug 70909 Summary: Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

   What|Removed |Added

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

[Bug demangler/67264] Infinite recursion of demangler on fuzzed input

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
Fixed.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #45 from Markus Trippelsdorf  ---
Fixed.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

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

--- Comment #44 from Markus Trippelsdorf  ---
Author: trippels
Date: Wed Mar  8 14:28:38 2017
New Revision: 245978

URL: https://gcc.gnu.org/viewcvs?rev=245978&root=gcc&view=rev
Log:
Fix PR demangler/70909 and 67264 (endless demangler recursion)

ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * include/demangle.h: Add d_printing to struct demangle_component
   and pass struct demangle_component as non const.

libiberty/ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * cp-demangle.c: Fix endless recursion. Pass
   struct demangle_component as non const.
   (d_make_empty): Initialize variable.
   (d_print_comp_inner): Limit recursion.
   (d_print_comp): Decrement variable.
   * cp-demint.c (cplus_demangle_fill_component): Initialize
   variable.
   (cplus_demangle_fill_builtin_type): Likewise.
   (cplus_demangle_fill_operator): Likewise.
   * testsuite/demangle-expected: Add tests.

Modified:
trunk/ChangeLog
trunk/include/demangle.h
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/cp-demint.c
trunk/libiberty/testsuite/demangle-expected

[Bug demangler/67264] Infinite recursion of demangler on fuzzed input

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Author: trippels
Date: Wed Mar  8 14:28:38 2017
New Revision: 245978

URL: https://gcc.gnu.org/viewcvs?rev=245978&root=gcc&view=rev
Log:
Fix PR demangler/70909 and 67264 (endless demangler recursion)

ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * include/demangle.h: Add d_printing to struct demangle_component
   and pass struct demangle_component as non const.

libiberty/ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * cp-demangle.c: Fix endless recursion. Pass
   struct demangle_component as non const.
   (d_make_empty): Initialize variable.
   (d_print_comp_inner): Limit recursion.
   (d_print_comp): Decrement variable.
   * cp-demint.c (cplus_demangle_fill_component): Initialize
   variable.
   (cplus_demangle_fill_builtin_type): Likewise.
   (cplus_demangle_fill_operator): Likewise.
   * testsuite/demangle-expected: Add tests.

Modified:
trunk/ChangeLog
trunk/include/demangle.h
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/cp-demint.c
trunk/libiberty/testsuite/demangle-expected

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The two cases are not equivalent, because the bounds of a[10] are known at
compile-time, but v.size() is not. The only way to know v.size() is with a
run-time check, which has a non-zero cost.

[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from amker at gcc dot gnu.org ---
> Fixed.  The failure on sparc-sun-solaris2.12 should be resolved by patch to
> PR77536.

It is indeed.

Thanks.
Rainer

[Bug c++/79727] -Wimplicit-fallthrough=3 doesn't seem to match any comments

[peter at eisentraut dot org]

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

Peter Eisentraut  changed:

   What|Removed |Added

 CC||peter at eisentraut dot org

--- Comment #3 from Peter Eisentraut  ---
My general impression is that level =2 looks for substring matches, like

 /* fall through because this code is weird */

whereas level =3 only looks for some exact strings, like

/* FALLTHROUGH */

This could be made clearer in the documentation.

[Bug tree-optimization/79958] New: Missed tree DSE

[jakub at gcc dot gnu.org]

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

Bug ID: 79958
   Summary: Missed tree DSE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

At -O3 in bar we have various dead temporaries, they don't have address taken
and so should be DSEd, but they aren't.  In foo which doesn't have the EH edges
this works well.

#include 
#include 
#include 

namespace
{
  struct bitarray
  {
bitarray(int i) : mSlice(i) {}
template
bitarray(const EXPR &expr) { mSlice = expr.slice(0); }
uint32_t
slice(ptrdiff_t index) const { if (index != 0) return 0; return mSlice; }
  private:
uint32_t mSlice;
  };
  template class OP>
  struct bit_binary_expr
  {
bit_binary_expr(const LEFT &left, const RIGHT &right) : mLeft(left),
mRight(right) {}
uint32_t slice(ptrdiff_t index) const { OP op; return
op(mLeft.slice(index), mRight.slice(index)); }
  private:
const LEFT &mLeft;
const RIGHT &mRight;
  };
  template
  bit_binary_expr
  operator &(const LEFT &left, const RIGHT &right) { return
bit_binary_expr(left, right); }
  template
  bit_binary_expr operator |(const LEFT &left,
const RIGHT &right)
  { return bit_binary_expr(left, right); }
  template
  struct bit_shift_left
  {
bit_shift_left(const OPERAND &operand, size_t nBits) : mOperand(operand),
mBits(nBits) {}
uint32_t slice(ptrdiff_t index) const
{
  const ptrdiff_t offset = mBits / 32;
  const size_t bits = mBits % 32;
  if (bits == 0)
return mOperand.slice(index - offset);
  else
return (mOperand.slice(index - offset) << bits) | (mOperand.slice(index
- offset - 1) >> (32 - bits));
}
  private:
const OPERAND &mOperand;
const size_t mBits;
  };
  template
  bit_shift_left operator <<(const OPERAND &operand, size_t nBits) {
return bit_shift_left(operand, nBits); }
}
struct Foo
{
  void write(const bitarray &);
};
void
foo(int i)
{
  Foo f;
  f.write(bitarray(( bitarray(i)  & bitarray(0x0001))) << 31) |
bitarray(0x4000)))
| bitarray(42) & bitarray(0x))) <<  8) |
bitarray(0x0080;
}
struct Bar
{
  ~Bar(void);
  void write(const bitarray &) /* throw() */;
};
void
bar(int i)
{
  Bar b;
  b.write(bitarray(( bitarray(i)  & bitarray(0x0001))) << 31) |
bitarray(0x4000)))
| bitarray(42) & bitarray(0x))) <<  8) |
bitarray(0x0080;
}

[Bug tree-optimization/79955] GLIBC build fails after r245840

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79955] GLIBC build fails after r245840

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Mar  8 14:10:47 2017
New Revision: 245976

URL: https://gcc.gnu.org/viewcvs?rev=245976&root=gcc&view=rev
Log:
2017-03-08  Richard Biener  

PR tree-optimization/79955
* tree-ssa-uninit.c (warn_uninitialized_vars): Do not warn
for accesses that are completely outside of the variable.

* gcc.dg/uninit-24.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-24.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug tree-optimization/79943] Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

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

Andrew Haley  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Haley  ---
Fixed.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Index: libgfortran/generated/parity_l8.c
===
--- libgfortran/generated/parity_l8.c   (revision 245968)
+++ libgfortran/generated/parity_l8.c   (working copy)
@@ -167,7 +169,7 @@ parity_l8 (gfc_array_l8 * const restrict
  base -= sstride[n] * extent[n];
  dest -= dstride[n] * extent[n];
  n++;
- if (n == rank)
+ if (n >= rank)
{
  /* Break out of the look.  */
  continue_loop = 0;

also avoids the warning (== exit conditions are sometimes hard to analyze
for niter analysis)

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 8 Mar 2017, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956
> 
> --- Comment #3 from Markus Trippelsdorf  ---
> Testcase that only warns with -O3

It also warns with -O1 and -Os (but not -O2).  At -O2 the function is
optimized to just

fn1 ()
{
  int n;
  int d[1];

   [0.01%]:
  c = 1;

   [100.00%]:
  goto ; [100.00%]
}

at -O3 we have peeled one iteration and are left with

fn1 ()
{
  int n;
  int d[1];
  int b.1_1;
  int _2;

   [0.01%]:
  n_4 = a;
  c = 1;
  _2 = d[0];
  b.1_1 = b;
  goto ; [100.00%]
... (similar to above)

Note the testcase doesnt' capture the specific case of a bogus
warning as it is in parity_l8.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|bootstrap   |libfortran
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
We do

  rank = GFC_DESCRIPTOR_RANK (array) - 1;
(expands to ((array)->dtype & 0x07) - 1 and thus is [-1, 6])

as result rank is one less than source rank(?) and

  for (n = 0; n < rank; n++)
{
  count[n] = 0;
  dstride[n] = GFC_DESCRIPTOR_STRIDE(retarray,n);
  if (extent[n] <= 0)
return;
}

thus we initialize up to dstride[5] (and we figure that out, peeling the
init loop completely and never initializing dstride[5]).

The innermost loop



  n = 0;
  while (count[n] == extent[n])
{
  /* When we get to the end of a dimension, reset it and increment
 the next dimension.  */
  count[n] = 0;
  /* We could precalculate these products, but this is a less
 frequently used path so probably not worth it.  */
  base -= sstride[n] * extent[n];
  dest -= dstride[n] * extent[n];
  n++;
  if (n == rank)
{
  /* Break out of the look.  */
  continue_loop = 0;
  break;
}
  else
{
  count[n]++;
  base += sstride[n];
  dest += dstride[n];
}
}

is peeled completely as well but we somehow are not able to optimize the
remaining

  if (rank == 6)

test to true as the dominating tests are in loops forming

  if (rank == 1)
;
  else
if (rank == 2)
   ;
else
  if (rank == 3)
...
if (rank == 6)

and that's too complicated for us to analyze.

Note that with LIM enabled we run into the issue that LIM happily hoists
uninitialized reads (kind of PR39612).  So we'd have to optimize this
before LIM runs (VRP1) where we end up with

rank_396: [-1, 6]  EQUIVALENCES: { rank_111 rank_387 rank_391 rank_392 rank_393
rank_394 rank_395 } (7 elements)

which is ok (all equivalences have the same range).  Ideally it would be
[-1, 0] U [6, 6] but then the cases -1 and 0 still would not allow this to
be optimized.

Note that the retarray->base_addr == NULL case explicitely accesses
extent[rank - 1] which means that rank != 0 as well.  But nothing tells
GCC about this (retarray->base_addr may not actually be NULL).

Index: libgfortran/generated/parity_l8.c
===
--- libgfortran/generated/parity_l8.c   (revision 245968)
+++ libgfortran/generated/parity_l8.c   (working copy)
@@ -54,6 +54,8 @@ parity_l8 (gfc_array_l8 * const restrict
   /* Make dim zero based to avoid confusion.  */
   dim = (*pdim) - 1;
   rank = GFC_DESCRIPTOR_RANK (array) - 1;
+  if (rank < 1)
+runtime_error ("oops");

   len = GFC_DESCRIPTOR_EXTENT(array,dim);
   if (len < 0)

fixes this (and the warning).

Can fortran people please fix this?

[Bug c++/77772] Segmentation fault when running an application with gdb

[Jose.DiazdeGrenu at digi dot com]

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

--- Comment #7 from Jose.DiazdeGrenu at digi dot com ---
Seems like this has been fixed in gdb 7.11.

Could you point to the commit that fixes it? Has it been backported to gdb 7.9?

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[dvyukov at google dot com]

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

--- Comment #6 from Dmitry Vyukov  ---
Just build kernel with it. Boots fine and sustains some load now.
Did not do any positive tests, though.
Thanks for the quick fix!

[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg00334.html

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Jakub Jelinek  ---
Created attachment 40923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40923&action=edit
gcc7-pr79944.patch

Untested fix.

[Bug bootstrap/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Testcase that only warns with -O3

int a, b, c;
void fn1() {
  int d[1];
  int e, n = a;
  for (; 0; n++)
;
  c = 1;
  while (c) {
if (a)
  for (;;)
;
while (d[0]) {
  e -= 0;
  if (b)
break;
}
  }
}

% gcc -c -Wall -Wextra -O2 parity_l8.i -Werror -Wfatal-errors
% gcc -c -Wall -Wextra -O3 parity_l8.i -Werror -Wfatal-errors
parity_l8.i: In function ‘fn1’:
parity_l8.i:12:13: error: ‘d[0]’ is used uninitialized in this function
[-Werror=uninitialized]
 while (d[0]) {
~^~~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors

% clang -c -Wall -Wextra -O3 parity_l8.i -Werror -Wfatal-errors
% clang --analyze -c -Wall -Wextra -O3 parity_l8.i -Werror -Wfatal-errors
parity_l8.i:4:14: warning: Value stored to 'n' during its initialization is
never read
  int e = 0, n = a;
 ^   ~
parity_l8.i:12:12: warning: Branch condition evaluates to a garbage value
while (d[0]) {
   ^~~~
2 warnings generated.

[Bug bootstrap/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Created attachment 40922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40922&action=edit
unreduced testcase

[Bug tree-optimization/79943] Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

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

--- Comment #1 from Andrew Haley  ---
Author: aph
Date: Wed Mar  8 11:35:23 2017
New Revision: 245974

URL: https://gcc.gnu.org/viewcvs?rev=245974&root=gcc&view=rev
Log:
2017-03-08  Andrew Haley  

PR tree-optimization/79943
* tree-ssa-loop-split.c (compute_new_first_bound): When
calculating the new upper bound, (END-BEG) should be added, not
subtracted.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79943.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-split.c

[Bug c++/79957] New: [C++] Zero-length array function parameters in templates should cause warning/substituion failure in pedantic mode

[felix.morgner at gmail dot com]

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

Bug ID: 79957
   Summary: [C++] Zero-length array function parameters in
templates should cause warning/substituion failure in
pedantic mode
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.morgner at gmail dot com
  Target Milestone: ---

According to ISO14882 [dcl.array] zero-length arrays are not allowed:

...
If the constant-expression (5.19) is present, it shall be a converted constant
expression of type std::size_t and its value shall be greater than zero.
...

GCC generally accepts zero-length arrays as an extension. However, it does
handle them inconsitently when compiling in pedantic mode. The following code
compiles fine in pedantic mode (for all code samples, the following flags are
used: -Wall -Wextra -Werror -pedantic-errors):

  template
  void fun(int [N] = {}) {
  }

  int main() {
fun<0>();
  }

even though the parameter of fun will be a zero-length array. On the other
hand, the following code does not compile in pedantic mode:

  void fun(int [0] = {}) {
  }

  int main() {
fun();
  }

with the expected error message:

  array.cpp:1:21: error: ISO C++ forbids zero-size array [-Wpedantic]
   void fun(int [0] = {}) {

Interestingly, the following code fails to compile as expected:

  template
  void fun(int (*)[N] = {}) {
  }

  int main() {
fun<0>();
  }

This incosistency leads to GCC interpreting the following code as being
ambiguous:

  template
  void fun(int [N + 1] = {}, int = 0) {
  }

  template
  void fun(int [N] = {}) {
  }

  int main() {
fun<0>();
  }

Handling zero-length array parameters in templates as invalid, when in pedantic
mode, would make GCC SFINAE away the second fun(...).

Both 'clang' and Microsoft's 'cl' handle zero-length arrays as expected.

[Bug c++/79900] [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
reduced test case:

template  struct A;
template  struct B {
  long _M_off;
  int _M_state;
};
template <> struct A { typedef B pos_type; };
enum _Ios_Openmode {};
struct C {
  typedef _Ios_Openmode openmode;
};
template  struct D {
  typedef typename _Traits::pos_type pos_type;
  pos_type m_fn1(pos_type, C::openmode);
};
template class D>;
template 
typename D<_CharT, _Traits>::pos_type D<_CharT, _Traits>::m_fn1(pos_type,
C::openmode) {}