[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization

["tobi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #7 from tobi at gcc dot gnu dot org  2007-02-16 13:31 -------
The backtrace ends in mpfr_erf, I couldn't go further up.  To overcome this
difficulty, I set a breakpoint on the caller, see below.

For the record as there seems to have been some confusion: this bug doesn't
appear during gfortran's constant folding, but during later compilation stages
(as evidenced by its dependence on -O, also I don't think we fold erf at all in
the Fortran FE).

If I find out how I can have my own mpfr and gmp coexist with the fink
libraries, I'll try setting up my own.  In the past, attempts I made at doing
this (on Linux) have failed.  Looking through the fink scripts, it seems that
its mpfr is a build with no unusual configure arguments, gmp is patched to
disable the assembly fragments but nothing unusual except for that.

----

Here's what it looks like on entry to do_mpfr_arg1 with Steve's testcase:
(gdb) run -O erf.f
Starting program: /Users/tobi/src/pristine/build/gcc/f951 -O erf.f
 MAIN__
Breakpoint 1, do_mpfr_arg1 (arg=0x42692b60, type=0x426f4a80, func=0x3179ab
<finalize_type_size+11>, min=0x1adcee, max=0x42692000, inclusive=66 'B') at
../../gcc/builtins.c:11923
11923   {
(gdb) p debug_tree (arg)
 <real_type 0x42692b60 real4 SF
    size <integer_cst 0x42685720 type <integer_type 0x42692070 bit_size_type>
constant invariant 32>
    unit size <integer_cst 0x426854c0 type <integer_type 0x42692000> constant
invariant 4>
    align 32 symtab 0 alias set -1 canonical type 0x42692b60 precision 32
    pointer_to_this <pointer_type 0x42692cb0>>
$9 = void
(gdb) bt
#0  do_mpfr_arg1 (arg=0x42692b60, type=0x426f4a80, func=0x3179ab
<finalize_type_size+11>, min=0x1adcee, max=0x42692000, inclusive=66 'B') at
../../gcc/builtins.c:11923
#1  0x000e3e8d in fold_builtin_1 (fndecl=0x426df300, arg0=0x20, ignore=0 '\0')
at ../../gcc/builtins.c:9301
Previous frame inner to this frame (corrupt stack?)
(gdb)

(understanding the stack seems to be a hard problem on Darwin, gdb fails quite
often making it fairly annoying to step through the code)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816