public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "brooks at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61382] parameter pack expansion unexpected order Date: Tue, 08 Jul 2014 02:57:00 -0000 [thread overview] Message-ID: <bug-61382-4-23p2fA2IPl@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-61382-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: 5006 bytes --] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382 --- Comment #15 from Brooks Moses <brooks at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #14) [...] > * g++.dg/cpp0x/initlist86.C (main): Initialize i. [...] Aha ... yes, that would do it. And, indeed, I can confirm that this fixes the failures I was seeing. Thanks! Jason, should this be marked as "resolved"? >From gcc-bugs-return-455834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 08 03:28:28 2014 Return-Path: <gcc-bugs-return-455834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 18081 invoked by alias); 8 Jul 2014 03:28: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 17774 invoked by uid 48); 8 Jul 2014 03:28:15 -0000 From: "gccbugzilla at limegreensocks dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug inline-asm/61740] New: Fixes for minor problems in asm_fprintf and output_asm_insn Date: Tue, 08 Jul 2014 03:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: inline-asm X-Bugzilla-Version: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gccbugzilla at limegreensocks dot com X-Bugzilla-Status: UNCONFIRMED 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 attachments.created Message-ID: <bug-61740-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: 2014-07/txt/msg00425.txt.bz2 Content-length: 2732 https://gcc.gnu.org/bugzilla/show_bug.cgi?ida740 Bug ID: 61740 Summary: Fixes for minor problems in asm_fprintf and output_asm_insn Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: gccbugzilla at limegreensocks dot com Created attachment 33087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3087&actioníit Proposed patch The attached patch fixes 4 inline asm issues in asm_fprintf and output_asm_insn. They vary in importance from minor to trivial. 1) Compiling this inline asm statement (correctly) reports "unterminated assembly dialect alternative": asm("{" :); But this one does not: asm("{stuff" :); This patch reports all unterminated dialects (for both att & intel) in both output_asm_insn & asm_fprintf: asm("{" :); asm("{nop" :); asm("{|" :); asm("{nop|" :); asm("{nop|nop" :); asm("{||" :); asm("{nop||" :); asm("{nop|nop|" :); asm("{nop||nop" :); asm("{nop|nop|nop" :); 2) In r198641, output_asm_insn was modified to add support for escaping the dialect characters: {|}. This feature was not added to asm_fprintf (which also supports dialects). This patch updates asm_fprintf to support escaping dialect characters, so that it truly will "handle alternate assembler dialects here, just like output_asm_insn." 3) There are two format strings (%@ %r) defined for asm_fprintf in c-format.c that are only available for arm. Any attempt to use them from other platforms results in an ICE. Since the entire purpose of these tables is to validate format strings, these entries should only be defined when building arm. While I could have simply wrapped the offending table entries in an #ifdef __arm__, that does not appear to be consistent with the standard used by the rest of gcc. Following the example of the related macro (ASM_FPRINTF_EXTENSIONS), I created a macro named ASM_FPRINTF_TABLE that can be created on a per-platform basis to define platform-specific formats. Like ASM_FPRINTF_EXTENSIONS, this is (currently) only implemented on arm. 4) asm_fprintf uses a fixed size buffer (buf[10]) that it copies data into, but it never checks to see if it is overrunning the buffer. While 10 bytes is almost certainly sufficient for most valid uses, not checking at all seems bad. There are legal (if unlikely) printf modifiers that require more than 10 bytes. Rather than depend upon people to not violate this restriction, this patch performs a simple check for overruns. An 11 byte example: asm_fprintf(asm_out_file, "%-160.140x", 12);
next prev parent reply other threads:[~2014-07-08 2:57 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-01 21:17 [Bug c++/61382] New: " pengujohn at xvlc dot de 2014-06-01 22:27 ` [Bug c++/61382] " redi at gcc dot gnu.org 2014-06-03 23:03 ` thibaut.lutz at googlemail dot com 2014-06-04 8:50 ` thibaut.lutz at googlemail dot com 2014-06-04 15:51 ` jason at gcc dot gnu.org 2014-06-04 15:52 ` jason at gcc dot gnu.org 2014-06-11 21:35 ` pengujohn at xvlc dot de 2014-06-30 14:26 ` jason at gcc dot gnu.org 2014-07-03 2:02 ` brooks at gcc dot gnu.org 2014-07-03 3:37 ` brooks at gcc dot gnu.org 2014-07-03 8:29 ` jakub at gcc dot gnu.org 2014-07-04 7:24 ` jason at gcc dot gnu.org 2014-07-04 8:24 ` jakub at gcc dot gnu.org 2014-07-08 2:57 ` brooks at gcc dot gnu.org [this message] 2014-07-08 22:34 ` jason 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-61382-4-23p2fA2IPl@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).