Bedankt

[donkergezien]

Hartelijk dank voor uw bericht.
Zodra wij in de gelegenheid zijn zullen wij uw bericht zonodig beantwoorden.

P.S.

Wij zijn voor publiek gesloten van 10-07-2005 t/m 20-08-2005!
  
Met vriendelijke groet,

Jan en Tinah Visser

"In het donker gezien"
T 0251-274788
E [EMAIL PROTECTED]
Website www.wakan.nl klik in het donker gezien

centrum WAKAN
Grote Hout- of Koningsweg 35-37
1951 GN  Velsen-Noord

Re: Hi I want to implement new target AVR MCU's for GCC

[Abhijit Gupta]

On 8/18/05, Rikard S <[EMAIL PROTECTED]> wrote:
> Where do I start?

Read the top of http://gcc.gnu.org/readings.html there's Hans-Peter
Nilsson's "Porting GCC for Dunces"
A good document to start with.

> I guess there is only some few files that I need to write or edit,
> using files for similar MCU's as "templates".
> 
> If I would like to implement new AVR targets, which files are involved?

You need to write the target.md , target.h and target.c files with
some makefile fragment in the gcc/config/ directory.

> 
> Who knows, maby I can contribute :-)
:-)
Regards,
Abhijit.
> 
> /Best Regards Rikard Strömmer
>

Re: ppc assembler problem

[Gunther Nikl]

On Wed, Aug 17, 2005 at 12:33:12PM -0700, James E Wilson wrote:
> F. Heitkamp wrote:
> > a particular cpu. Looking at the specs file for the host compiler the
> > default is -mppc.  When I gave the "--with-cpu=7400" shouldn't that have
> > made the default  -m7400?.   What about xgcc, how can I make that use
> > the 7400 cpu?
> 
> Perhaps this is a case that gcc doesn't handle right.  When you use the
> -m7400 option, gcc will pass -maltivec to the assembler.

  3.3.6 doesn't.

> When you use --with-cpu=7400 at configure time, gcc should pass -maltivec
> to the assembler by default.

  AFAICS, --with-cpu does only set the default CPU for the compiler.

> This is apparently not happening, and is probably a gcc bug.  ASM_SPEC
> would have to be modified to fix this.  You may be able to do this
> manually by creating a spec file and editing it to add the missing
> -maltivec option to the assembler specs.

  He should provide a suitable ASM_DEFAULT_SPEC for his port and modify
  the mcpu=7400 part of rs6000/rs6000.h/ASM_CPU_SPEC.

> You may want to report this problem into the gcc bugzilla database so it
> gets tracked and fixed.

  Well, 3.3.6 is a dead branch. 3.4.x and later have a proper ASM_CPU_SPEC.

  Gunther

Re: Hi I want to implement new target AVR MCU's for GCC

[E. Weddington]

Rikard S wrote:


Where do I start?
I guess there is only some few files that I need to write or edit,
using files for similar MCU's as "templates".

If I would like to implement new AVR targets, which files are involved?

Who knows, maby I can contribute :-)

/Best Regards Rikard Strömmer

 

Please note that the avr-libc project has all of the developers working 
on the AVR port of the GNU toolchain. avr-libc can be found at Savannah at:



If you would like to implement new devices in the AVR target then be 
aware that:

- you will have to modify GNU Binutils, GCC, and avr-libc.
- and that your device may already be implemented. The avr-libc Patch 
Manager has a number of patches already that implement a lot of new 
devices. We've been waiting for one of the AVR maintainers of GCC (in 
the CC list) to find the time to formally commit them to Binutils or GCC.


If you want more information about the AVR target, I would suggest 
getting on the avr-libc-dev mailing list (part of the avr-libc project 
at Savannah).


Eric Weddington

RE: [PATCH]: Proof-of-concept for dynamic format checking

[Dave Korn]

Original Message
>From: Ian Lance Taylor
>Sent: 18 August 2005 02:20

> "Giovanni Bajo" writes:
> 
>> Florian Weimer wrote:
>> 
>>> Can't we just use some inline function written in plain C to check the
>>> arguments and execute it at compile time using constant folding etc.?
>> 
>> 
>> Do we have a sane way to (partially) execute optimizers at -O0 without
>> screwing up with the pass manager too much? Probably they can be talked
>> into, but might require some work. The idea is neat though, and I prefer
>> it over introducing a specific pattern-matching language (which sounds
>> like over-engineering for such a side feature).
> 
> I suppose I have the reverse opinion about which one is over-
> engineering, but that's probably just me.  Remember that it's not
> enough simply to execute the optimizers.  You have to build a symbol
> table and an environment for the code to execute in.
> 
> Another approach would be to dlopen a shared library to do format
> checking.  There might be some security implications to that, though.


  PMFBI, but how is all this going to work on a cross compiler?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Florian Weimer]

* Giovanni Bajo:

> Do we have a sane way to (partially) execute optimizers at -O0
> without screwing up with the pass manager too much?

Do we have to provide user-defined format string warnings at -O0?

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Florian Weimer]

* Dave Korn:

>   PMFBI, but how is all this going to work on a cross compiler?

Constant folding works in a cross-compiler, too. 8-)

RE: [PATCH]: Proof-of-concept for dynamic format checking

[Dave Korn]

Original Message
>From: Florian Weimer
>Sent: 18 August 2005 13:00

> * Dave Korn:
> 
>>   PMFBI, but how is all this going to work on a cross compiler?
> 
> Constant folding works in a cross-compiler, too. 8-)

  I was referring to this bit:

>   Remember that it's not
> enough simply to execute the optimizers.  You have to build a symbol
> table and an environment for the code to execute in.

  IIUIC, that would be a requirement for the optimisers to be able to
perform the full constant-folding and get the same results as if the
function was executed at runtime instead, wouldn't it?  It seems to me like
it would be quite a difficult thing to get right in a cross environment.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Kaveh R. Ghazi]

 > > Yeah, BFD can only do that because it forces the %A %B specifiers be
 > > in the front.
 > 
 > No, it's worse than that.  %A and %B can appear anywhere in the format
 > string, but consume their args first.  eg.
 > 
 > _bfd_default_error_handler ("section %d is called %A", sec, 1);
 > 
 > Alan Modra

Oh... ick, I didn't realize that.  It means my numbers for format
errors in bfd were off because GCC counted positional mismatches as
bugs in note #1 here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00693.html

GCC's current infrastructure doesn't seem suited to handle this style.
The clostest I can shoehorn it is that it's really two separate
formats, one with %A and %B ignoring all other specifiers and checking
against the first N arguments.  Then check all other specifiers
ignoring %A and %B against arguments N+1 until the end.  (Where N
equals the number of %A and %B appearances.)  We can actually do that
in GCC by creating two separate formats.  The trick is to calculate N
on the fly and apply both formats against the "right" arguments.  I
haven't figured out how to solve that without major surgery on GCC.

I don't know how wedded to this style the bfd folks are, but perhaps
we can modify bfd sources into a more conforming format compatible
with GCC's format checking.  However it requires tweeking BFD sources.
I wouldn't consider doing that until format checking is in place so
that we'll know if we introduce bugs into bfd in this conversion.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Alan Modra]

On Thu, Aug 18, 2005 at 08:46:04AM -0400, Kaveh R. Ghazi wrote:
> I don't know how wedded to this style the bfd folks are

Not at all.  In fact I don't like it, even though I wrote the code.

It would be great if _bfd_default_error_handler used the natural arg
positions for %A and %B.  I couldn't think of a way to do that without
incorporating a whole lot of knowledge about printf into the bfd
function.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Kaveh R. Ghazi]

 > > I don't know how wedded to this style the bfd folks are
 > 
 > Not at all.  In fact I don't like it, even though I wrote the code.
 > It would be great if _bfd_default_error_handler used the natural arg
 > positions for %A and %B.  I couldn't think of a way to do that without
 > incorporating a whole lot of knowledge about printf into the bfd
 > function.

Right, in GCC we ended up doing that except we only implemented the
bits of printf commonly used.  So for example we don't implement all
of the specifiers (floating point) or modifers (%h) or flags.  In fact
the fortran front end has a format that only has %d %i %c and %s from
printf, (plus two custom specifiers.)  No flags or even length
modifiers!

It's likely that bfd doesn't use a big chunk of printf that you could
leave out as well.  (I haven't actually audited bfd though).


Another option is to require positional specifiers for out of order
arguments.  E.g.

_bfd_default_error_handler ("section %2$d is called %1$A", sec, 1);

You could keep "sec" at the front, consume it, replace %1$A with the
appropriate string, and then pass the modified format string and the
partially consumed argument list to vfprintf.

Two problems, one is you'd have to modify (or delete) all the
positional parameters to account for taking out "sec".  So 2$ above
becomes 1$ or is eliminated.

Also, there's nothing to prevent someone from violating the rules
keeping "sec" in the front.


So I favor rewriting _bfd_default_error_handler to do the safer thing
which is to use natural arg positions.  Then create a format check
with only the stuff you need, not the whole printf style.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Ian Lance Taylor]

Florian Weimer <[EMAIL PROTECTED]> writes:

> > Do we have a sane way to (partially) execute optimizers at -O0
> > without screwing up with the pass manager too much?
> 
> Do we have to provide user-defined format string warnings at -O0?

Yes, we do.

(But, although I don't like this approach, I think this particular
problem could be solved.)

Ian

Ian Lance Taylor appointed "middle-end" maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Ian Lance Taylor to the role of "middle-end" maintainer,
joining Roger Sayle.  The role covers all files that may get included
into libbackend.a.

Please join me in congratulating Ian on his new role.  Ian,
please update your entry in the MAINTAINERS file.

Happy Hacking!
David

Re: Ian Lance Taylor appointed "middle-end" maintainer

[Ian Lance Taylor]

David Edelsohn <[EMAIL PROTECTED]> writes:

>   I am pleased to announce that the GCC Steering Committee has
> appointed Ian Lance Taylor to the role of "middle-end" maintainer,
> joining Roger Sayle.  The role covers all files that may get included
> into libbackend.a.

My thanks to David and the steering committee for trusting me in this
role, which I will endeavor to execute to the best of my ability.

My first steps will be to restore the much-missed byte code generation
capability, and to begin the transition from the old tree data
structures to the new LISP based ones.

Ian

P.S. Just in case: yes, I'm kidding.

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Mike Stump]

On Aug 18, 2005, at 5:08 AM, Dave Korn wrote:

  I was referring to this bit:

Remember that it's not enough simply to execute the optimizers.   
You have to build a symbol table and an environment for the code  
to execute in.


IIUIC, that would be a requirement for the optimisers to be able to
perform the full constant-folding and get the same results as if the
function was executed at runtime instead, wouldn't it?  It seems to  
me like
it would be quite a difficult thing to get right in a cross  
environment.


Imagine the following program:

{
   int i = 234234;
   printf ("%d", i);
}

imagine the folder collapsing this to puts ("234234");

Or:

enum {
foo=42;

foo() {
printf("%d", (int)foo);
}

Hint, we already have a symbol table, it already works for cross  
compilation.

Ian Lance Taylor appointed "middle-end" maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Ian Lance Taylor to the role of "middle-end" maintainer,
joining Roger Sayle.  The role covers all files that may get included
into libbackend.a.

Please join me in congratulating Ian on his new role.  Ian,
please update your entry in the MAINTAINERS file.

Happy Hacking!
David

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Branko Čibej]

Mike Stump wrote:


Imagine the following program:

{
   int i = 234234;
   printf ("%d", i);
}

imagine the folder collapsing this to puts ("234234");


Now imagine that the output of the original program depends on the 
locale that's in force at execution time, which defines numberic output 
to be in arabic numerals (real ones, not the sort we see in ASCII).


-- Brane

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Vincent Lefevre]

On 2005-08-18 21:53:47 +0200, Branko Čibej wrote:
> Mike Stump wrote:
[...]
> >   printf ("%d", i);
[...]
> Now imagine that the output of the original program depends on the
> locale that's in force at execution time, which defines numberic
> output to be in arabic numerals (real ones, not the sort we see in
> ASCII).

Is it possible? I would have thought that only the decimal-point
character depends on the locale.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Mike Stump]

On Aug 18, 2005, at 12:53 PM, Branko Čibej wrote:
Now imagine that the output of the original program depends on the  
locale that's in force at execution time


Now imagine that you can't use locale specific functions for these  
things.

gcc-4.0-20050818 is now available

[gccadmin]

Snapshot gcc-4.0-20050818 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050818/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050818 

You'll find:

gcc-4.0-20050818.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20050818.tar.bz2 C front end and core compiler

gcc-ada-4.0-20050818.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20050818.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20050818.tar.bz2  C++ front end and runtime

gcc-java-4.0-20050818.tar.bz2 Java front end and runtime

gcc-objc-4.0-20050818.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20050818.tar.bz2The GCC testsuite

Diffs from 4.0-20050811 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Joe Buck]

On Thu, Aug 18, 2005 at 11:52:36PM +0200, Vincent Lefevre wrote:
> On 2005-08-18 21:53:47 +0200, Branko Čibej wrote:
> > Mike Stump wrote:
> [...]
> > >   printf ("%d", i);
> [...]
> > Now imagine that the output of the original program depends on the
> > locale that's in force at execution time, which defines numberic
> > output to be in arabic numerals (real ones, not the sort we see in
> > ASCII).
> 
> Is it possible? I would have thought that only the decimal-point
> character depends on the locale.

The digits we use come from the Arabs, and look much the same in Arabic.
Check an Arabic-language site, for example http://www.aljazeera.net/ .

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Alan Modra]

On Thu, Aug 18, 2005 at 10:35:22AM -0400, Kaveh R. Ghazi wrote:
>  > > I don't know how wedded to this style the bfd folks are
>  > 
>  > Not at all.  In fact I don't like it, even though I wrote the code.
>  > It would be great if _bfd_default_error_handler used the natural arg
>  > positions for %A and %B.  I couldn't think of a way to do that without
>  > incorporating a whole lot of knowledge about printf into the bfd
>  > function.
> 
> Right, in GCC we ended up doing that except we only implemented the
> bits of printf commonly used.  So for example we don't implement all
> of the specifiers (floating point) or modifers (%h) or flags.  In fact
> the fortran front end has a format that only has %d %i %c and %s from
> printf, (plus two custom specifiers.)  No flags or even length
> modifiers!
> 
> It's likely that bfd doesn't use a big chunk of printf that you could
> leave out as well.  (I haven't actually audited bfd though).

$ sed -n -e 's,[^%]*\(%[0-9\.# hlL+-]*.\)[^%]*,\1,gp' < bfd/po/bfd.pot | sed -e 
's,%,\
%,g' | sort | uniq

%
%"
%-7ld
%.2x
%.8lx
%02X
%02x
%04lx
%08lx
%08x
%4d
%4lx
%4x
%A
%B
%X
%d
%i
%ld
%lu
%lx
%p
%s
%u
%x

(The '%"' is line wrapping in bfd.pot.  I may have missed a few format
specifiers because of that.  And the '%' is really '%%'.)

> Another option is to require positional specifiers for out of order
> arguments.  E.g.

Ick.

> So I favor rewriting _bfd_default_error_handler to do the safer thing
> which is to use natural arg positions.  Then create a format check
> with only the stuff you need, not the whole printf style.

I'm not motivated to do that myself. :)  There aren't that many places
that don't have %A or %B first in the format string.

$ sed -n -e 's,[^%]*\(%[0-9\.# hlL+-]*.\)[^%]*,\1,gp' < bfd/po/bfd.pot | grep 
'[^%AB]%[AB]'
%B%lx%A
%B%d%B%d
%s%d%d%B
%B%d%B%"
%B%d%B%d
%B%x%A
%B%s%s%A
%s%B
%s%B
%s%B
%s%B
%%%d%s%B%s%B
%s%B%s%B
%s%s%B%B
%s%B%A%B
%s%B%B
%s%B%A%B
%s%B%B%A
%B%lx%lx%lx%A
%u%s%B%u%B
%s%lu%B%lu%B
%B%s%s%B
%B%s%A
%X%s%A%B%A
%B%lx%A
%B%s%s%lx%A%lx

It's a great pity that vfprintf doesn't return its va_list arg.  If it
did, you could chop the format string into pieces and have vprintf
process the normal parts, consuming args as it goes.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH]: Proof-of-concept for dynamic format checking

[James E Wilson]

Joe Buck wrote:
> The digits we use come from the Arabs, and look much the same in Arabic.
> Check an Arabic-language site, for example http://www.aljazeera.net/ .

In English, we call them "Arabic Numerals", but that is a bit of a
misnomer.  Once upon a time, a long time ago, some Arabs used digits
that looked something like the ones we use today, but not anymore.
Arabic actually has its own set of digits which are quite different from
the ones that we use.

For more info, see
http://en.wikipedia.org/wiki/Arabic_numerals
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Robert Dewar]

James E Wilson wrote:

Joe Buck wrote:


The digits we use come from the Arabs, and look much the same in Arabic.
Check an Arabic-language site, for example http://www.aljazeera.net/ .


In English, we call them "Arabic Numerals", but that is a bit of a
misnomer.  Once upon a time, a long time ago, some Arabs used digits
that looked something like the ones we use today, but not anymore.
Arabic actually has its own set of digits which are quite different from
the ones that we use.


as far as i know,
you are both right and wrong. the arabic numerals we know (and indeed acquired
from the arabs) are characteristic of the western arabic dialects.
For example today in Morocco, that is what you will see. The eastern
arabic dialects, e.g. in Egypt, use quite different numerals closer
to Indian roots.

i certainly find the Wikipedia article inconsistent with what I have
read elsewhere, e.g.
http://www-history.mcs.st-andrews.ac.uk/history/HistTopics/Arabic_numerals.html
which shows al-Banna al-Marrakushi's form of the numerals to be very similar
to our own, and with my personal observations in Morocco.

Re: [PATCH]: Proof-of-concept for dynamic format checking

[Ian Lance Taylor]

Alan Modra <[EMAIL PROTECTED]> writes:

> It's a great pity that vfprintf doesn't return its va_list arg.  If it
> did, you could chop the format string into pieces and have vprintf
> process the normal parts, consuming args as it goes.

You can do relatively limited parsing and still identify how printf is
going to use its arguments.  See libiberty/vasprintf.c.  (Although it
admittedly assumes that long == int, and it mishandles %lld.)

I suppose we could write the version of vfprintf you want, and put it
in libiberty.  Assuming it is always OK to pass the address of a
va_list to a function.

Ian

Keyword _Imaginary in C99 standard and in GCC

[Yao qi]

Hi, everyone,
I have looked through C99 standard, in 6.4.1 Keywords,  "_Imaginary" is 
mentioned as a keyword in this standard.  However, it seems that GCC can not 
recognize it,  report error: '_Imaginary' undeclared.  I also search it in 
GCC info, there is no spot mentioned that.  Maybe GCC does not include it as 
a keyword, I am not sure about that, am I missing something?  Maybe someone 
of you could clarify for me.  Thanks in advance.


Best Regards

Yao Qi
Bejing Institute of Technology

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Keyword _Imaginary in C99 standard and in GCC

[Andrew Pinski]

On Aug 18, 2005, at 11:04 PM, Yao qi wrote:


Hi, everyone,
I have looked through C99 standard, in 6.4.1 Keywords,  "_Imaginary" 
is mentioned as a keyword in this standard.  However, it seems that 
GCC can not recognize it,  report error: '_Imaginary' undeclared.  I 
also search it in GCC info, there is no spot mentioned that.  Maybe 
GCC does not include it as a keyword, I am not sure about that, am I 
missing something?  Maybe someone of you could clarify for me.  Thanks 
in advance.


_Imaginary types are not implemented yet in GCC.

-- Pinski

Re: Keyword _Imaginary in C99 standard and in GCC

[Yao qi]

From: Andrew Pinski <[EMAIL PROTECTED]>
To: "Yao qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: Keyword _Imaginary in C99 standard and in GCC
Date: Thu, 18 Aug 2005 23:07:49 -0400


On Aug 18, 2005, at 11:04 PM, Yao qi wrote:


Hi, everyone,
I have looked through C99 standard, in 6.4.1 Keywords,  "_Imaginary" is 
mentioned as a keyword in this standard.  However, it seems that GCC can 
not recognize it,  report error: '_Imaginary' undeclared.  I also search 
it in GCC info, there is no spot mentioned that.  Maybe GCC does not 
include it as a keyword, I am not sure about that, am I missing something? 
 Maybe someone of you could clarify for me.  Thanks in advance.


_Imaginary types are not implemented yet in GCC.

-- Pinski

Thanks.  That means GCC has not fully support C99, just partialy, am I 
right?  I want to continue a question further, could you tell me where can I 
find a document about GCC's coverage in C99, if any?  If there is no such 
document, I just have to collect these information by hand.


Best Regards

Yao Qi
Bejing Institute of Technology

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Keyword _Imaginary in C99 standard and in GCC

[Andrew Pinski]

On Aug 18, 2005, at 11:25 PM, Yao qi wrote:
Thanks.  That means GCC has not fully support C99, just partialy, am I 
right?  I want to continue a question further, could you tell me where 
can I find a document about GCC's coverage in C99, if any?


http://gcc.gnu.org/c99status.html

Note there is a DR report about _Imaginary types:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_207.htm

-- Pinski

Re: Keyword _Imaginary in C99 standard and in GCC

[Yao qi]

Hi,Pinski,

Got it!  Thanks.

Best Regards

Yao Qi
Bejing Institute of Technology






From: Andrew Pinski <[EMAIL PROTECTED]>
To: "Yao qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: Keyword _Imaginary in C99 standard and in GCC
Date: Thu, 18 Aug 2005 23:30:06 -0400


On Aug 18, 2005, at 11:25 PM, Yao qi wrote:
Thanks.  That means GCC has not fully support C99, just partialy, am I 
right?  I want to continue a question further, could you tell me where can 
I find a document about GCC's coverage in C99, if any?


http://gcc.gnu.org/c99status.html

Note there is a DR report about _Imaginary types:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_207.htm

-- Pinski



_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

ISO C++ forbids initialization in array new?

[WU Yongwei]

Well, I see this in the gcc error message.  Can someone here kindly
point to me which part of the Standard specified this behaviour?  I
thought it should be in 5.3.4, but was not able to find the words
there.

By the way, anyone knows the rationale of this behaviour?

Thanks in advance.

Best regards,

Yongwei