[Bug c++/96852] New: Missing diagnostic message for friend declaration with wrong number of template arguments.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 96852
   Summary: Missing diagnostic message for friend declaration with
wrong number of template arguments.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Program (main.cpp):

  template
  class A
  {
  };

  class B
  {
  template
  friend class ::A;
  };

  int main()
  {
  }

Compilation command line:

  g++ -std=c++17 -pedantic-errors main.cpp

Observed behaviour:

  No compilation errors.

Expected behaviour:

  Compilation error about using the wrong number of template arguments in the
  firend declaration.

Note:

  clang++ gives the expected error message.

[Bug c++/96884] New: Missing diagnostics when applying the member operator on this in class template

[anders.granlund.0 at gmail dot com]

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

Bug ID: 96884
   Summary: Missing diagnostics when applying the member operator
on this in class template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Program (main.cpp):

  template
  class V
  {
  int *a;
  void f()
  {
  this.a = 0;
  }
  };

  int main()
  {
  }

Compilation command line:

  g++ -std=c++17 -pedantic-errors main.cpp

Observed behaviour:

  No compilation errors.

Expected behaviour:

  Compilation error about incorrectly trying to use the member operator (.)
instead of (->) on the this keyword.

Note:

  clang++ gives the expected error message.

[Bug c++/96957] New: No name-lookup into base class when using an non dependent base class via template alias with dummy parameter.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 96957
   Summary: No name-lookup into base class when using an non
dependent base class via template alias with dummy
parameter.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following c++ program:

  class A
  {
  protected:
  int x;
  };

  template
  using B = A;

  template
  class C : public B
  {
  public:
  void f()
  {
  x = 0;
  }
  };

  int main()
  {
  }

Compile it with "-std=c++17 -pedantic-errors".

Expected behaviour:

  Since the base class is not dependent (see http://wg21.link/cwg1390 ) the
  name lookup of x should succeed and no error message should be outputed
  during the compilation.

Observed behaviour:

  An compilation error about failing the name lookup of x was outputed during
  the compilation.

GCC is correctly compiling the program with no error messages outputed. See the
discussion in: https://bugs.llvm.org/show_bug.cgi?id=47435

[Bug c++/96957] No name-lookup into base class when using an non dependent base class via template alias with dummy parameter.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Also see the following stack overflow post:

https://stackoverflow.com/questions/63761866/difference-in-behaviour-between-clang-and-gcc-when-trying-to-confuse-them-by-usi

[Bug c++/96957] No name-lookup into base class when using an non dependent base class via template alias with dummy parameter.

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
Correction to my first comment:

"GCC is correctly compiling the program with no error messages outputed. See
the discussion in: https://bugs.llvm.org/show_bug.cgi?id=47435";

should be:

"Clang is correctly rejecting the program with a error message outputed. See
the discussion in: https://bugs.llvm.org/show_bug.cgi?id=47435";

[Bug c++/96884] Missing diagnostics when applying the member operator on this in class template

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #2 from Anders Granlund  ---
Yes. You are correct this is not a bug. The standard allows both possibilities
in this case.

[Bug c/88477] New: Variable with type completed in initializer not allowed.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88477
   Summary: Variable with type completed in initializer not
allowed.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program (prog.c):

  int main()
  {
struct S s = (struct S { int x; }) { .x = 1 };
  }

The type of s is completed in the initializer, so this should be legit.

I get an unexpected error however when compiling with the following command
line:

  gcc prog.c -std=c11 -pedantic-errors 

Note that clang compiles this program without any errors.

Link to online compiler:

  https://wandbox.org/permlink/WyMDk6tDyTwORPVp

[Bug c/88477] Variable with type completed in initializer not allowed.

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
To what part of the standard are you refering to?

This is what I found and it allows the given program:

  C11 standard 6.7.7: https://port70.net/~nsz/c/c11/n1570.html#6.7p7

[Bug c/88477] Variable with type completed in initializer not allowed.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
In general the standard seems to be a bit inprecise when it talks about types
beeing complete.

The same type may be incomplete at one point in the program, but complete at
another point. The standard should always specify at what point in the program
a type needs to be complete when it requires it to be complete.

I will file a defect report about that instead.

[Bug c/88525] New: gcc thinks that C11 program does not declare anything but it does.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88525
   Summary: gcc thinks that C11 program does not declare anything
but it does.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following C11 program (prog.c):

  int main()
  {
struct { enum { a } b; };
  }

This program does NOT violate rule 6.7.2 in the C11 standard since the
declaration declares a member of an enum (a).

I tried to compile it with the following command line:

  gcc prog.c -std=c11 -pedantic-errors

I get the following unexpected error message:

  error: unnamed struct/union that defines no instances

This is wrong. The declaration does declare the enum member  a  and according
to the C11 standard it does not need to declare anything else.

[Bug c/88526] New: gcc accepts ill-formed program with sizeof (int [*])

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88526
   Summary: gcc accepts ill-formed program with sizeof (int [*])
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following C11 program (prog.c):

  void f(int a[sizeof(int [*])]);

  int main()
  {
  }

Compiling it with

  gcc prog.c -std=c11 -pedantic-errors

gives no errors. The expected behaviour is that it should compile with at least
one error. This becuase the flag  -pedantic-errors  was used and because the
program is incorrect according to the C11 standard (taking sizeof int [*]
should not be possible since it is not a complete type).

[Bug c/88526] gcc accepts ill-formed program with sizeof (int [*])

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
Thanks for the clarification.

I'll report this bug for clang instead.

[Bug c/88525] gcc thinks that C11 program does not declare anything but it does.

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
Thanks for the explanation. That makes sense.

[Bug c/88525] gcc thinks that C11 program does not declare anything but it does.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
This is a defect in the standard.

[Bug c/88526] gcc accepts ill-formed program with sizeof (int [*])

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
This is not a bug in gcc. It is clang that has the incorrect behaviour.

[Bug c/88477] Variable with type completed in initializer not allowed.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #6 from Anders Granlund  ---
The standard is a bit unclear, but that seems like a reasonable interpretation
of it.

[Bug c/88581] New: GCC thinks that

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88581
   Summary: GCC thinks that
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

[Bug c/88582] New: GCC does not unqualify return types in the case of _Atomic qualified return type.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88582
   Summary: GCC does not unqualify return types in the case of
_Atomic qualified return type.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main()
  {
typedef _Atomic int f();
typedef int f();
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  The following error message was outputed:

error: conflicting types for 'f'

Expected behaviour:

  No error message. Return types of function types are always unqualified, so
  both typedefs defines f to be the same type: 'int ()'.

References to the standard:

  6.7.6.5 ( "... returning the unqualified version of T" )

[Bug c/88584] New: GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88584
   Summary: GCC thinks that the type is complete dispite
shaddowing.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test program (prog.c):

  int a[1] = { 0 };

  int main()
  {
int a;
{
  extern int a[];
  sizeof (a);
}
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed behaviour:

  No error messages are outputed.

Expected behaviour:

  An error message. Because the file scope declaration is shaddowed  a  should
  not have a complete type in  sizeof (a).

Note:

  Clang outputs the expected error message for the program.

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
By "merging" i suppose you mean the process described at 6.2.7.4 in the
standard:

"For an identifier with internal or external linkage declared in a scope in
which
 a prior declaration of that identifier is visible, if the prior declaration
 specifies internal or external linkage, the type of the identifier at the
later
 declaration becomes the composite type."

Note that the declaration  int a[1] = { 0 };  is not visible to the declaration
extern int a[];  because of the shaddowing done by the declaration  int a; .

Therefore the "merging" is not done and  a  have the incomplete type  int [] 
in  sizeof (a) .

Becuase of this I still think that GCC is wrong here.

[Bug c/88581] GCC thinks that

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
Yes. That is correct.

[Bug c/88582] GCC does not unqualify return types in the case of _Atomic qualified return type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
Quote from the C17 standard (the bugfix version of C11) 6.7.6.3/5:

  If, in the declaration “T D1”, D1 has the form D(parameter-type-list) or
  D(identifier-list[opt]) and the type specified for ident in the declaration
  “T D” is “derived-declarator-type-list T”, then the type specified for ident
  is “derived-declarator-type-list function returning the unqualified version
of
  T”.

Note that the return type is specified as "the unqualified version of T".

Latest draft of the C17 standard (the bugfix for C11):

  http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to Andrew Pinski from comment #3)
> http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_011.html

To me it looks like the resolution of that defect report (and the current
wording of the standard) indicates that the current behaviour of GCC for my
test program (prog.c) is not correct.

The declaration  int a[1] = { 0 };  is not visible (because of shaddowing by  
int a; ) to  the declaration extern int a[];

[Bug c/88625] New: c11: GCC Allows enumerator value not representable in type int.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88625
   Summary: c11: GCC Allows enumerator value not representable in
type int.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  enum E { x = UINT_MAX };

  int main()
  {
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error message outputed.

Expected behaviour:

  An error message outputed.

  The value of the integer constant expression UINT_MAX is not representable
  as an int. This is not allowed.

Reference to the c11 standard (the bugfix version of the c11 standard):

  6.7.2.2/2:

"The expression that defines the value of an enumeration constant shall be
 an integer constant expression that has a value representable as an int."

Note:

  Clang gives the expected error.

[Bug c/88625] c11: GCC Allows enumerator value not representable in type int.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Forgot to include the include of a header file in the test case:

  #include 

  enum E { x = UINT_MAX };

  int main()
  {
  }

[Bug c/88642] New: Accepts ill-formed program with invalid scalar initialization syntax.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88642
   Summary: Accepts ill-formed program with invalid scalar
initialization syntax.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test program (test.c):

  int main()
  {
int x = { { 0 } };
  }

Compilation command line:

  clang prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error message outputed. Only warning messages outputed.

Expected behaviour:

  An error message outputed.

  The initalizer  0  or  { 0 }  is valid according to 6.7.9/11, but not
  { { 0 } } .

Note:

  Clang gives the expected error message for the program.

[Bug c/88582] GCC does not unqualify return types in the case of _Atomic qualified return type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
Probably a defect in the standard.

The behaviour seems reasonable since the  _Atomic  type qualifier is different
from the other type qualifiers in that it may change the size, represenation
and alignment of a type.

[Bug c/88647] New: Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88647
   Summary: Rejects valid program dereferencing pointer with
incomplete reference type.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  struct S *p;

  void f(void);

  int main()
  {
f();

*p;
  }

  struct S { int x; };

  void f()
  {
static struct S s = { 0 };
p = &s;
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  The following error message was outputed:

prog.c: In function 'main':
prog.c:10:5: error: dereferencing pointer to incomplete type 'struct S'
   10 | *p;
  | ^~

Expected behaviour:

  No error message outputed.

  I can't find anything in the standard that makes the this program invalid.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #2 from Anders Granlund  ---
Thanks. That explains it.

[Bug c/88582] GCC does not unqualify return types in the case of _Atomic qualified return type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #5 from Anders Granlund  ---
Thanks for the explanation.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
What about this modified test case?

  struct S *p;

  void f(void);

  int main()
  {
f();

&*p;
  }

  struct S { int x; };

  void f()
  {
static struct S s = { 0 };
p = &s;
  }

It gives the same error message (using the same compilation command line), and
there is no lvalue to rvalue conversion of *p in this case, because of the
operator & .

Clang accept that test case without any errors.

[Bug c/88667] New: Accepts program with invalid abstract-declarator grammar.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88667
   Summary: Accepts program with invalid abstract-declarator
grammar.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  void f(int [const *]);

  int main() {}

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error messages outputed.

Expected behaviour:

  An error message outputed.

  [const *]  is an invalid abstract-declarator according to the grammar in
6.7.7/1
  (no type qualifiers allowed in [*]).

[Bug c/88667] Accepts program with invalid abstract-declarator grammar.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #2 from Anders Granlund  ---
Thanks for the explanation.

[Bug c/88674] New: GCC thinks that register is a qualifier in function declaration with no parameters.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88674
   Summary: GCC thinks that register is a qualifier in function
declaration with no parameters.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  void f(register void);

  int main()
  {   
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed behaviour:

  The following error message was outputed:

prog.c:1:8: error: 'void' as only parameter may not be qualified
1 | void f(register void);
  |^

Expected behaviour:

  No error message outputed.

  The program is valid.  register  is not a type qualifier.

Note:

  Clang accepts the program without outputing any error message.

[Bug c/88674] GCC thinks that register is a qualifier in function declaration with no parameters.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #2 from Anders Granlund  ---
Thanks for the explanation.

[Bug c/88695] New: Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88695
   Summary: Accepts invalid program with incompatible function
types.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  void f()
  {
  }

  int main()
  {
void (*g)(int) = 0;
&f == g;
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error messages outputed.

Expected behaviour:

  An error message outputed.

  The program is invalid due to the following paragraphs of the standard:

  6.5.9/2:

  "One of the following shall hold:
   —  both operands have arithmetic type;
   —  both operands are pointers to qualified or unqualified versions of
  compatible types;
   —  one operand is a pointer to an object type and the other is a pointer to
a 
  qualified or unqualified version of void; or
   —  one operand is a pointer and the other is a null pointer constant."

  6.7.3/15:

  "... If one type has a parameter type list and the other type is specified by
   a function definition that contains a (possibly empty) identifier list, both
   shall agree in the number of parameters, and the type of each prototype
   parameter shall be compatible with the type that results from the
application
   of the default argument promotions to the type of the corresponding
   identifier. ..."

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Correction:

The second standard reference should be 6.7.6.3/15 and not 6.7.3/15.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
Yes, the type of  f  does have a prototype.

That fact is however not relevant here.

Note that I'm not making any calls to  f  here. I am only using  f  in a way
that requires its type to be compatible with  void (int) .

The prototype mentioned in 6.7.3/15 refers to the prototype of the type  void
(int)  in this case.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #2)
> See PR 64526 and DR 317.

(Forgot to reply instead of adding an additional comment)

Yes, the type of  f  does have a prototype.

That fact is however not relevant here.

Note that I'm not making any calls to  f  here. I am only using  f  in a way
that requires its type to be compatible with  void (int) .

The prototype mentioned in 6.7.3/15 refers to the prototype of the type  void
(int)  in this case.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to jos...@codesourcery.com from comment #1)
> 6.3.2.1#2 (conversion of lvalues to rvalues): "If the lvalue has an 
> incomplete type and does not have array type, the behavior is undefined.".  
> Cf. bug 36941 (noting how DR#106 confuses things by allowing dereferences 
> of pointers to qualified void).

(Incorrectly added an additional comment instead of replying)

What about this modified test case?

  struct S *p;

  void f(void);

  int main()
  {
f();

&*p;
  }

  struct S { int x; };

  void f()
  {
static struct S s = { 0 };
p = &s;
  }

It gives the same error message (using the same compilation command line), and
there is no lvalue to rvalue conversion of *p in this case, because of the
operator & .

Clang accept that test case without any errors.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #6 from Anders Granlund  ---
Thanks for the explanation.

[Bug c/88701] New: Internal compiler error for valid program using compound literal with variably modified type.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88701
   Summary: Internal compiler error for valid program using
compound literal with variably modified type.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  void f(int [(int (*)[*]) { 0 } == 0]);

  int main()
  {
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  Internal compiler error.

[Bug c/88701] Internal compiler error for valid program using compound literal with variably modified type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Another test case that also gives internal compiler error with the same
compilation command line:

  void f(int n, int [(int (*)[n]) { 0 } == 0]);

  int main()
  {
  }

[Bug c/88701] [9 Regression] Internal compiler error for valid program using compound literal with variably modified type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
Thanks for the bisect.

[Bug c/88704] New: Accepts invalid program with [*] outside function prototype scope.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88704
   Summary: Accepts invalid program with [*] outside function
prototype scope.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  void f(a)
int a[*];
  {
  }

  int main()
  {
  }

Compilation command line:

  gcc prog.c -std=c11 -pedantic-errors 

Observed behaviour:

  No error message outputed.

Expected behaviour:

  An error message outputed.

  The program is invalid because [*] occurs outside function prototype scope.

Note:

  Clang gives the expected error message.

[Bug c/88716] New: Improved diagnostics: No detection of conflicting function definitions in some cases.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88716
   Summary: Improved diagnostics: No detection of conflicting
function definitions in some cases.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following two test cases (prog1.c):

  void f(x)
int x;
  {
  }

  void f(int, int);

  void f();

  int main() {}

and (prog2.c):

  void f(x)
int x;
  {
  }

  void f();

  void f(int, int);

  int main() {}

Both have compile time undefined behaviour because of conflicting declarations
of the function f.

The only difference between them is the reordering of the two last
declarations.

When the first test case is compiled with 

  gcc prog1.c -Wall -Wextra -std=c11 -pedantic-errors

The undefined behaviour is detected and an error message is outputed.

When the second test case is compiled with

  gcc prog2.c -Wall -Wextra -std=c11 -pedantic-errors

The undefined behaviour is not detected.

It would be good if gcc could detect the undefined behaviour even in the second
case.

[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.

[anders.granlund.0 at gmail dot com]

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

--- Comment #7 from Anders Granlund  ---
(In reply to jos...@codesourcery.com from comment #6)
> This looks like a case that was missed in, or broken by, my fix for bug 
> 13801, which was supposed to address such cases of entities with different 
> (compatible) types in different scopes.  It seems GCC handled this 
> correctly (i.e. produced an error) in the 3.4 release series only.

Does this mean that we can change the status for this bug report from
UNCONFIRMED to NEW?

[Bug c/88718] New: Strange inconsistency between old style and new style declarations of iinline functions.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88718
   Summary: Strange inconsistency between old style and new style
declarations of iinline functions.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

GCC is behaving inconsistently for the following two test cases:

prog1.c:

  static int x;

  inline void g(int a[sizeof(x)])
  {
  }

  int main()
  {
  }

prog2.c:

  static int x;

  inline void g(a)
int a[sizeof(x)];
  {
  }

  int main()
  {
  }

Compiling the first test case with the following compilation command line

  gcc prog1.c -Wall -Wextra -std=c11 -pedantic-errors 

gives no error message.

Compiling the second test case with the following compilation command line

  gcc prog2.c -Wall -Wextra -std=c11 -pedantic-errors 

gives the following error message:

  error: 'x' is static but used in inline function 'g' which is not static

I think there should be an error message in both cases because of 6.7.4/3. At
least the two test cases should behave consistently.

[Bug c/88720] New: Strange error message about nested function declared but not defined when using inline.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88720
   Summary: Strange error message about nested function declared
but not defined when using inline.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  static void f();

  int main()
  {
inline void f();
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed behaviour:

  The following error message was outputed:

error: nested function 'f' declared but never defined

Expected behaviour:

  No error message outputed.

Note:

  Clang accepts the program without any error message outputed.

[Bug c/88726] New: GCC thinks that translation unit does not contain a definition of inline function.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88726
   Summary: GCC thinks that translation unit does not contain a
definition of inline function.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (test.c):

  int main()
  {
extern inline void f();
  }

  void f()
  {
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed beaviour:

  The following error message was outputed:

error: inline function 'f' declared but never defined

Expected behaviour:

  No error message outputed.

Note:

  Clang accepts the program without any error message outputed.

[Bug c/88727] New: Diagnostics improvement: Detection of undefined behaviour. Incomplete type in tenative definition with internal linkage.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88727
   Summary: Diagnostics improvement: Detection of undefined
behaviour. Incomplete type in tenative definition with
internal linkage.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  static struct S s;

  int main()
  {
  }

  struct S { int x; };

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed behaviour:

  No error messages outputes.

Possible improvement of behaviour:

  Outputing an error message about using an incomplete type in the tenative
  definition  static struct S s; .

  The program has undefined behaviour becuase of a violation of 6.9.2/2:

  "If the declaration of an identifier for an object is a tentative definition
   and has internal linkage, the declared type shall not be an incomplete
type."

  GCC detects such undefined behaviour in other cases (for example using the 
  incomplete type int []). It would be good if it could also hande the case in
  the test case for this bug report.

Note:

  Clang detects the undefined behaviour for this program and outputs an error
  message.

[Bug c/88731] New: Rejects well-formed program using bit-fields in _Generic.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88731
   Summary: Rejects well-formed program using bit-fields in
_Generic.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main()
  {
struct S { unsigned x:4; } s;

_Generic(s.x, unsigned: 0);
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  The following error message is outputed:

error: '_Generic' selector of type 'unsigned char:4' is not compatible
   with any association

Expected behaviour:

  No error message outputed.

  See http://www.open-std.org/Jtc1/sc22/wg14/www/docs/summary.htm#dr_481:

"... It was noted that bitfields are of integer type. ..."

Note:

  Clang accepts the program without any error message.

[Bug c/88774] New: Qualification of parameters does not change a function type: Bug or standard defect?

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88774
   Summary: Qualification of parameters does not change a function
type: Bug or standard defect?
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main(void)
  {
typedef void f(int);
typedef void f(const int);
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed behaviour:

  No error messages outputed.

Question:

  The function types in the two typedefs are compatible, but are they distinct?

  The standard is not very clear on this.

  If the two function types are distinct the expected behaviour is to get an 
  error message about redeclaring the typedef name  f  with a different type.

  Else the observed behaviour is expected and there is no bug.

[Bug c/88774] Qualification of parameters does not change a function type: Bug or standard defect?

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
Ok. Thanks for the answers.

[Bug c/88817] New: Diagnostics improvement: Does not detect attempt to use void expression in some cases.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88817
   Summary: Diagnostics improvement: Does not detect attempt to
use void expression in some cases.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  extern void v;

  int main(void)
  {
_Generic(v, default: 0);
  } 

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error messages outputed.

Possible improvement:

  The program has undefined behaviour because it attempts to use the void
  expression  v  (as the controlling expression of _Generic).

  Since GCC detects attempts to use void expressions in other case it would be
  good if it detected it in this case also.

[Bug c/88704] Accepts invalid program with [*] outside function prototype scope.

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
(In reply to Martin Sebor from comment #2)
> Confirmed, although I'd be more inclined to invest energy into including
> -Wstrict-prototypes in -Wall or -Wextra than into diagnosing the VLA in
> K&R-style definitions.

Yeah, probably not worth fixing since K&R-style function definitions is an
obsolencent feature.

[Bug c/88731] [DR 481] Rejects well-formed program using bit-fields in _Generic.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
(In reply to jos...@codesourcery.com from comment #2)
> GCC makes the integer type of the bit-field in question "unsigned:4".  
> See DR#315 (also, see the line of C90 DRs that led to the wording changes 
> in C99 relating to types of bit-fields, references in 
> ).

Thanks for the explanation.

[Bug c/88822] New: Strange inconsistency between types of qualified rvalues.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88822
   Summary: Strange inconsistency between types of qualified
rvalues.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main()
  {
int * const p1 = 0;
int *   _Atomic p2 = 0;
int * const _Atomic p3 = 0;

struct S { int x; } s;

s = &*p1; // Type of  &*p1  is  int * const  according to error message.
s = &*p2; // Type of  &*p2  is  int *according to error message.
s = &*p3; // Type of  &*p3  is  int *according to error message.
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observations:

  The following error messages are outputed:

incompatible types when assigning to type 'struct S' from type 'int *
const'
incompatible types when assigning to type 'struct S' from type 'int *'
incompatible types when assigning to type 'struct S' from type 'int *'

  From the error messages it looks like GCC thinks that the type of  &*p1  is
  int * const  and that the types of  &*p2  and  &*p3  are both  int * .

  So it seems like if the  _Atomic  qualifier is used, all qualifiers are
  removed, else they are keept.

  6.5.3.2/3 describing the special case of  &*  does not say anything about
  droping any qualifiers. However since the result of  &*  is an rvalue the
  intention of the standard was probably to remove all qualifiers always.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #5 from Anders Granlund  ---
Invalid, but will open another bug case with a different test case.

[Bug c/88827] New: Rejects valid program using &* operator combination.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88827
   Summary: Rejects valid program using &* operator combination.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main()
  {
struct S *p = 0;
&*p;
  } 

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  The following error message was outputed:

error: dereferencing pointer to incomplete type 'struct S'

Expected behaviour:

  No error messages outputed. The program is valid. Note that using the value
  0 for pointer  p  is not a problem since neither & nor * is evaluated due to
  the special rule for &* in 6.5.3.2/3.

Note:

  Clang accepts the program without outputing any error messages.

[Bug c++/66878] New: Segmentation fault when compiling

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66878
   Summary: Segmentation fault when compiling
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Created attachment 35987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35987&action=edit
prog.cc used in the command line

With the attached file the following command results in an internal compiler
error:

gcc prog.cc

The output is:

gcc: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output for gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug c++/66879] New: Error message when defining a member function inside a class definition

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66879
   Summary: Error message when defining a member function inside a
class definition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Created attachment 35988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35988&action=edit
prog.cc used in the command line

Compile the attached program with the following command line:

gcc prog.cc

The output is the following:

prog.cc:6:22: error: definition of ‘void A::f()’ is not in namespace enclosing
‘A’ [-fpermissive]
 class A { void f() {} };
  ^

The expected behaviour is not to get this error message. The error message seem
to suggest that the compiler thinks that the program violates [class.mfct]/2
where one sentence says:

"A member function definition that appears outside of the class definition
shall appear in a namespace scope enclosing the class definition."

Observe however that the member function definition in the given program is
made inside the class definition.

Note that if we remove the member function definition in the given program it
compiles without errors.

Output of gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug c++/66879] Error message when defining a member function inside a class definition

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
Thanks for the comments! Now I remember the following bug report that I sent to
clang:

https://llvm.org/bugs/show_bug.cgi?id=24030

That bug has now been confirmed and fixed in clang, so yes this is the actual
bug and it should be fixed in gcc also.

[Bug c++/66888] New: Compiler accepting ill-formed program trying to define a struct via using-declaration

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66888
   Summary: Compiler accepting ill-formed program trying to define
a struct via using-declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Created attachment 35990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35990&action=edit
prog.cc used in the command line

The attached program is ill-formed according to the c++ standard.

This by the following clauses in the c++ standard:

* [class]p11 ( http://eel.is/c++draft/class#11 ):
Note especially the sentence "i.e., not merely inherited or introduced by a
using-declaration"

* [dcl.meaning]p1 ( http://eel.is/c++draft/dcl.meaning#1 ):
Not especially the sentence "the member shall not merely have been introduced
by a using-declaration in the scope of the class or namespace nominated by the
nested-name-specifier of the declarator-id."

When compiling with the following command line no error message is given:

gcc prog.cc

The expected behaviour is to get an error message since the program is
ill-formed.

Output from gcc -v is:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug c++/66889] New: Accepting ill-formed program trying to define a struct via using-directive

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66889
   Summary: Accepting ill-formed program trying to define a struct
via using-directive
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Created attachment 35991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35991&action=edit
prog.cc used in the command line

Compile the attached program with the following command line:

gcc prog.cc

No error output is given. The expected behaviour is to get an error. This
because the program is ill-formed according to the clause [class]p11 of the c++
standard:

http://eel.is/c++draft/class#11

Output for gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug c++/66878] Segmentation fault when compiling

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
The following bug that I also reported is related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888

[Bug c++/66892] New: Fix of core language defect 355 has status c++11 but is not implemented yet

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66892
   Summary: Fix of core language defect 355 has status c++11 but
is not implemented yet
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

The following core language defect has status c++11 but is not implemented yet:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#355

Without implementing this fix gcc doesn't fully support c++11 syntax.

[Bug c++/66900] New: No error message for ill-formed program with qualified name lookup

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66900
   Summary: No error message for ill-formed program with qualified
name lookup
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Created attachment 35998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35998&action=edit
prog.cc used in the command line

Compiled the attached ill-formed program with the following command line:

gcc prog.cc

It compiles without error. The expected behaviour is to get an error message
since the program is ill-formed by basic.lookup.qual]p1:

"... If a :: scope resolution operator in a nested-name-specifier is not
preceded by a decltype-specifier, lookup of the name preceding that ::
considers only namespaces, types, and templates whose specializations are
types. If the name found does not designate a namespace or a class,
enumeration, or dependent type, the program is ill-formed. ..."

http://eel.is/c++draft/basic.lookup.qual#1

For comparison Clang gives a compiler error.

Output for gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug c++/66901] New: Segmentation fault in compiler instead of error message for ill-formed program with namespace alias and qualified definition

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66901
   Summary: Segmentation fault in compiler instead of error
message for ill-formed program with namespace alias
and qualified definition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Created attachment 35999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35999&action=edit
The program prog.cc used in the command line

Compile the attached program prog.cc with the following command line:

gcc prog.cc

This results in a segmentation fault instead of an error message:

gcc: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Since the program is ill-formed and diagnostics is required, the expected
behaviour is to get an error message instead of a segmentation fault.

Output for gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug c++/66888] Compiler accepting ill-formed program trying to define a struct via using-declaration

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
This bug seems to be more general than struct definitions. It also exists for
variable declarations like this:

  namespace X { extern int i; }

  namespace N { using X::i; }

  int N::i = 1;

  int main() {}

The above program is ill-formed by [dcl.meaning]p1, but no error message is
given.

[Bug c++/66934] New: Compiler accepting ill-formed program with extern variable declarations and using-declaration

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66934
   Summary: Compiler accepting ill-formed program with extern
variable declarations and using-declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

The following program is ill-formed since the two declarations in main are
conflicting.

  namespace N {
  extern int x;
  }

  int main() {
  using N::x;
  extern int x;
  }

GCC compiles with program without errors. The expected behaviour is to get a
compiler error.

[Bug c++/66935] New: Compiler rejects well-formed program with local extern variable declaration and using-declaration

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66935
   Summary: Compiler rejects well-formed program with local extern
variable declaration and using-declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

The following program is well-formed. The two declarations in main are not
conflicting.

  int x = 1;

  int main() {
  extern int x;
  using ::x;
  }

The following output is given when compiling it:

  prog.cc: In function 'int main()':
  prog.cc:5:13: error: redeclaration of 'int x'
   using ::x;
   ^
  prog.cc:4:16: note: previous declaration 'int x'
   extern int x;
  ^

Expected behaviour is to get no error messages.

[Bug c++/66921] failure to determine size of static constexpr array that is nested within a templated class

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 CC||anders.granlund.0 at gmail dot 
com

--- Comment #1 from Anders Granlund  ---
Smaller test-case:

  template struct S { static constexpr int a[] {0}; };

  template struct S;

  int main() {}

[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #1)
> I think we could combine most of your reports into one or two PRs since
> they're all related and fixing them one by one would probably not be very
> efficient.

What is a PR?

[Bug c++/66966] New: Missing diagnostic message for ill-formed program with anonymous enum

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66966
   Summary: Missing diagnostic message for ill-formed program with
anonymous enum
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program (prog.cc):

  enum {};
  int main() {}

This is ill-formed according to [dcl.dcl]/5 of the c++ standard:

  http://eel.is/c++draft/dcl.dcl#5

Compile the program with the following command line:

  gcc prog.cc -std=c++98 -pedantic-errors -w

Observe that no diagnostic message is emitted. At least one diagnostic message
is expected since the program is ill-formed.

The bug 54216 that has been fixed seems to be similar. The difference is that
I'm using -w and -pedantic-errors. 

Could the bug be caused by a general problem of some errors getting hidden by
the combination -w and -pedantic-errors? I suspect this since I get the
following error message if I remove -w:

  error: ISO C++ forbids empty anonymous enum

Output for gcc -v (the problem seems to be quite independent of this however):

Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 6.0.0 20150721 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++98' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/cc1plus -quiet
-v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE prog.cc -quiet -dumpbase prog.cc
-mtune=generic -march=x86-64 -auxbase prog -std=c++98 -version -o
/tmp/ccHJNWUA.s
GNU C++98 (GCC) version 6.0.0 20150721 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 6.0.0 20150721 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/x86_64-unknown-linux-gnu

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/backward
 /usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/include
 /usr/local/include
 /usr/local/gcc-head/include
 /usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++98 (GCC) version 6.0.0 20150721 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 6.0.0 20150721 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 498fb50b10eacf300a28f79d04f435a8
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++98' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccpk87pk.o /tmp/ccHJNWUA.s
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.22
COMPILER_PATH=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std

[Bug c++/66966] Missing diagnostic message for ill-formed program with anonymous enum

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #2)
> Oh wait ... if you use -w then you are suppressing diagnostics, so you can't
> really complain that there are no diagnostics!
> 
> So this seems invalid to me.

Note that I'm having -pedantic-errors also.

[Bug c++/66966] Missing diagnostic message for ill-formed program with anonymous enum

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #2)
> Oh wait ... if you use -w then you are suppressing diagnostics, so you can't
> really complain that there are no diagnostics!
> 
> So this seems invalid to me.

In this case -w suppressed an error when combined with -pedantic-errors.
Shouldn't -w only suppress warnings?

[Bug c++/66966] Missing diagnostic message for ill-formed program with anonymous enum

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Anders Granlund  ---
I'm reopening this because of my latest comment.

[Bug c++/66966] Missing diagnostic message for ill-formed program with anonymous enum

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Anders Granlund  ---
OK. Seems to work differently in Clang but I guess they don't have the same
problem with legacy.

[Bug c++/66976] New: Compiler error for well-formed program with a definition of a constexpr function returning void

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66976
   Summary: Compiler error for well-formed program with a
definition of a constexpr function returning void
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

The following program (prog.cc in the command line below) is well-formed:

  constexpr void f() {}
  int main() {}

Note that the return type void is a literal type according to [basic.types]/10:

  http://eel.is/c++draft/basic.types#10

I compiled the program with the following command line:

  gcc prog.cc -std=c++11 -pedantic-errors

I expected to get no errors since the program is well-formed, but I got the
following error:

prog.cc: In function 'constexpr void f()':
prog.cc:1:16: error: invalid return type 'void' of constexpr function
'constexpr void f()'constexpr void f() {}
^

For comparison Clang accepts the program without errors.

Output for gcc -v (I think the bug quite independent of this however):

Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 6.0.0 20150722 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++11' '-pedantic-errors' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/cc1plus -quiet
-v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE prog.cc -quiet -dumpbase prog.cc
-mtune=generic -march=x86-64 -auxbase prog -pedantic-errors -std=c++11 -version
-o /tmp/ccE6wwKW.s
GNU C++11 (GCC) version 6.0.0 20150722 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 6.0.0 20150722 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/x86_64-unknown-linux-gnu

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/backward
 /usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/include
 /usr/local/include
 /usr/local/gcc-head/include
 /usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (GCC) version 6.0.0 20150722 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 6.0.0 20150722 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9115218d8690e08d2bbd8844106c0d12
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++11' '-pedantic-errors' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/cc8TSYhs.o /tmp/ccE6wwKW.s
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.22
COMPILER_PATH=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o'

[Bug c++/66995] New: First declaration as inline after definition of function

[anders.granlund.0 at gmail dot com]

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

Bug ID: 66995
   Summary: First declaration as inline after definition of
function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program (prog.cc):

  void f() {}
  inline void f();
  int main() {}

It is ill-formed by [dcl.fct.spec]/4 (http://eel.is/c++draft/dcl.fct.spec#4):

"If the definition of a function appears in a translation unit before its first
declaration as inline, the program is ill-formed."

Therefore I expected gcc to give at least one diagnostic message when compiling
it, but I get none with the following command line:

  g++ prog.cc -std=c++98 -pedantic-errors

I have tried with gcc HEAD 6.0.0 20150722 here:

  http://melpon.org/wandbox/permlink/c6wrML22huCFZMxp

[Bug c++/67006] New: type-specifier const in declaration of anonymous union

[anders.granlund.0 at gmail dot com]

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

Bug ID: 67006
   Summary: type-specifier const in declaration of anonymous union
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program (prog.cc):

const union {};
int main() {}

It is ill-formed by [dcl.type.cv] http://eel.is/c++draft/dcl.dcl#dcl.type.cv-1:

"If a cv-qualifier appears in a decl-specifier-seq, the init-declarator-list of
the declaration shall not be empty."

Compile the program with the following command line:

g++ prog.cc -std=c++14 -pedantic-errors

No error messages are given. I expected to get an error message here since the
program is ill-formed.

I tried this with gcc HEAD 6.0.0 201507, here:

http://melpon.org/wandbox/permlink/lGKyEQQW4BtKube9

[Bug c++/67008] New: Qualified name-lookup in using-declaration fails

[anders.granlund.0 at gmail dot com]

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

Bug ID: 67008
   Summary: Qualified name-lookup in using-declaration fails
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program:

  namespace N { int i; }
  using namespace N;
  using ::i;
  int main() {}

Compile it with the following command line:


Observe that the following error message is given:

  prog.cc:3:9: error: 'i' not declared
  using ::i;
  ^

The program is well-formed, so this error message is not expected. It seems
that the qualified name-lookup inside the using-declaration fails.

I tried it with gcc HEAD 6.0.0 201507 here:

  http://melpon.org/wandbox/permlink/immhNeWFCMcCA800

[Bug c++/67008] Qualified name-lookup in using-declaration fails

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Forgot the command line:

  g++ prog.cc -std=c++14 -pedantic-errors

[Bug c++/67010] New: Name hiding in the same declarative region fails when done via using-directive

[anders.granlund.0 at gmail dot com]

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

Bug ID: 67010
   Summary: Name hiding in the same declarative region fails when
done via using-directive
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following well-formed program:

  namespace N { struct x {}; }
  using namespace N;
  int x;
  int main() { sizeof (x); }

Compile it with the following command line:

  g++ prog.cc -std=c++14 -pedantic-errors

Observe that error messages about name lookup ambiguity are given. I expect to
get no errors when compiling since the program is well-formed.

That the program is well-formed can be seen by applying both [namespace.udir]/2
and [basic.scope.hiding]/2:

  http://eel.is/c++draft/dcl.dcl#namespace.udir-2
  http://eel.is/c++draft/basic.scope.hiding#2

This seems reasonable also, so I don't think this is a defect of the c++
standard.

I tried it with gcc HEAD 6.0.0 201507 here:

  http://melpon.org/wandbox/permlink/GmJgvsbjt5CPdWrA

[Bug c++/67013] New: Compilation error for well-formed program with empty declaration in the global namespace

[anders.granlund.0 at gmail dot com]

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

Bug ID: 67013
   Summary: Compilation error for well-formed program with empty
declaration in the global namespace
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program:

  int main() {};

It is well-formed, the extra semi colon is just an empty declaration after the
definition of main.

Compile it with the following command line:

  g++ prog.cc -std=c++14 -pedantic-errors

The following error message is then given:

  prog.cc:1:14: error: extra ';' [-Wpedantic]
  int main() {};
  ^

I expected to get no error messages since the program is well-formed. For
comparison Clang gives no error message.

I have tried it with gcc HEAD 6.0.0 201507 here:

  http://melpon.org/wandbox/permlink/gaOys1DxBYMnRWei

[Bug c++/67010] Name hiding in the same declarative region fails when done via using-directive

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Detailed explanation of how the c++ standard can be applied to the program:

By [namespace.udir]/2 during the unqualified name lookup of x in sizeof (x),
the declaration struct x {}; appears as if it was declared in the declarative
region of the global namespace, so the name lookup will appear to be affected
by the type of name hiding described in [basic.scope.hiding]/2. Because of this
name hiding we should not get any ambiguity in the name lookup.

[Bug c++/67016] New: Redeclaration of enum

[anders.granlund.0 at gmail dot com]

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

Bug ID: 67016
   Summary: Redeclaration of enum
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program:

  enum E {};
  enum E;
  int main() {}

Compile it with the following command line:

  g++ prog.cc -std=c++98 -pedantic-errors

No error messages are given. I expect to get at least one error message, since
the program is ill-formed according to the c++ standard, see [dcl.type.elab]/1:

  http://eel.is/c++draft/dcl.dcl#dcl.type.elab-1

I have tried compiling with gcc HEAD 6.0.0 20150725 here:

  http://melpon.org/wandbox/permlink/KtDN7vjZN3bc1gtc

[Bug c++/67013] Compilation error for well-formed program with empty declaration in the global namespace

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
That comment seems to be incorrect. The c++ standard has never forbidden empty
declarations at global namespace. I think we should get a warning instead of an
error.

[Bug c++/67017] New: Mixing init-declarator for variables and functions in declaration with auto type-specifier

[anders.granlund.0 at gmail dot com]

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

Bug ID: 67017
   Summary: Mixing init-declarator for variables and functions in
declaration with auto type-specifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program (prog.cc):

  auto i = 0, f();
  int main() {}

Compile it with the following command line:

  g++ prog.cc -std=c++14 -pedantic-errors

No error messages are given. I expect to get at least one error message since
the program is ill-formed.

The program is ill-formed by [decl.spec.auto]/8:

  http://eel.is/c++draft/dcl.dcl#dcl.spec.auto-8

  "If the init-declarator-list contains more than one init-declarator, they
shall all form declarations of variables."

I have tried this with gcc HEAD 6.0.0 20150725 here:

  http://melpon.org/wandbox/permlink/UaCnMgfMlG9nDqf3

[Bug c++/67016] Redeclaration of enum

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
(In reply to Andrew Pinski from comment #1)
> Looks like this changed between c++11 and c++98. 
> 
> Note you are quoting c++11 but compiling with c++98. 
> 
> Also this is a big incompatibility with c99 and a surprising one too.

The test case program has never been well-formed in any c++ standard. I'm just
quoting the latest standard since that is the one I have.

[Bug c++/67013] Compilation error for well-formed program with empty declaration in the global namespace

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #3)
> It might have changed between the ARM and C++98, but I haven't checked.

Is ARM a c++ standard before c++98?

[Bug c++/67017] Mixing init-declarator for variables and functions in declaration with auto type-specifier

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #1)
> EDG and Clang also accept this in C++14 mode (and like GCC, reject it in
> C++11 mode).

I think that is because type deduction for return types of functions was
introduced in c++14.

The following program is well-formed in c++14, but not in c++11:

auto f();
int main() {}

[Bug c++/67017] Mixing init-declarator for variables and functions in declaration with auto type-specifier

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #1)
> EDG and Clang also accept this in C++14 mode (and like GCC, reject it in
> C++11 mode).

(In reply to Anders Granlund from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > EDG and Clang also accept this in C++14 mode (and like GCC, reject it in
> > C++11 mode).
> 
> I think that is because type deduction for return types of functions was
> introduced in c++14.
> 
> The following program is well-formed in c++14, but not in c++11:
> 
> auto f();
> int main() {}

(In reply to Jonathan Wakely from comment #1)
> EDG and Clang also accept this in C++14 mode (and like GCC, reject it in
> C++11 mode).

It is interesting that the compilers seem to agree, looks like they all have
this bug. 

I noticed an interesting thing however. Consider this program:

auto i = 0, f();
auto f() { return false; }
int main() {}

Clang accepts it, but GCC rejects it (I didn't try EDG).

[Bug c++/67017] Mixing init-declarator for variables and functions in declaration with auto type-specifier

[anders.granlund.0 at gmail dot com]

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

--- Comment #5 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Anders Granlund from comment #3)
> > > I think that is because type deduction for return types of functions was
> > > introduced in c++14.
> 
> Yes, I understand why they reject it in C++11 mode, my point was that they
> all consistently accept it in C++14 mode.
> 
> > I noticed an interesting thing however. Consider this program:
> > 
> > auto i = 0, f();
> > auto f() { return false; }
> > int main() {}
> > 
> > Clang accepts it, but GCC rejects it (I didn't try EDG).
> 
> EDG accepts that too.

Yes, it is interesting that three different compilers seems to disagree with my
interpretation of the c++ standard. I still think this is a bug.

I'm trying to get a second option about this interpretation of the c++ standard
here:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/_xOC2ou49ZQ

[Bug c++/66888] Compiler accepting ill-formed program trying to define a struct via using-declaration

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
I'm moving this into 66879 since it is very similar.

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

[Bug c++/66879] Error message when defining a member function inside a class definition

[anders.granlund.0 at gmail dot com]

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

--- Comment #5 from Anders Granlund  ---
*** Bug 66888 has been marked as a duplicate of this bug. ***

[Bug c++/66889] Accepting ill-formed program trying to define a struct via using-directive

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #2 from Anders Granlund  ---
I'm moving this into 66879 since it is very similar.

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

[Bug c++/66879] Error message when defining a member function inside a class definition

[anders.granlund.0 at gmail dot com]

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

--- Comment #6 from Anders Granlund  ---
*** Bug 66889 has been marked as a duplicate of this bug. ***

[Bug c++/66879] Error message when defining a member function inside a class definition

[anders.granlund.0 at gmail dot com]

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

--- Comment #7 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #4)
> So confirming as accepts-invalid with this testcase:
> 
> class A;
> 
> namespace Y {
> using ::A;
> class A { };
> }

Here are two similar test cases pulled in from my related bug reports (i have
marked them as resolved duplicates).

The following ill-formed programs are also accepted by gcc:

  namespace R { struct f; }
  namespace S { using R::f; }
  struct S::f {};
  int main() {} 

  The above is ill-formed by [dcl.meaning]p1 (
http://eel.is/c++draft/dcl.meaning#1 )

  namespace P { struct S; }
  namespace R { using namespace P; }
  struct R::S {};
  int main() {}

  The above is also ill-formed by [dcl.meaning]p1

In general redeclarations must be done directly and not indirectly.