From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Zick" Subject: Re: [parisc-linux] Re: Looking at vfprintf.c and alloca. Date: Wed, 19 Jul 2006 10:22:44 -0500 Message-ID: <200607191022.45082.mszick@morethan.org> References: <200607190248.k6J2mlLd015855@hiauly1.hia.nrc.ca> <44BDA13F.6040706@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: parisc-linux@lists.parisc-linux.org Return-Path: In-Reply-To: <44BDA13F.6040706@tausq.org> List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: parisc-linux-bounces@lists.parisc-linux.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. 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