This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Compat testsuite improvement (part #1)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Janis Johnson <janis187 at us dot ibm dot com>
- Cc: Eric Botcazou <ebotcazou at libertysurf dot fr>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 15 Mar 2004 17:11:43 -0800
- Subject: Re: [PATCH] Compat testsuite improvement (part #1)
- References: <firstname.lastname@example.org><email@example.com><20040316005324.GA28574@us.ibm.com>
Janis Johnson <firstname.lastname@example.org> writes:
> On Mon, Jan 19, 2004 at 09:24:54AM -0800, Zack Weinberg wrote:
>> Another compatibility issue I have personally tripped over: HP's acc
>> accepts "float _Complex" but not "_Complex float" (same for double,
>> long double). I think this is a bug in acc, but it would be nice to
>> work around it.
> This is another issue I lost track of. Is "float _Complex" more commonly
> accepted than "_Complex float"? These tests are for functionality, not
> syntax, so they can use whatever is most common, or else use a macro that
> can be replaced for other compilers.
I don't know about more commonly accepted. C99 6.7.2p2 lists only the
"float _Complex" forms, but precedes them with (normative) text saying
"the type specifiers may occur in any order" which I think pretty
conclusively shows this to be a bug in acc.
> I'm also planning to fix the complex constant values used in these tests
> so they don't use the Fortran syntax which is a comma expression in C.
It would be more work, but would you consider changing all these tests
to get their numbers from statically initialized arrays, rather than
lists of globals with runtime-calculated values, and to check the
values by straight comparison with these arrays? Runtime computation
introduces another source of error - I've several times now had the
compat testsuite find bugs that had nothing to do with the ABI. Which
is all very well, but causes no end of headache to the poor schmuck
trying to figure out what's wrong with the argument passing (because
there isn't anything wrong with the argument passing).