This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __LDBL_MAX__ exceeds range of 'long double'


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 ();


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]