#84 #include <float.h> does NOT really include it

[Alexey Pushkin]

#include <float.h> does NOT really include x86_64-pc-mingw32/include/float.h.
Only GCC's float.h gets included.

For example:

#include <float.h>

int main(){

_status87();

return 0;

}

In function ‘int main()’:

:5: error: ‘_status87’ was not declared in this scope

[Kai Tietz]

I can confirm this. The gcc variant of float.h should have an #include_next <float.h> (and ours shouldn't try to do this). I think this an issue to be solved in 4.5. Btw I assume that mingw32 has the same problem, or am I wrong by this assumption?

Cheers,
Kai

[Alexey Pushkin]

> Btw I assume that mingw32 has the same problem, or am I wrong by this assumption?
The "unofficial" combination of gcc-4.3 with mingw.org's runtime does have this problem.
The "official" mingw.org's distribution with gcc-3.x does not (assuming that my recollections are correct)

> The gcc variant of float.h should have an #include_next <float.h> (and ours shouldn't try to do this)
What about patching GCC's float.h ?

[Kai Tietz]

Yes, patching gcc is ok, but first at Stage 1 again. In gcc 4.5 I will do that

[Kai Tietz]

[Kai Tietz]

So I prepared an update for our float.h file. As I found is float.h in gcc not able to handle conditional #include_next. So I put the ISO/gcc extension defines into our float.h.
Could you verify, if this adjusted header files works?
I'll commit it to our repository, if we verified that it solves this issue.

Thanks in advance,
Kai

[Kai Tietz]

Too be more clear here what happens in gcc. fixinclude verifies target float.h file for existing of some macro definitions. If they aren't present it uses the version of float.h from gcc/ginclude.
If those defines are present, it doesn't put it under lib/gcc/4.4.0/include.
So when testing, please make sure that this directory doesn't contains float.h!

Cheers,
Kai

[Nobody/Anonymous]

The new float.h works fine for me.

One thing: shouldn't the declaration of fpreset() be guarded with old-names ?

P.S. is #ifndef __STRICT_ANSI__ appropriate
around the declarations of MS FP functions ?
(Not really arguing, just asking.
Frankly I never understood how __STRICT_ANSI__ is used in MinGW)

[Kai Tietz]

Ok, do you want to appy it?

the fpreset is declared in crt_FP8.c (IIRC) as weak, so it is present in any case here. From fundamental point of view, you're right. Possibly something we should cleanup in future.

Cheers,
Kai

[Kai Tietz]

Ok, I applied it already. See revision 706.

Thanks,
Kai