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);


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