On Fri, 4 Mar 2005, Perrin Meyer wrote:
> As someone who writes a lot of computational acoustics code, I'd really like
> to start using these features, or at least have better explanation of what
> is broken and what isn't. I've been using _Complex variables in gcc for a
> while now, and as far as I can tell, that part is working fine.
Are the explanations on that page:
* Complex numbers support may be broken (some problems with
passing/returning complex values on 64-bit targets, and not
checked against the requirements of the C99 standard). However,
the _Complex keyword now works.
and
* The C99 semantics of variable length arrays (VLAs) are not fully
implemented by the existing GCC extension: the concept of variably
modified (VM) types, and the rules for what identifiers can be
declared with VLA or VM types, are not implemented (for example,
GCC allows elements of VM type in a structure with block scope);
while the syntax for arrays to be declared with [*] in parameter
declarations is present, the semantics are not; and in general the
implementation of VLAs has not been checked against C99
requirements.
inadequate?
My view would be that once logarithmic reduction for complex
multiplication and division is implemented, and once the 64-bit problems
are known to be resolved, it would make sense to do a detailed
line-by-line comparison of the requirements of the standard for complex
number support against the implementation, writing testcases in the
process, and mark complex number support done if the results of this
process indicate that it indeed is done.
As for VLAs, bugs 7948, 12913, 18740 and 19771 are a small sampling of
specific issues, beyond the general comments quoted above. VLAs are
complicated and there are several obscure or problematic parts of the
standard relating to them (I've just sent the UK C Panel convenor three
DRs on the subject to pass to the WG14 convenor); they also interact with
constant expressions. I do *not* recommend attempting isolated fixes for
random VLA issues (including that we no longer accept [*][*] as a
side-effect of rejecting [][]; since we don't meaningfully implement the
semantics of [*] I don't consider this significant or a regression)
without first properly understanding all the standard requirements and the
interaction with GNU extensions and auditing what is currently implemented
and preparing thorough testcases.
void f(int a, int (*b)[*], int c[static sizeof(*b)]);
is valid C99 code. What exactly it means is more obscure.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
