__LDBL_MAX__ exceeds range of 'long double'
Jonathan Wakely
cow@compsoc.man.ac.uk
Wed Mar 2 18:07:00 GMT 2005
On Mon, Feb 21, 2005 at 09:14:22PM -0800, James E Wilson wrote:
> Jonathan Wakely wrote:
> >$ gcc4x -c bug.c -pedantic -save-temps
> >bug.c: In function 'main':
> >bug.c:1: error: floating constant exceeds range of 'long double'
>
> This is easy enough to explain. Grepping for the message shows that it
> is printed from c-lex.c, and is only printed when -pedantic.
> -save-temps means we run cc1 twice, once to produce the .i file, and
> once to read the .i file. So the problem is either writing the .i file
> or reading the .i file.
>
> Looking further, I noticed that FreeBSD sets the rounding mode to
> 53-bits. real.c knows this, and computes values appropriately, i.e.
> 96-bit values with 53-bits of fraction. Unfortunately, this value isn't
> getting propagated properly to the C preprocessor when using
> -save-temps/-E, and this problem exists because
> init_adjust_machine_modes is run in the wrong place. It is run from
> backend_init, but it needs to be run always, as we need it to compute
> the FP predefined macros correctly.
>
> The value really is wrong, even though it is the same as gcc-3.4. It
> has 11 too many bits of fraction.
>
> Targets using paired-double long double formats are probably also wrong.
> Anything that overrides the normal IEEE FP formats will be wrong.
>
> Attached is a mostly untested patch to fix this. It works for your
> testcase. And it now prints a different correct value of __LDBL_MAX__
> in the .i file.
Sorry for the late reply. It does indeed fix the problem I saw with 4.0
on FreeBSD, but I'm now seeing this with 3.4.4 20050228 too, so I think
it's a regression introduced in the last 6 weeks or so.
Is the same fix safe to apply to 3.4?
I got no regressions testing on x86/FreeBSD a few days ago. I'm in the
process of updating and re-testing current 3.4.
jon
> --
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
> 2005-02-21 James E Wilson <wilson@specifixinc.com>
>
> * toplev.c (backend_init): Don't call init_adjust_machine_modes here.
> (do_compile): Do call it here.
>
> Index: toplev.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/toplev.c,v
> retrieving revision 1.942
> diff -p -p -r1.942 toplev.c
> *** toplev.c 12 Feb 2005 00:26:52 -0000 1.942
> --- toplev.c 22 Feb 2005 04:58:04 -0000
> *************** process_options (void)
> *** 1954,1961 ****
> static void
> backend_init (void)
> {
> - init_adjust_machine_modes ();
> -
> init_emit_once (debug_info_level == DINFO_LEVEL_NORMAL
> || debug_info_level == DINFO_LEVEL_VERBOSE
> #ifdef VMS_DEBUGGING_INFO
> --- 1954,1959 ----
> *************** do_compile (void)
> *** 2092,2097 ****
> --- 2090,2100 ----
> /* Don't do any more if an error has already occurred. */
> if (!errorcount)
> {
> + /* This must be run always, because it is needed to compute the FP
> + predefined macros, such as __LDBL_MAX__, for targets using non
> + default FP formats. */
> + init_adjust_machine_modes ();
> +
> /* Set up the back-end if requested. */
> if (!no_backend)
> backend_init ();
More information about the Gcc-patches
mailing list