From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: gdb-patches@sources.redhat.com
Subject: [patch/testsuite] compiler.cc, compiler.c: work with old hp acc
Date: Wed, 30 Jun 2004 07:59:00 -0000 [thread overview]
Message-ID: <20040630075939.64DDD4B104@berman.michael-chastain.com> (raw)
This is a one-line patch to make the test suite run with old hp aC++
compilers. I recently switched to an older hpux and I got hurt by this.
This happens with hp aC++ A.03.13 but is fixed in hp aCC A.03.45.
lib/compiler.cc says:
set compiler_info "unknown"
#if foo
...
#endif
#if defined (_HP_aCC)
blah blah blah
#endif
The hp aC++ preprocessor emits:
set compiler_info "unknown"blah blah blah
That's right, it eats the newline! This gives lib/gdb.exp indigestion
because it's eval'ing this output as tcl commands.
After some experimentation and cursing, it looks like their compiler
does aggressive string concatenation. If the last token in the line is
a string, then the preprocessor eats the newline in order to merge with
the first token on the next line, in case that token is a string.
The patch is simple: add another token at the end of the line, like a
semicolon. That makes the preprocessor respect the newlines.
Tested on:
native i686-pc-linux-gnu, gcc 2.95.3 3.3.3 3.4.0, dwarf-2 stabs+
native hppa2.0w-hp-hpux11.00, hp ansi c A.11.01.25171.GP,
hp aC++ A.03.13
I don't have access to the newer hp aC++ (A.03.45) but since this
works with A.03.13 it should work with A.03.45.
I am committing this now,
Michael C
2004-06-30 Michael Chastain <mec.gnu@mindspring.com>
* lib/compiler.cc: Work around string preprocessing problem
with old hp c++ compiler.
* lib/compiler.c: Likewise.
Index: lib/compiler.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/compiler.cc,v
retrieving revision 1.7
diff -c -3 -p -r1.7 compiler.cc
*** lib/compiler.cc 14 Jun 2004 15:29:30 -0000 1.7
--- lib/compiler.cc 30 Jun 2004 06:10:01 -0000
***************
*** 22,28 ****
/* This file is exactly like compiler.c. I could just use compiler.c if
I could be sure that every C++ compiler accepted extensions of ".c". */
! set compiler_info "unknown"
#if defined (__GNUC__)
#if defined (__GNUC_PATCHLEVEL__)
--- 22,35 ----
/* This file is exactly like compiler.c. I could just use compiler.c if
I could be sure that every C++ compiler accepted extensions of ".c". */
! /* Note the semicolon at the end of this line. Older versions of
! hp c++ have a bug in string preprocessing: if the last token on a
! line is a string, then the preprocessor concatenates the next line
! onto the current line and eats the newline! That messes up TCL of
! course. That happens with HP aC++ A.03.13, but it no longer happens
! with HP aC++ A.03.45. */
!
! set compiler_info "unknown" ;
#if defined (__GNUC__)
#if defined (__GNUC_PATCHLEVEL__)
Index: lib/compiler.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/compiler.c,v
retrieving revision 1.5
diff -c -3 -p -r1.5 compiler.c
*** lib/compiler.c 14 Jun 2004 15:29:30 -0000 1.5
--- lib/compiler.c 30 Jun 2004 06:10:01 -0000
***************
*** 34,40 ****
TODO: purge signed_keyword_not_used. */
! set compiler_info "unknown"
#if defined (__GNUC__)
#if defined (__GNUC_PATCHLEVEL__)
--- 34,47 ----
TODO: purge signed_keyword_not_used. */
! /* Note the semicolon at the end of this line. Older versions of
! hp c++ have a bug in string preprocessing: if the last token on a
! line is a string, then the preprocessor concatenates the next line
! onto the current line and eats the newline! That messes up TCL of
! course. That happens with HP aC++ A.03.13, but it no longer happens
! with HP aC++ A.03.45. */
!
! set compiler_info "unknown" ;
#if defined (__GNUC__)
#if defined (__GNUC_PATCHLEVEL__)
next reply other threads:[~2004-06-30 7:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-30 7:59 Michael Elizabeth Chastain [this message]
2004-06-30 13:11 ` Daniel Jacobowitz
2004-06-30 16:52 Michael Elizabeth Chastain
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=20040630075939.64DDD4B104@berman.michael-chastain.com \
--to=mec.gnu@mindspring.com \
--cc=gdb-patches@sources.redhat.com \
/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