public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr
Date: Wed, 24 Jun 2015 13:29:00 -0000	[thread overview]
Message-ID: <bug-66639-4-cQNnp7SWck@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-66639-4@http.gcc.gnu.org/bugzilla/>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 7108 bytes --]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|5.1.1                       |6.0
            Summary|Feature request C++: mark   |declare __func__ ,
                   |__func__ , __FUNCTION__ &   |__FUNCTION__ &
                   |__PRETTY_FUNCTION__ as      |__PRETTY_FUNCTION__ as
                   |constexpr                   |constexpr

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Simon Gleissner from comment #3)
> > If at all, this could only be provided as compiler extension.
> 
> Good point. Yes, i think this would be a adequate solution.
> 
> > (assuming making it constexpr doesn't break anything)
> 
> ... which IMHO could only be tested safely with an optional compiler switch.

Due to past negative experiences, compiler extensions are only accepted under
very careful consideration and if they do not conflict with an existing (or
future) standard. Extensions accepted under an optional compiler switch are
even more rare: They add another very rarely tested point of failure and
increment the complexity of the compiler for very little benefit. The best
option is: create a tentative implementation, test it (by compiling and testing
GCC, libstdc++, boost, QT, Clang and other large C++ code bases) and propose
its standardization.
>From gcc-bugs-return-490068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 24 13:34:46 2015
Return-Path: <gcc-bugs-return-490068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15159 invoked by alias); 24 Jun 2015 13:34:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15133 invoked by uid 48); 24 Jun 2015 13:34:41 -0000
From: "public at alisdairm dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66649] New: variable template specializations not being found
Date: Wed, 24 Jun 2015 13:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: public at alisdairm dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created
Message-ID: <bug-66649-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg02400.txt.bz2
Content-length: 3672

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf649

            Bug ID: 66649
           Summary: variable template specializations not being found
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: public at alisdairm dot net
  Target Milestone: ---

Created attachment 35841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5841&actioníit
C++ code that should compile in C++14 mode, but fails

The attached file shows a simple test case for variable templates that I
believe is correct, and passes with Clang:

template <typename T, typename U>
constexpr bool is_same_v = false;

template <typename T>
constexpr bool is_same_v<T, T> = true;

template <typename T>
auto make() -> T;

template <typename T>
void AssertMakeSame() {
   static_assert( is_same_v<T, T>, "Type should be the same as itself");
   static_assert( is_same_v<decltype(make<T>()), T>, "make should produce the
same type");
};

int main() {
   AssertMakeSame<int>();
// AssertMakeSame<int const>();  // Should be an error
   AssertMakeSame<int *>();
}


In gcc 5, I get an error that the partial specialization must be at namespace
scope, but this appears to be fixed in trunk.  However, all 4 static asserts
fire in both trunk and 5.

Tested with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20150614/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20150614_0'
Thread model: posix
gcc version 6.0.0 20150614 (experimental) (MacPorts gcc6 6-20150614_0)


and with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc5/gcc5/work/gcc-5.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc5 --includedir=/opt/local/include/gcc5
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-5 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-5
--with-gxx-include-dir=/opt/local/include/gcc5/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc5 5.1.0_1'
Thread model: posix
gcc version 5.1.0 (MacPorts gcc5 5.1.0_1)


      parent reply	other threads:[~2015-06-24 13:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 13:08 [Bug c++/66639] New: Feature request C++: mark " simon at gleissner dot de
2015-06-23 18:55 ` [Bug c++/66639] " msebor at gcc dot gnu.org
2015-06-24  9:26 ` simon at gleissner dot de
2015-06-24 13:29 ` manu at gcc dot gnu.org [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-66639-4-cQNnp7SWck@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).