[Mingw-users] MinGW missing _controlfp and related defines? Looks like not...

[Luis Lavena]

Hello,

I'm compiling a C program that sets floating point control word:

<test.c>
#include <float.h>

int main(void)
{
/* set FPU precision to 64-bit and round to nearest */
_controlfp( _PC_64|_RC_NEAR, _MCW_PC|_MCW_RC );

return 0;
}
</test.c>

Which results in the following:
V:\>gcc test.c -o test.exe
test.c: In function 'main':
test.c:6:14: error: '_PC_64' undeclared (first use in this function)
test.c:6:14: note: each undeclared identifier is reported only once
for each function it appears in
test.c:6:21: error: '_RC_NEAR' undeclared (first use in this function)
test.c:6:31: error: '_MCW_PC' undeclared (first use in this function)
test.c:6:39: error: '_MCW_RC' undeclared (first use in this function)

Here is defined in MSDN:
http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.71).aspx

But peeking into float.h seems that those elements are only defined if
__STRICT_ANSI__ is not defined...

Why is __STRICT_ANSI__ defined even if I haven't requested it?

Looking at GCC documentation.

http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

Says that __STRICT_ANSI__ is defined when -ansi is used. Also mentions
that non-ISO compliant are not rejected gratuitously unless -pedantic
option is provided (which wasn't on this case).

GCC version in use is 4.6.2, mingwrt is 3.20 and w32api is 3.17-2.

Thanks in advance and pardon my ignorance.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-use...@lists.sourceforge.net?subject=unsubscribe

[Earnie Boyd]

On Sun, Feb 12, 2012 at 3:38 PM, Luis Lavena <luisl...@gmail.com> wrote:
> Hello,
>
> I'm compiling a C program that sets floating point control word:
>
> <test.c>
> #include <float.h>
>

This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which
isn't kind enough to ``#include_next <float.h>''

> int main(void)
> {
>        /* set FPU precision to 64-bit and round to nearest */
>        _controlfp( _PC_64|_RC_NEAR, _MCW_PC|_MCW_RC );

So these do not get defined regardless of __STRICT_ANSI__

The only work around I found was to "c:/mingw/include/float.h" instead
of <float.h>.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[Luis Lavena]

On Mon, Feb 13, 2012 at 9:46 AM, Earnie Boyd
<ear...@users.sourceforge.net> wrote:
>
> This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which
> isn't kind enough to ``#include_next <float.h>''
>
>> int main(void)
>> {
>>        /* set FPU precision to 64-bit and round to nearest */
>>        _controlfp( _PC_64|_RC_NEAR, _MCW_PC|_MCW_RC );
>
> So these do not get defined regardless of __STRICT_ANSI__
>
> The only work around I found was to "c:/mingw/include/float.h" instead
> of <float.h>.
>

Thank you Earnie for your answer.

Having a hardcoded path could be a inconvenient in portability.

Perhaps something else could be done?

Should I report this to SF bug tracker?

Thank you for your time.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

------------------------------------------------------------------------------

[Sergio NNX]

I've just compiled your code using GCC 4.5.2 without any changes and it worked ok.

[Earnie Boyd]

On Mon, Feb 13, 2012 at 8:01 AM, Luis Lavena <luisl...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 9:46 AM, Earnie Boyd
> <ear...@users.sourceforge.net> wrote:
>>
>> This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which
>> isn't kind enough to ``#include_next <float.h>''
>>
>>> int main(void)
>>> {
>>>        /* set FPU precision to 64-bit and round to nearest */
>>>        _controlfp( _PC_64|_RC_NEAR, _MCW_PC|_MCW_RC );
>>
>> So these do not get defined regardless of __STRICT_ANSI__
>>
>> The only work around I found was to "c:/mingw/include/float.h" instead
>> of <float.h>.
>>
>
> Thank you Earnie for your answer.
>
> Having a hardcoded path could be a inconvenient in portability.
>
> Perhaps something else could be done?
>

Modify the /mingw/lib/gcc/GCC-VERSION/mingw32/include/float.h file and add

#ifndef _MINGW_FLOAT_H_
#include_next <float.h>
#endif

> Should I report this to SF bug tracker?
>

No, it is a GCC issue and I think there is a SF bug already entered.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------

[Earnie Boyd]

DO NOT TOP POST
Is this loud enough?

On Mon, Feb 13, 2012 at 8:09 AM, Sergio NNX wrote:
> I've just compiled your code using GCC 4.5.2 without any changes and it
> worked ok.
>

So, it is a regression of 4.6.x series.

--8<--
TRIM THE FAT

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------

[Eli Zaretskii]

> Date: Mon, 13 Feb 2012 07:46:24 -0500
> From: Earnie Boyd <ear...@users.sourceforge.net>

>
> > I'm compiling a C program that sets floating point control word:
> >
> > <test.c>
> > #include <float.h>
> >
>
> This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which
> isn't kind enough to ``#include_next <float.h>''

Shouldn't it be the other way around? That is, shouldn't MinGW header
#include_next the one from GCC?

At least on my machine (which uses such an ancient version of GCC that
I'm embarrassed to say which one) this is so.

[Earnie Boyd]

On Mon, Feb 13, 2012 at 12:28 PM, Eli Zaretskii <el...@gnu.org> wrote:
>> Date: Mon, 13 Feb 2012 07:46:24 -0500
>> From: Earnie Boyd <ear...@users.sourceforge.net>
>>
>> > I'm compiling a C program that sets floating point control word:
>> >
>> > <test.c>
>> > #include <float.h>
>> >
>>
>> This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which
>> isn't kind enough to ``#include_next <float.h>''
>
> Shouldn't it be the other way around?  That is, shouldn't MinGW header
> #include_next the one from GCC?
>

It does already. The issue is that GCC has a regression that chooses
its library header first.

> At least on my machine (which uses such an ancient version of GCC that
> I'm embarrassed to say which one) this is so.

Yes, it used to work just fine. IIRC, Keith told me that GCC used to
do what I suggested above. I can't find the reference to what I'm
think of though.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------

[Keith Marshall]

On 13/02/12 19:45, Earnie Boyd wrote:

> On Mon, Feb 13, 2012 at 12:28 PM, Eli Zaretskii <eliz@...> wrote:
>>> Date: Mon, 13 Feb 2012 07:46:24 -0500

>>> From: Earnie Boyd <earnie@...>

>>>
>>>> I'm compiling a C program that sets floating point control word:
>>>>
>>>> <test.c>
>>>> #include <float.h>
>>>>
>>>
>>> This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which
>>> isn't kind enough to ``#include_next <float.h>''
>>
>> Shouldn't it be the other way around? That is, shouldn't MinGW header
>> #include_next the one from GCC?
>
> It does already. The issue is that GCC has a regression that chooses
> its library header first.

And, at least up to (and including) GCC-3.4.5, the MinGW header did
appear first in the #include search path, so all was hunky-dory.

>> At least on my machine (which uses such an ancient version of GCC that
>> I'm embarrassed to say which one) this is so.
>
> Yes, it used to work just fine. IIRC, Keith told me that GCC used to
> do what I suggested above. I can't find the reference to what I'm
> think of though.

http://bit.ly/xK7fyY perhaps?

Reviewing that today, I can no longer reproduce the fault with my self
built GCC-3.4.5 cross-compiler, (on LinuxMint-10):

$ mingw32-gcc -v -c -o /dev/null -xc /dev/null
Reading specs from /home/keith/mingw32/lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-2/configure
--prefix=/home/keith/mingw32 --target=mingw32
--with-gcc --with-gnu-as --with-gnu-ld --disable-nls
--disable-shared --disable-debug --enable-threads=win32
--disable-win32-registry --enable-sjlj-exceptions
--with-sysroot=/home/keith/mingw32
--enable-languages=c,c++,f77
Thread model: win32
gcc version 3.4.5 (mingw-vista special r2)
/home/keith/mingw32/libexec/gcc/mingw32/3.4.5/cc1 -quiet -v -isystem
/home/keith/mingw32-local/include /dev/null -quiet -dumpbase null
-auxbase-strip /dev/null -version -o /tmp/ccUDD3Ar.s
ignoring nonexistent directory "/home/keith/mingw32/lib/gcc/mingw32
/3.4.5/../../../../mingw32/include"
ignoring nonexistent directory "/home/keith/mingw32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
/home/keith/mingw32-local/include
/home/keith/mingw32/usr/local/include
/home/keith/mingw32/lib/gcc/mingw32/3.4.5/include
End of search list.
GNU C version 3.4.5 (mingw-vista special r2) (mingw32)
compiled by GNU C version 4.4.5.
GGC heuristics: --param ggc-min-expand=63
--param ggc-min-heapsize=62529
...

Note the order of the header searches:

1) /home/keith/mingw32-local/include

This is established by a local specs file customisation; it's where
I put the add-on headers I install, so they are kept separate from the
MinGW and GCC core header sets.

2) /home/keith/mingw32/usr/local/include

This is the sysroot path, (from --with-sysroot=/home/keith/mingw32);
it is where MinGW's headers (including float.h) are installed.

3) /home/keith/mingw32/lib/gcc/mingw32/3.4.5/include

This is where the GCC specific headers are installed; hence the GCC
float.h is correctly pulled in, by #include_next, from (2).

However, with GCC-4.6.2 on my MSYS box, I see:

$ gcc -v -c nul.c
Using built-in specs.
COLLECT_GCC=C:/mingw32/bin/gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/mingw32/4.6.2
/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++
--disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgomp --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runtime-libs
--build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'
c:/mingw32/bin/../libexec/gcc/mingw32/4.6.2/cc1.exe -quiet -v
-iprefix c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/ nul.c -quiet
-dumpbase nul.c -mtune=i386 -march=i386 -auxbase nul -version
-o C:/Users/.../AppData/Local/Temp/ccsEB0ea.s
GNU C (GCC) version 4.6.2 (mingw32)
compiled by GNU C version 4.6.2, GMP version 5.0.1,
MPFR version 2.4.1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100
--param ggc-min-heapsize=131072
ignoring nonexistent directory "c:/mingw32/bin/../lib/gcc/mingw32
/4.6.2/../../../../mingw32/include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32
/4.6.2/include"
ignoring nonexistent directory "/mingw/include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32
/4.6.2/include-fixed"
ignoring nonexistent directory "c:/mingw32/lib/gcc/../../lib/gcc
/mingw32/4.6.2/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include
c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/../../../../include
c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include-fixed
End of search list.
...

Note that, in this case, the search order is:

1) c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include

This is equivalent to c:/mingw32/lib/gcc/mingw32/4.6.2/include; it is
the GCC specific headers directory, in which GCC's float.h is found.

2) c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/../../../../include

This is equivalent to c:/mingw32/include, which is the MinGW headers
directory; note that it is now placed *after* the GCC directory, so its
float.h is occluded by the GCC version, (which does not #include_next
this, nor any other supplementary float.h); this is the GCC regression
to which Earnie refers.

3) c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include-fixed

This is a further GCC include directory, (for headers with applied
fix-ups); its presence here is not germane to the issue.

On the original patch ticket, I invited Aaron, Danny, or Cesar to pursue
this with the GCC folks. Has it been expedited? I don't know, and I
simply don't have the time to follow it up, but *somebody* needs to pick
up this ball, and run with it.

--
Regards,
Keith.

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

[Earnie Boyd]

On Tue, Feb 14, 2012 at 10:47 AM, Keith Marshall wrote:
>
> http://bit.ly/xK7fyY perhaps?
>

Probably.

Actually this is the first ignored include.

Using your example if I cd c:/mingw32/mingw32 and ``junction include
../include'' I can work around the issue.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------