[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2017-02-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #13 from Jonathan Wakely  ---
Patch committed to trunk, thanks.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2017-02-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Sun Feb 19 14:13:53 2017
New Revision: 245574

URL: https://gcc.gnu.org/viewcvs?rev=245574=gcc=rev
Log:
PR c++/69523 make -Wliteral-suffix control warning

gcc:

PR c++/69523
* doc/invoke.texi (C++ Dialect Options) [-Wliteral-suffix]: Update
description.

gcc/cp:

2017-02-19  Eric Fiselier  
Jonathan Wakely  

PR c++/69523
* parser.c (cp_parser_unqualified_id): Use OPT_Wliteral_suffix to
control warning about literal suffix identifiers without a leading
underscore.

gcc/testsuite:

2017-02-19  Eric Fiselier  
Jonathan Wakely  

PR c++/69523
* g++.dg/cpp0x/Wliteral-suffix2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2017-02-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #11 from Jonathan Wakely  ---
Patch submitted to gcc-patches with docs:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01109.html

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2017-02-17 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Fiselier  ---
It appears as though this patch was never applied, or it was applied and then
reverted.

Re-opening for a new, permanent, solution.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-10-12 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Fiselier  ---
This bug has been fixed by adding -Wno-literal-suffix. Thanks.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-08-07 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #8 from Eric Fiselier  ---
Created attachment 39069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39069=edit
fix.patch

Add a suggested fix with make -Wno-literal-suffix suppress the reserved
identifier warnings.

@Jonathan Could you help me land this?

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-06-14 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #7 from Eric Fiselier  ---
> The warning should be controlled by *some* flag, but I'm not sure whether or 
> not linking it with -Wliteral-suffix makes sense. I'll prepare a patch and 
> see what people think.

Any update? I would be happy with anything so long as I can enable warnings
again.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-05-09 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #6 from Jonathan Wakely  ---
We already support that flag, but the warning that you get on the declaration
of operator""s is not controlled by that flag.

The warning should be controlled by *some* flag, but I'm not sure whether or
not linking it with -Wliteral-suffix makes sense. I'll prepare a patch and see
what people think.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-05-08 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #5 from Eric Fiselier  ---
Would it be possible to add a -Wno-literal-suffix flag? I really want to use
warning with GCC, but I need to disable this one.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-01-28 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Not sure how namespace std should be special then though.  It seems the
specific warning isn't guarded by any warning flag though and thus you can't
selectively disable it.

Confirmed thus for this issue.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-01-28 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #4 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #3)
> Not sure how namespace std should be special then though.

Suffixes that don't start without underscore are reserved, but so are all names
in namespace std. It's reasonable to assume that std::operator""s is part of
the implementation and so is allowed to use a reserved name.

So I can see an argument for not treating this like other warnings that would
typically need to be disabled in system headers.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-01-27 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #1 from Andrew Pinski  ---
How about declaring those headers as system headers by using -isystem instead
of using -I :)?

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

2016-01-27 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523

--- Comment #2 from Eric Fiselier  ---
@Andrew I'm a libc++ developer and I really like using compiler warnings when
developing and testing libc++. Using -isystem prevents this entirely. Normally
they are system headers but this is explicitly turned off during development.