public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "fnf at specifixinc dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/30363]  New: Support for -traditional-cpp is incomplete in current gcc relative to gcc 2.95.3
Date: Thu, 04 Jan 2007 03:24:00 -0000	[thread overview]
Message-ID: <bug-30363-9863@http.gcc.gnu.org/bugzilla/> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]

Given the following test case:

  #define f(x, y) "x y"

  extern void abort (void);

  int main ()
  {
    const char *str1 = f("a", "\"a\"");
    const char *str2 = f( \t, " \t");

    if (strcmp (str1, "\"a\" \"\\\"a\\\"\""))
      abort ();
    if (strcmp (str2, "\t \" \\t\""))
      abort ();
    return 0;
  }

Gcc 2.95.3 will accept it and do the right thing:

  $ gcc -v
  Reading specs from /opt/local/fsf/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
  gcc version 2.95.3 20010315 (release)
  $ gcc -traditional-cpp -o macroargs macroargs.c
  $ ./macroargs
  $

Current gcc 4.X fails to accept this code.  For example, using the Fedora Core
6 compiler:

  $ /usr/bin/gcc -v
  Using built-in specs.
  Target: i386-redhat-linux
  Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
  Thread model: posix
  gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
  $ /usr/bin/gcc -traditional-cpp -o macroargs macroargs.c
  macroargs.c: In function ‘main’:
  macroargs.c:7: error: expected ‘,’ or ‘;’ before ‘a’
  macroargs.c:7: error: stray ‘\’ in program
  macroargs.c:7: error: missing terminating " character
  macroargs.c:8: error: stray ‘\’ in program
  macroargs.c:12: error: ‘str2’ undeclared (first use in this function)
  macroargs.c:12: error: (Each undeclared identifier is reported only once
  macroargs.c:12: error: for each function it appears in.)

The attached patch (also posted to gcc-patches) will fix it, although
it's handling of quoted arguments is not exactly identical to gcc
2.95.3.  Notice the difference between the test case above, and the
test case included with the patch.

Here is an example of a patched gcc's behavior:

  $ /opt/specifix/experimental/bin/gcc -v
  Using built-in specs.
  Target: i686-pc-linux-gnu
  Configured with: /src/specifix/experimental/src/gcc/configure
--enable-languages=c,c++,fortran --prefix=/opt/specifix/experimental
--disable-werror --disable-bootstrap --with-mpfr=/opt/specifix/experimental
--with-gmp=/opt/specifix/experimental --cache-file=/dev/null
--srcdir=/src/specifix/experimental/src/gcc
  Thread model: posix
  gcc version 4.3.0 20061231 (experimental)
  $ /opt/specifix/experimental/bin/gcc -traditional-cpp -o macroargs
macroargs.c
  $

Note however that the above test case WILL abort if run, while the
test case included with the patch will not, due to the handling of
leading and trailing whitespace in macro args.  See the code inside
"#if 0 ... #endif" in the patch and the associated comments.  Either the
current gcc testsuite is wrong in how it tests for this whitespace, or
gcc 2.95.3 is wrong.  It's not clear to me which behavior is more correct.


-- 
           Summary: Support for -traditional-cpp is incomplete in current
                    gcc relative to gcc 2.95.3
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fnf at specifixinc dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30363


             reply	other threads:[~2007-01-04  3:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-04  3:24 fnf at specifixinc dot com [this message]
2007-01-07  1:09 ` [Bug preprocessor/30363] [4.0/4.1/4.2/4.3 Regression] " pinskia at gcc dot gnu dot org
2007-01-07  1:21 ` fnf at specifixinc dot com
2007-02-03 21:23 ` gdr at gcc dot gnu dot org
2007-02-03 21:24 ` pinskia at gcc dot gnu dot org
2007-02-05  5:49 ` mmitchel at gcc dot gnu dot org
2007-02-14  9:20 ` mmitchel at gcc dot gnu dot org
2007-12-16 23:19 ` steven at gcc dot gnu dot org
2007-12-18  4:09 ` tromey at gcc dot gnu dot org
2008-01-07 17:30 ` tromey at gcc dot gnu dot org
2008-01-07 17:34 ` [Bug preprocessor/30363] [4.0/4.1/4.2 " tromey at gcc dot gnu dot org
2008-07-04 21:48 ` [Bug preprocessor/30363] [4.2 " jsm28 at gcc dot gnu dot org
2009-03-30 20:21 ` jsm28 at gcc dot gnu dot 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-30363-9863@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).