Thankfully, the complex type modifier was introduced into C99 standard. What I don't understand is why it was decided to omit support for fixed point arithmetic (specifically, support fractional types like 1.15 {signed} or 0.32 {unsigned}) where these types are so fundamental to DSP programming?
Does GCC support these through an extension?
It's been discussed/proposed (e.g., in N938, N953) but those papers have only proposed it as extensions, not additions to the main standard. Those seem to have led to its inclusion in N1169, which is a draft of TR 18037 ("Extensions to support embedded processors"), but that isn't considered complete (and the draft doesn't seem to have been updated in quite a while).
My guess (though it's only a guess) is that work on it probably got dropped (at least temporarily) to concentrate on finishing C11. Whether work on it will resume now will probably depend on whether there are still people around who still care. Writing and submitting a paper based on those earlier ones that covers more detail, provides more supporting evidence, etc., might help to get it back in motion again (though I obviously can't guarantee anything).
To address the question 'Does GCC support these through an extension', we can quote from 'Using the GNU Compiler Collection' (for GCC version 4.4.0 — bullet points added to clarify). (The GCC 4.9.0 URL equivalent is Fixed Point — Using the GNU Compiler Collection (GCC), but the section is 6.15 instead of 5.13.)
§5.13 Fixed-Point Types
As an extension, the GNU C compiler supports fixed-point types as defined in the N1169 draft of ISO/IEC DTR 18037. Support for fixed-point types in GCC will evolve as the draft technical report changes. Calling conventions for any target might also change. Not all targets support fixed-point types.
The fixed-point types are:
short _Fract,_Fract,long _Fract,long long _Fract,unsigned short _Fract,unsigned _Fract,unsigned long _Fract,unsigned long long _Fract,_Sat short _Fract,_Sat _Fract,_Sat long _Fract,_Sat long long _Fract,_Sat unsigned short _Fract,_Sat unsigned _Fract,_Sat unsigned long _Fract,_Sat unsigned long long _Fract,short _Accum,_Accum,long _Accum,long long _Accum,unsigned short _Accum,unsigned _Accum,unsigned long _Accum,unsigned long long _Accum,_Sat short _Accum,_Sat _Accum,_Sat long _Accum,_Sat long long _Accum,_Sat unsigned short _Accum,_Sat unsigned _Accum,_Sat unsigned long _Accum,_Sat unsigned long long _Accum.Fixed-point data values contain fractional and optional integral parts. The format of fixed-point data varies and depends on the target machine.
You can find the text of the draft proposal here.
Like Carl said in the comment, fixed-point is really exactly the same thing as integer. I suppose the language could have added a feature to do the scaling for you after mult/div (this would be on about the same level as pointer-to-VLA types: cleaning up the syntax by hiding scaling arithmetic for you) but considering the diverse range of scales and mix of types (e.g. fixed 8.24 times fixed 24.8, or fixed times integer) people want to use with fixed-point, it would be really hard to cover it all well.
Another major issue is the distinction of purpose. Fixed point is almost always a hack for speed at the expense of correctness (and as such it's much easier to roll your own). Floating point arithmetic, including the new complex support in C99, is for when you want rigorous results with known error bounds, safety from false overflows, etc. C99 complex support does a lot more for you than just FOIL'ing your complex binomials for you. It hides all the heavy work involved in making sure your results don't get trashed by corner cases.
来源：https://stackoverflow.com/questions/9883532/why-arent-fixed-point-types-included-in-c99