This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.3.0 Status Report (2007-09-04)


Jakub Jelinek wrote:

> I have a bunch of tiny patches, nevertheless all Stage 2 material, as
> they add new features:

I'd like a middle-end maintainer to review this one:

> redundant zero store elimination optimization (simplistic version,
> but nevertheless is able to trigger many times during gcc bootstrap):
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html

That seems like a nice optimization.  It was interesting to see how many
places this hit in GCC.  I didn't see any data about performance
improvements on benchmarks (e.g., SPEC), or code-size improvements
(e.g., CSiBE), but it sure can't hurt.

Unfortunately, I think there are enough issues around most of the rest
of these patches that we should wait for 4.4.  In particular, all of these:

> __artificial__ attribute (except the builtins.c hunk which is addressed
> differently):
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html
> 
> __builtin_va_arg_pack_len () addition:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html
> 
> __error_decl__ and __warning_decl__ attributes:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html

add extensions of one kind or another to GCC, and there has been some
discussion about each of them.  I think we have to be very careful with
these things; once they go out in a release, we live with them forever.

However, I do hereby acknowledge that these were submitted before Stage
2 ended, and, as per our guidelines, if these patches are approved, they
can still go in.

This one:

> diagnostic changes to print virtual call stack:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html

looks like it would have a major effect on consumers of GCC output.  As
you say:

> The tools that parse this will need changing anyway to do something
> reasonable with it

I think we should consider GCC diagnostic a defined, machine-readable
format and that we should modify it only in backwards-compatible ways.
Or, make incompatible changes only under control of an option or
environment variable.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]