Re: A prototype patch for tree.h/tree.def/calls.c

Re: A prototype patch for tree.h/tree.def/calls.c

[Ian Haggard]

Jeffrey A Law wrote:
> 
>   In message <m0x0tpx-0004ecC@ocean.lucon.org>you write:
>   > > But regardless of what other parts of gcc are doing, using "unsigned"
>   > > in the prototype for xmalloc is wrong and such a change will not be
>   > > installed.
>   >
>   > It makes nosenses when the definion of xmalloc uses unsigned
>   > and its prototype uses size_t. It is much worse.
> Providing a prototype that is blatently wrong will not be accepted.
> There's no use argueing about this, an incorrect patch will not
> be accepted.

Actually, you are both sort-of right on this.  In some programs, the
definition of xmalloc takes a signed or unsigned int, and in some it
takes a size_t.  The mips-tfile.c is the worst offender:

Its definition of xmalloc starts like:

> 
> PTR_T
> xmalloc (size)
>      Size_t size;
> {

Earlier in mips-tfile.c, "Size_t" is defined as:

> #if defined(__OSF1__) || defined(__OSF__) || defined(__osf__)
> #define Size_t          long unsigned int
> #else
> #define Size_t          unsigned int
> #endif

Both cccp.c and protoize.c contain definitions of xmalloc with a size_t
argument.  And just for completeness, bi-arity.c, bi-lexer.c,
bi-opcode.c, and bi-opname.c also have the trivial inconsistency that
they contain definitions of xmalloc that expect an int, not an unsigned
int.  All other definitions of xmalloc do, however, take unsigned int.
-- 
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion

PA port & haifa

[Jeffrey A Law]

In the next snapshot, the PA port will default to using the
haifa scheduler.

After some tuning of the PA backend, haifa is showing a noticable
improvement in FP intensive code.  While there are still some
cases where the generated code is slower, the majority of the
time the code is significantly faster.  For specfp92 I'm seeing
an overall improvement of about 6.5%.

I encourage others to test with haifa and tune the scheduling
parameters to get good performance from haifa.

As haifa improves in both code reliability and speed, we can
make it the default for additional cpus -- with the goal of
having the haifa scheduler replace the old scheduler.


Jeff