[Bug c++/39159] unhelpful attribute warning on matching declaration after definition

[gw.fossdev at gmail dot com]

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

Gert  changed:

   What|Removed |Added

 CC||gw.fossdev at gmail dot com

--- Comment #5 from Gert  ---
Created attachment 38202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38202&action=edit
Proposed patch to silence the warning if the new attribute is same

Hello, 

I propose the attached patch for this. I'm flying blind here and the patch is
not yet tested. 

The idea is to search whether the attribute to be applied is already set and if
this is the case, to not emit a warning, and otherwise to rephrase the warning
pointing out that a different attribute was specified. 

The code was inspired by the lines starting from 589 in the same file
gcc/attribs.c. 

Now since I don't know whether simple_cst_equal really compares the value of
the attribute, or just some attribute type, it may be that the code does not do
what I hope to achieve. 

Any comments how to improve the patch are very welcome. 

Best, 
Gert

[Bug c++/39159] unhelpful attribute warning on matching declaration after definition

[gw.fossdev at gmail dot com]

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

--- Comment #6 from Gert  ---
I forgot to mention: the patch is against 5.3.0.

[Bug c++/71975] New: In c++11/14 mode whitespaces are ignored between enum or class type name and ::

[gw.fossdev at gmail dot com]

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

Bug ID: 71975
   Summary: In c++11/14 mode whitespaces are ignored between enum
or class type name and ::
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gw.fossdev at gmail dot com
  Target Milestone: ---

Created attachment 38951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38951&action=edit
Test case triggering the bug

Hello, 

I've got a wired behaviour with c++11 and enums or classes as return type of a
fully specified function residing in the global namespace. I.e.  with a line
like 

namespace bar {
  class foo {
friend some_enum_type ::global_function(); 
  }; 
}

an error  "enum some_enum_type is not a class or namespace" is reported.
Attached is an according test case. 

Observations: 
* With std=c++03 this compiles fine, probably because in this case enums can 
  not be strongly typed and make use of "::".  

* With c++11 this code compiles not.  

* If the return type is a class this construct also fails to compile.

* If the return  type is an "int" then it always compiles. 

I've first reported this bug in Debian [1] and also against LLVM [2]. 

Especially, since these two mostly independently developed compilers choke on
this same construct I'm not sure whether this is actually a bug in the
compilers, or whether this is an error or undefined behaviour resulting from
the formulation of the C++ standard. 

Many thanks, 
Gert 

[1] https://bugs.debian.org/829604
[2] https://llvm.org/bugs/show_bug.cgi?id=28422

[Bug c++/71975] In c++11/14 mode whitespaces are ignored between enum or class type name and ::

[gw.fossdev at gmail dot com]

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

Gert  changed:

   What|Removed |Added

  Attachment #38951|0   |1
is obsolete||

--- Comment #1 from Gert  ---
Created attachment 38952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38952&action=edit
Test case triggering the bug (corrected)

[Bug c++/71975] In c++11/14 mode enumname::name is assumed name to be part of the enumname

[gw.fossdev at gmail dot com]

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

--- Comment #3 from Gert  ---
Created attachment 38957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38957&action=edit
test case with "enu" being a struct

I would also assume that this is a parsing issue. 

With enu being a struct the compilation fails always (also with -std=c++98 and
c++03)

> g++ -std=c++98 whitespace_eating-class.cc

whitespace_eating-class.cc:11:24: error: ISO C++ forbids declaration of 'wow'
with no type [-fpermissive]
   friend enu ::wow();
^
whitespace_eating-class.cc:11:24: error: no 'int enu::wow()' member function
declared in class 'enu'

[Bug c++/71975] In c++11/14 mode enumname::name is assumed name to be part of the enumname

[gw.fossdev at gmail dot com]

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

--- Comment #4 from Gert  ---
Regarding the "whitespace" I didn't know that with something like 

namespace foo { class bar {}; }

one can actually write 

  foo  ::bar x; 

i.e. add whitespaces between a namespace or class name and "::" before the
nested name, and I'm quite positive that I have never seen code where this is
actually done. This led me to the conclusion that the parser might be skipping
over whitespaces where it is not supposed to do so.