| Title: | DEC C Problem Reporting Forum |
| Notice: | Report DEC C++ problems in TURRIS::C_PLUS_PLUS |
| Moderator: | CXXC::REPETE TCHEON |
| Created: | Fri Nov 13 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1299 |
| Total number of notes: | 6249 |
A user on the internet has claimed that our latest DEC C on Unix no longer compiles some sources he uses (unless he specifies -oldc). Here is his newsgroup posting: Article 20768 of comp.unix.osf.osf1: From: Michel van der List <[email protected]> Newsgroups: comp.unix.osf.osf1 Subject: cc problem on OSF 4.0B Date: 12 Mar 1997 14:14:59 GMT Organization: SmithKline Beecham Pharmaceuticals R & D, Bioinformatics Lines: 21 Message-ID: <[email protected]> NNTP-Posting-Host: phu967.um.us.sbphrd.com Originator: [email protected] Xref: nntpd.lkg.dec.com comp.unix.osf.osf1:20768 Hi there. I've used Landon Curt Noll's calc program for while now. I've never had any problems compiling it under OSF1, but as of version 4.0B, I can't compile it anymore, unless I use the -oldc flag. Also, gcc has no problems compiling this program. The current version can be found at: http://reality.sgi.com/chongo/calc/2.10.3t5.2.tgz Any comments? a d v Thanks a e c n Michel -- ------------------------------------------------------------------- Michel van der List SmithKline Beecham Pharmaceuticals R & D [email protected] UW2230, 709 Swedeland Road, P.O. Box 1539 (610) 270-4525 King of Prussia, PA 19406-0939
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1271.2 | Thanks, we'll take a look... | DECC::SULLIVAN | Jeff Sullivan | Thu Mar 13 1997 11:10 | 10 |
Joe Mario copied this off the 'net and sent me a pointer. I am able to reproduce the problem here on Platinum. We plan to investigate this and resolve it either as a bug in the compiler or possibly in the source code. We'll post a reply here when we have more info. Thanks for posting this. Resolving portability problems for Digital UNIX is a very high priority. -Jeff | |||||
| 1271.3 | Simplest reproducer | DECC::SULLIVAN | Jeff Sullivan | Thu Mar 13 1997 12:38 | 43 |
Here's the simplest reproducer for the zrand.c compilation failure. It appears
that there is a difference in the old-style token-pasting in compile vs.
preprocess-only modes. We get the same answer as ACC (cc -oldc) when
preprocessing only.
Ironically, DEC C does not get their expected result in -std1 (using the ANSI
token-pasting macro), since DEC C inserts the spaces in between the tokens.
% cat decc_bugs1271.c
#define U(x) ((unsigned long)x)
#define FULL int
# if defined(__STDC__) && __STDC__ != 0
# define SVAL(a,b) (FULL)U(0x ## a ## b)
# else
# define SVAL(a,b) (FULL)U(0x/**/a/**/b)
# endif
static int arr[] = {
SVAL(23a252f6,0bae4907)
};
% cc -oldc -c decc_bugs1271.c
% cc -c decc_bugs1271.c
cc: Warning: decc_bugs1271.c, line 12: Invalid token discarded.
SVAL(23a252f6,0bae4907)
--^
cc: Warning: decc_bugs1271.c, line 12: Invalid token discarded.
SVAL(23a252f6,0bae4907)
--^
cc: Warning: decc_bugs1271.c, line 12: Invalid token discarded.
SVAL(23a252f6,0bae4907)
--^
cc: Error: decc_bugs1271.c, line 12: Invalid expression.
SVAL(23a252f6,0bae4907)
--^
Still under investigation...
-Jeff
| |||||
| 1271.4 | fixed | DECC::PARKS | Thu Mar 13 1997 15:03 | 5 | |
Thanks for the report. I could go into details but I'll spare you. I've fixed the problem. When the tests finished running I'll check the new code in. \John | |||||
| 1271.5 | Fix expected in Platinum.minor and Steel | DECC::SULLIVAN | Jeff Sullivan | Thu Mar 13 1997 15:45 | 9 |
We'll expect to get this fix into the next minor and major release after V4.0. I have added a distilled test case as decc_bugs1271.c into our regression test system. Someone will need to reply to the news thread. Is there a procedure or protocol for doing that "officially". Thanks, -Jeff | |||||
| 1271.6 | here's my reply to comp.unix.osf.osf1 | DECC::PARKS | Thu Mar 13 1997 15:51 | 27 | |
Hi Michel,
It was indeed a compiler problem. The compiler refused to
token-paste 0x to 23a252f6 in the SVAL macro. Here's a distilled
testcase
#define SVAL(a,b) 0x ## a ## b
SVAL(23a252f6,0bae4907)
The compiler should expand the SVAL call to 0x23a252f60bae4907.
It didn't because it didn't like the leftmost operand (0x is not
a legitimate hex constant). It shouldn't have cared.
The compiler bug is now fixed.
A simple code workaround would be to rewrite 0x as 0x0. It
should not change the numeric value. Modifying the above
testcase would yield
#define SVAL(a,b) 0x0 ## a ## b
SVAL(23a252f6,0bae4907)
Thanks for letting us know about the problem. Hope the work-
around will help. We can also point you to a fixed compiler
if you'd like.
\John
| |||||