This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: Ian Lance Taylor <iant at google dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: eggert at cs dot ucla dot edu, autoconf-patches at gnu dot org, bug-gnulib at gnu dot org, gcc at gcc dot gnu dot org
- Date: 31 Dec 2006 21:37:00 -0800
- Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- References: <200612300047.kBU0lFwk014817@localhost.localdomain> <45963E6D.5070203@t-online.de> <10612301301.AA14129@vlsi1.ultra.nyu.edu> <871wmht4ab.fsf@penguin.cs.ucla.edu> <10612302258.AA24598@vlsi1.ultra.nyu.edu> <87lkkosz1n.fsf@penguin.cs.ucla.edu> <45970416.80407@adacore.com> <8764bssikm.fsf@penguin.cs.ucla.edu> <571f6b510612310047r3b7ef9acl4a0ab082e88e17a3@mail.gmail.com> <87bqlkmm3r.fsf@penguin.cs.ucla.edu> <4aca3dc20612310641n78e8898euf1c003444e2303eb@mail.gmail.com> <45980964.7000406@gnu.org> <45980C39.7030404@adacore.com> <87mz53lefb.fsf@penguin.cs.ucla.edu> <10701010259.AA10299@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> > But didn't this thread get started by a real program that was broken
> > by an optimization of loop invariants? Certainly I got a real bug
> > report of a real problem, which you can see here:
> >
> > http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html
>
> I just thought of something interesting about this case. We have a loop
> looking like:
>
> for (j = 1; 0 < j; j *= 2)
>
> in this case, the compiler is quite capable of arguing "this end condition
> won't terminate the loop except in the case of overflow, so obviously the
> programmer must be relying on wrapping semantics. So let's use those here"
Sure, but it's not the loop optimizer which is causing this code to
fail.
> > Here is a bit more discussion:
> >
> > http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html
>
> Indeed that message hinted at exactly that point. Note that if you do
> argue along those lines, you can convert this to a loop with a new IV
> that increments up to 31 (or is it 32?).
That is in fact precisely what happens if you compile with
-fno-tree-vrp.
Ian