Re: Stack direction check fails with optimizations

Any reason why the following should not work ? - int growsdown (void *x) { int y; return x > (void *)&y; } int main() { int x; exit (growsdown(&x)); } Roger While ___ Autoconf mailing list Autoconf@gnu.org http://li

Re: Stack direction check fails with optimizations

Roger While <[EMAIL PROTECTED]> writes: > Any reason why the following should not work ? - > > int > growsdown (void *x) > { > int y; > return x > (void *)&y; > } > > int > main() > { > int x; > exit (growsdown(&x)); > } That could fail exactly the same way if grow

Re: Stack direction check fails with optimizations

Hi Peter, I'm far from an expert in this area, so take this with a grain of salt. * Peter O'Gorman wrote on Tue, Dec 12, 2006 at 01:26:42PM CET: > > There is a test to check the stack direction when building the > replacement alloca. This test returns bad results with optimizations: [...] > ex

Re: Stack direction check fails with optimizations

On Dec 13, 2006, at 9:48 PM, Ralf Wildenhues wrote: Hi Peter, Hi Ralf, * Peter O'Gorman wrote on Tue, Dec 12, 2006 at 01:26:42PM CET: There is a test to check the stack direction when building the replacement alloca. This test returns bad results with optimizations: [...] exit (find_s

Re: Stack direction check fails with optimizations

Ralf Wildenhues wrote: * Peter O'Gorman wrote on Tue, Dec 12, 2006 at 01:26:42PM CET: There is a test to check the stack direction when building the replacement alloca. This test returns bad results with optimizations: [...] exit (find_stack_direction () < 0); It also fails with -xO2 on HPU

Re: Stack direction check fails with optimizations

I have two questions about this thread. First, is there an easy way to disable optimization for certain test cases? Second, what about the cross-compile case (where the code cannot be run)? H ___ Autoconf mailing list Autoconf@gnu.org http://lists.gn

Re: Stack direction check fails with optimizations

I disagree. gcc (versions 3 and 4) will indeed inline with various -On options but gets it right. AFAIK the return test in growsdown MUST be evaluated regardless of optimization out of the variables themselves and therefore the compiler in this case must do it right. Actually, as a side note to t

Re: Stack direction check fails with optimizations

> What about invoking the function indirectly, i.e. declare a pointer to > the function, set it to the function, and call Sorry, none of that stuff is guaranteed to work with ISO C. The implementation is allowed to dump core if you compare A < B where A and B point to distinct objects. alloc

Re: Stack direction check fails with optimizations

Paul Eggert wrote: What about invoking the function indirectly, i.e. declare a pointer to the function, set it to the function, and call Sorry, none of that stuff is guaranteed to work with ISO C. The implementation is allowed to dump core if you compare A < B where A and B point to distin

proposal - command-line option checking

Something that has been bothering me for a long time has been Autoconf's lack of checking for command-line options. That is, it doesn't give any error, or even a warning, if the user accidentally types --with-foo or --enable-ffoo instead of --enable-foo. In my experience, this has caused nume

Re: proposal - command-line option checking

"Steven G. Johnson" <[EMAIL PROTECTED]> writes: >* Autoconf configure scripts should check their --with and --enable > arguments, and exit with an error if the option was not specified in > an AC_ARG_ENABLE or AC_ARG_WITH statement That would run afoul of the GNU coding standards, no? See

Re: proposal - command-line option checking

I understand and agree with the coding standards, and it would be nice if, for example, each invoked "configure" noted which options it did anything with, and if the parent "configure" process noted usage it should not be all that hard to have the top-level "configure" process write a note saying t

Re: proposal - command-line option checking

Quoting Paul Eggert <[EMAIL PROTECTED]>: "Steven G. Johnson" <[EMAIL PROTECTED]> writes: * Autoconf configure scripts should check their --with and --enable arguments, and exit with an error if the option was not specified in an AC_ARG_ENABLE or AC_ARG_WITH statement That would run afoul