From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17942 invoked by alias); 8 Jul 2014 02:57:53 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17859 invoked by uid 48); 8 Jul 2014 02:57:40 -0000 From: "brooks at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: brooks at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jason at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: 2014-07/txt/msg00424.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61382 --- Comment #15 from Brooks Moses --- (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: 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: List-Archive: List-Post: List-Help: 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" 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: 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?id=61740 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?id=33087&action=edit 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);