Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gabriel Dos Reis]

Andrew Pinski <address@hidden> writes:

| > 
| > Andrew Pinski <address@hidden> writes:
| > 
| > | > 
| > | > Paul Eggert <address@hidden> writes:
| > | > 
| > | > >       * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > | > >       optional second argument specifying the default optimization
| > | > >       options for GCC.  These optimizations now default to "-O2 
-fwrapv"
| > | > >       instead of to "-O2".  This partly attacks the problem reported 
by
| > | > >       Ralf Wildenhues in
| > | > >       
<http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html>
| > | > >       and in <http://gcc.gnu.org/ml/gcc/2006-12/msg00459.html>.
| > | > 
| > | > Does anybody think that Paul's proposed patch to autoconf would be
| > | > better than changing VRP?
| > | 
| > | I think both ways are incorrect way forward.
| > | What about coding the loops like:
| > | 
| > | if (sizeof(time_t) == sizeof(unsigned int))
| > | {
| > |   // do loop using unsigned int
| > |   // convert to time_t and then see if an overflow happened
| > | }
| > | //etc. for the other type
| > 
| > Yuck.
| 
| It might be Yuck but that is the only real portable way to do this loop.

You have not shown all the real codes that need to go in the blanks but
I have some doubt as to whether what would come out would be portable,
and even if it would be portable, whether it would be readable, and
even if it would readable, wheter it would be maintainable.

| Now if other compilers actually treat signed overflow as undefined, you
| will still run into this, even if GCC gets changed.

That indicates a fundamental problem with the stance GCC optimizers
have taken recently.

For this _specific_ instance of the general problem, C++ users could
use numeric_limits<time_t>::max() and get away with it, but I don't
believe such a solution (or the one you propose or similar I've seen)
to this specific instance generalizes to portable, readable and
maintainable solution to the general problem.   

| > If the above is the only without Autoconf change, I would highly
| > recommend Autoconf change if GCC optimizers highly value benchmarks
| > over running real world code.
| 
| Which one, mine or Paul's?

If what you propose is the only way out, and there is no way to make
GCC optimizers reasonable, then I believe Paul's proposal is the next
option. 

-- Gaby