Re: [parisc-linux] Re: Looking at vfprintf.c and alloca.

["Michael S. Zick" <mszick@morethan.org>]

On Tue July 18 2006 22:04, Randolph Chung wrote:
> > What doesn't work?  ptr - old = 0x1c0 = 7 * 64.  The preferred
> > stack boundary is 64 bytes.  6 * 64 = 384 bytes.  That's too
> > small for the requested allocation.  &old[100] - old = 0x190 = 400.
> > So, the results printed appear correct.
> 
> gcc is completely correct, I meant to agree with your other email, that
> is glibc is totally bogus ;P
>

Since I have exchanged off-list bits and pieces that are related to the
series 4 compilers, let me try to explain the observations to date.
 
Joel has invested months of time, looking for the cause of 64-bit-smp
hangs under heavy load.

He will post when he is ready, I say nothing here other than he is
still working hard on the problem.

I have an interest in getting -finstrument-functions to work to my
own standard of satisfaction.  I will post to the appropriate lists
when I am certain I have all of the "cockpit error" out of my findings.

</end disclaimers>

I will be very careful to avoid the word: "mis-compiled" since it does
not apply to the following;

Given any series 3 compiler...
Given any C source code...
Define the assembler code generated as "expected output"...
Define the logical function(s) performed by that code 
as the "expected result".

The test standard of "expected output" is only an indicator;
not an error in itself.

We have found, Joel in the functions using spinlock macros;
Myself in the functions of the gcc provided crt* files;

That not only is the series 4 compiler not generating the
expected output (only an indicator) but it is not generating
the expected result (functionally equivalent code).

To date, neither of us have found a "wrong code" error in
the compilers.

What we have found are "source based" problems, in general,
the series 4 compilers require additional annotations in the
source to generate functionally equivalent code.

Without sufficient, proper, annotations; the series 4 compiler
will (correctly) throw away things the author of the source
expected to always be part of the "expected result".

The above is not our "single point of failure".  We have both
discovered good, old fashioned, programming errors in addition
to the above.

Which brings me to the subject of this thread, the vfprintf.c
is a "good, old fashioned, programming error" if the code expects
the stack space generated by alloca to be contiguous with any
other stack object.  That is true for either series compiler,
on any machine, regardless of stack direction growth.
(The man page for alloca could also use some help.  Its text
ignores the effect of compiler stack padding.)

> randolph
Mike
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux