[fortran, patch] Don't use huge_val builtins in the front-end

[FX]

Currently, the code generated for NEAREST is something like:

  NEAREST(i,j) = nextafter(i, copysign(HUGE_VAL, j)) 

where HUGE_VAL is a call to one of __builtin_huge_val{f,,l}. This call, which gives a constant result, is immediatly folded by the middle-end. Its value is +Inf if infinities are supported for this type, or the largest representable real otherwise.

Dominique discovered that this is not handled too well with quad-float, where a __builtin_huge_valq() is available, but not directly from our front-end. While I could fix this, it seems much simpler to emit directly the appropriate real constant from the front-end, in all cases, and get rid of __builtin_huge_val{f,,l}. In addition, there is existing code doing that for generating inline {MIN,MAX}LOC.

The attached patch creates a new function in trans-const.c (gfc_build_inf_or_huge), which is used in both places.
It also fixes the testcase gfortran.dg/promotion.f90 which has nothing to do with it, but it a trivial patch (see http://gcc.gnu.org/ml/fortran/2010-09/msg00266.html for details).

Bootstrapped and regtested on x86_64-linux, both with and without the quad-float patch. OK to commit?

FX




-------------- next part --------------
A non-text attachment was scrubbed...
Name: hugeval.ChangeLog
Type: application/octet-stream
Size: 690 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20100911/85e526e5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hugeval.diff
Type: application/octet-stream
Size: 6160 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20100911/85e526e5/attachment-0001.obj>