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)
prev 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: linkBe 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).