public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Casey at Carter dot net" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/67217] New: [concepts] Constraints are ignored when specializing union templates Date: Fri, 14 Aug 2015 13:44:00 -0000 [thread overview] Message-ID: <bug-67217-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67217 Bug ID: 67217 Summary: [concepts] Constraints are ignored when specializing union templates Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Casey at Carter dot net Target Milestone: --- r226833 incorrectly compiles this program without diagnostics: template <class T> requires __is_same_as(T, double) union A {}; int main() { A<int>{}; } despite that int does not satisfy the constraints of A. Changing the expression __is_same_as(T, double) to true, false, 42, or (new T) has no effect - the program compiles without diagnostics. Compiling *this* program, however: template <class> union B {}; template <class T> requires false union B<T> {}; int main() { B<int>{}; } incorrectly produces diagnostics: ~/gcc6-r226833/bin/g++ -std=gnu++1z foo.cpp -c foo.cpp: In function ‘int main()’: foo.cpp:9:10: error: ambiguous template instantiation for ‘union B<int>’ B<int>{}; ^ foo.cpp:6:7: note: candidates are: template<class T> union B<T> [with T = int] union B<T> {}; ^ foo.cpp:6:12: note: template<class T> union B<T> [with T = int] union B<T> {}; ^ foo.cpp:6:13: note: template<class T> union B<T> [with T = int] union B<T> {}; ^ foo.cpp:9:10: error: invalid use of incomplete type ‘union B<int>’ B<int>{}; ^ foo.cpp:2:7: note: declaration of ‘union B<int>’ union B {}; ^ It would appear that constraints are not being checked on union templates. >From gcc-bugs-return-494835-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 14:23:49 2015 Return-Path: <gcc-bugs-return-494835-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 126152 invoked by alias); 14 Aug 2015 14:23:49 -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 126079 invoked by uid 48); 14 Aug 2015 14:23:47 -0000 From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274 Date: Fri, 14 Aug 2015 14:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-67133-4-Qjf8JwzhHp@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-67133-4@http.gcc.gnu.org/bugzilla/> References: <bug-67133-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg00977.txt.bz2 Content-length: 877 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #23 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Richard Biener from comment #21) > OTOH users like infer_nonnull_range_by_attribute cannot rely on > gimple_call_fntype being "compatible" with the actual call (like in > terms of number of arguments). So > > lacks a check that idx < gimple_call_num_args. And what would happen if the nonnull attribute refers to a different argument that still satisfies the check? For example, fntype may have more arguments than the call and the one marked as nonnull may still satisfy the check, yet not be the actual argument that was marked as nonnull. There must be a way to "fix" the attributes or mark them as not "compatible". Asking "users" of the attributes to "guess" if the attributes are compatible seems fragile. >From gcc-bugs-return-494836-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 14:29:28 2015 Return-Path: <gcc-bugs-return-494836-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 92529 invoked by alias); 14 Aug 2015 14:29:27 -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 92482 invoked by uid 48); 14 Aug 2015 14:29:26 -0000 From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274 Date: Fri, 14 Aug 2015 14:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: mpolacek at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-67133-4-QcIHcPHhaB@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-67133-4@http.gcc.gnu.org/bugzilla/> References: <bug-67133-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg00978.txt.bz2 Content-length: 528 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #24 from Marek Polacek <mpolacek at gcc dot gnu.org> --- (In reply to Manuel López-Ibáñez from comment #23) > And what would happen if the nonnull attribute refers to a different > argument that still satisfies the check? For example, fntype may have more > arguments than the call and the one marked as nonnull may still satisfy the > check, yet not be the actual argument that was marked as nonnull. Then operand_equal_p would return false. >From gcc-bugs-return-494838-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 15:06:55 2015 Return-Path: <gcc-bugs-return-494838-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 95750 invoked by alias); 14 Aug 2015 15:06:54 -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 92212 invoked by uid 48); 14 Aug 2015 15:06:52 -0000 From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/48664] Use autoconf test instead of target blacklist to determine weak undefined reference support Date: Fri, 14 Aug 2015 15:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: fxcoudert at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: fxcoudert at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc assigned_to everconfirmed Message-ID: <bug-48664-4-7iNPGXWmlQ@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-48664-4@http.gcc.gnu.org/bugzilla/> References: <bug-48664-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-08/txt/msg00980.txt.bz2 Content-length: 736 https://gcc.gnu.org/bugzilla/show_bug.cgi?idH664 Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2015-08-14 CC| |fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- Patch available: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00796.html
next reply other threads:[~2015-08-14 13:44 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-08-14 13:44 Casey at Carter dot net [this message] 2021-12-08 19:17 ` [Bug c++/67217] " redi at gcc dot gnu.org
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-67217-4@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).