Re: [Mingw-w64-public] Regarding strtold() bugs #711 and #725

[sisyphus1]

Hi Carl,

I'm already defining __USE_MINGW_ANSI_STDIO.

The messages you've quoted from the ChangeLog relate to strtod().
But strtod() works fine - the bug occurs only with strtold().

Is it just that strtold() needs to be aliased to __mingw_strtold() when 
__USE_MINGW_ANSI_STDIO is defned ?


Thanks for looking into it.

Cheers,
Rob

-Original Message- 
From: Carl Kleffner

Sent: Sunday, July 01, 2018 11:13 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Regarding strtold() bugs #711 and #725

I was too hasty, it's just the other way around.
Try to define __USE_MINGW_ANSI_STDIO to make automatically use of
__mingw_strtold instead of the strtold (msvcrt).



2018-07-01 15:03 GMT+02:00 Carl Kleffner :



mingw-w64/mingw-w64-headers/crt/ChangeLog:

2014-03-03  Ray Donnelly mingw.andr...@gmail.com
* stdlib.h (strtod): Don't define it to __strtod if
__USE_MINGW_STRTOX is defined.

mingw-w64-headers/crt/ChangeLog.2013:

2013-01-12  Jonathan Yong  

* stdlib.h: Define __USE_MINGW_STRTOX if __USE_MINGW_ANSI_STDIO in 
use.

(strtod): Alias to __mingw_strtod if __USE_MINGW_STRTOX.
(strtof): Likewise to __mingw_strtof.

This bug should only happen if either __USE_MINGW_ANSI_STDIO or
__USE_MINGW_STRTOX is defined. However, I am not sure if this should be 
the

desired behaviour.

2018-07-01 11:27 GMT+02:00 :


Hi,

In relation to

https://sourceforge.net/p/mingw-w64/bugs/711/
and
https://sourceforge.net/p/mingw-w64/bugs/725/

I've just discovered that replacing the strtold() calls with calls to
__mingw_strtold() avoids the buggy behaviour.

Why would that be so ?
Does this observation open the door to these bugs with strtold() soon
being fixed ?
Are there any downsides to my using __mingw_strtold() as a replacement
for strtold() ?

I should add that I've tested this only on gcc version 8.1.0
(i686-posix-dwarf-rev0, Built by MinGW-W64 project) and gcc version 8.1.0
(x86_64-posix-seh-rev0, Built by MinGW-W64 project).
I haven't actually tested it on mingw-w64 ports of earlier versions of
gcc.

Cheers,
Rob


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Regarding strtold() bugs #711 and #725

[sisyphus1]

Hi,

In relation to

https://sourceforge.net/p/mingw-w64/bugs/711/
and
https://sourceforge.net/p/mingw-w64/bugs/725/

I've just discovered that replacing the strtold() calls with calls to 
__mingw_strtold() avoids the buggy behaviour.


Why would that be so ?
Does this observation open the door to these bugs with strtold() soon being 
fixed ?
Are there any downsides to my using __mingw_strtold() as a replacement for 
strtold() ?


I should add that I've tested this only on gcc version 8.1.0 
(i686-posix-dwarf-rev0, Built by MinGW-W64 project) and gcc version 8.1.0 
(x86_64-posix-seh-rev0, Built by MinGW-W64 project).

I haven't actually tested it on mingw-w64 ports of earlier versions of gcc.

Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] alignment of _Decimal128 type with gcc-8.1.0

[sisyphus1]

-Original Message- 
From: sisyph...@optusnet.com.au

Sent: Friday, June 15, 2018 11:57 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] alignment of _Decimal128 type with gcc-8.1.0

[snip]

Has this change in requirements arisen because the version of gcc has 
reached 8.1.0 ?

Or has it arisen because the mingw runtime version has reached 6.0.0 ?


My mistake ... it has arisen because of a change in the perl source code.

Sorry for the noise.

Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] alignment of _Decimal128 type with gcc-8.1.0

[sisyphus1]

Hi,

With the latest x86_64 (official) builds of gcc-8.1.0, I'm finding it 
necessary to do something like:


typedef _Decimal128 D128 __attribute__ ((aligned(8)));

However, I didn't have to concern myself with such alignment issues with 
x86_64 mingw-w64 builds of earlier versions of gcc.


Has this change in requirements arisen because the version of gcc has 
reached 8.1.0 ?

Or has it arisen because the mingw runtime version has reached 6.0.0 ?

Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] The toolchain's future and my taking part in this project

[sisyphus1]

-Original Message- 
From: niXman

Sent: Friday, June 01, 2018 6:12 AM
To: mingw-w64-public
Subject: [Mingw-w64-public] The toolchain's future and my taking part in 
this project




Hi,

It's quite simple - I've lost my job and can no longer afford to work for 
free, although I want to...


Hmmm ... I'm thinking that not having a job would clear the way for you to 
spend even *more* time working for free !!!


Sorry - that was rather facetious.
In fact, I'm most appreciative of the work that you've done. And I hope that 
you soon find gainful employment.


Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News|New Builds]

[sisyphus1]

-Original Message- 
From: niXman Sent: Friday, May 25, 2018 2:26 AM To: mingw-w64-public 
Subject: [Mingw-w64-public] [Project News|New Builds]



Hi,


The new builds of MinGW-W64 based on 'GCC-8.1.0' and MinGW-w64 'master' 
branch was uploaded.


Thank you !!
I'll be trying them out soon.

A few days ago I grabbed and installed 
i686-7.3.0-release-posix-dwarf-rt_v5-rev0.7z and 
x86_64-7.3.0-release-posix-seh-rt_v5-rev0.7z.


I discovered that, despite being labelled as "rt_v5", 
__MINGW64_VERSION_MAJOR and __MINGW64_VERSION_MINOR actually report as being 
"6" and "0" respectively.


I mention this only in (the unlikely) case it hasn't already come to your 
attention.


Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [OT] warnings and errors messages overwrite my cmd.exe shell color selection.

[sisyphus1]

Hi,

Whenever a warning or error is emitted during compilation, the 
foreground/background colors of the cmd.exe console revert permanently from 
the colors I've selected, to the default.
This means that I continually have to re-enter the "color" selection at the 
command line.

What do I need to do in order to avoid this annoyance ?

NOTE: The behaviour occurs for me only with my mingw-w64 builds ("mingw 
builds") of gcc-7.2.0 and gcc-7.3.0.
There's no such problem with my mingw-w64 builds of gcc-7.1.0 and earlier 
(going back to 4.7.0).


Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sizeof long

[sisyphus1]

-Original Message- 
From: Vincent Torri

Sent: Wednesday, April 18, 2018 1:12 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] sizeof long


https://msdn.microsoft.com/ro-ro/library/s3f49ktz.aspx
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models


Thanks for those links, and the additional links/info provided by others.

Is it therefore the case that porting gcc's "-mlong64" switch (I think 
currently available for MIPS only) to Windows would, under *no* 
circumstances, provide anything useful ? In fact, would it inevitably be 
unusable because of the incompatibility with the Windows API ?


Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] sizeof long

[sisyphus1]

Hi,

Why is it that on our x86_64 compilers sizeof long is only 4 ?
Does it absolutely have to be that way ?  Would it be possible to design
a switch that would enable 8 byte longs ?

The mismatch between linux and windows in this regard is a real pita, and
I'm curious about the reason(s) that it exists.
(A link to relevant explanation would be fine.)

Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to backtrace a crash with gdb on Windows 7

[sisyphus1]

-Original Message- 
From: Hannes Domani via Mingw-w64-public

Sent: Thursday, January 18, 2018 10:11 PM
To: mingw-w64-public@lists.sourceforge.net
Cc: Hannes Domani
Subject: Re: [Mingw-w64-public] How to backtrace a crash with gdb on Windows 
7



(gdb) run
Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
[New Thread 4680.0x160c]

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
repl-vsnprintf.c:358: GNU MP assertion failed: 0
[Inferior 1 (process 4680) exited with code 03]
(gdb) bt
No stack.


That's because it didn't crash, but an assertion failed.
This calls abort(), which then normally exits with exit code 3.

A crash looks in gdb like this:
Thread 1 received signal SIGSEGV, Segmentation fault.

To get a proper stacktrace for an assertion failure, just use "break 
abort"

before "run".


Aaah ... yes, that makes all the difference.
Thank you, Hannes.

Cheers,
Rob



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] How to backtrace a crash with gdb on Windows 7

[sisyphus1]

Hi,

In the msys2 shell, I'm building gmp (with specific configure args) and then 
mpfr.
But there are 3 crashing tests in the mpfr test suite for which I would like 
to obtain a backtrace - but so far, all I'm getting is "No stack".


In the hope that someone might be able to see how I can improve on this 
(non) result, here's exactly what I'm doing.


gmp-6.1.2 source and mpfr-4.0.0 source are in /c/scratch.

In /c/scratch/gmp-6.1.2 I run:
./configure disable-shared --enable-static --enable-assert CC="gcc -ggdb" && 
make && make check.


That works fine, the -ggdb is propagated throughout the build, even to the 
compiling of the gmp test executables (all of which pass).


Then, in /c/scratch/mpfr-4.0.0 I run:
./configure 
disable-shared --enable-static --with-gmp-build=/c/scratch/gmp-6.1.2 && make 
&& make check


Again, the -ggdb flag (which mpfr inherits from gmp) is propagated 
throughout the build, including the compiling of the mpfr test executables 
(all of which pass except for the 3 crashing test programs).


The first crashing test is tests/tfprintf.exe, so I 'cd' to the tests 
directory and run:


###
$ gdb tfprintf.exe
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tfprintf.exe...done.
(gdb) run
Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
[New Thread 4680.0x160c]

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information.
repl-vsnprintf.c:358: GNU MP assertion failed: 0
[Inferior 1 (process 4680) exited with code 03]
(gdb) bt
No stack.
(gdb) q
###

And it's the same for the other 2 crashing test scripts (tprintf.exe and 
tsprint.exe).


Is there something I can do here to obtain a useful backtrace ?

Cheers,
Rob


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Finding runtime version

[sisyphus1]

-Original Message- 
From: sisyph...@optusnet.com.au

Sent: Friday, November 10, 2017 8:09 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Finding runtime version


Hi,

For mingw-w64 runtime version x.y.z, I know that __MINGW64_VERSION_MAJOR 
will give me the value of x, and __MINGW64_VERSION_MINOR will give me the 
value of y.

But what's the symbol that will give me the value of z ?

Is there a symbol that will give me all three values as a string "x.y.z" ?

https://sourceforge.net/p/predef/wiki/Compilers/ mentions only 
__MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR, __MINGW32_MAJOR_VERSION 
and __MINGW32_MINOR_VERSION.


Cheers,
Rob


Still hoping for some feedback on this.

To rephrase it:
Having determined that __MINGW64_VERSION_MAJOR is "5" and that 
__MINGW64_VERSION_MINOR is "0", is there some way that the C preprocessor 
can determine whether the runtime version is 5.0.3 (or not) ?


Cheers,
Rob


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Finding runtime version

[sisyphus1]

Hi,

For mingw-w64 runtime version x.y.z, I know that __MINGW64_VERSION_MAJOR 
will give me the value of x, and __MINGW64_VERSION_MINOR will give me the 
value of y.

But what's the symbol that will give me the value of z ?

Is there a symbol that will give me all three values as a string "x.y.z" ?

https://sourceforge.net/p/predef/wiki/Compilers/ mentions only 
__MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR, __MINGW32_MAJOR_VERSION 
and __MINGW32_MINOR_VERSION.


Cheers,
Rob 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] New bug fix from v5.x release soon

[sisyphus1]

-Original Message- 
From: JonY via Mingw-w64-public 
Sent: Friday, October 27, 2017 9:07 PM 
To: mingw-w64-public@lists.sourceforge.net 
Cc: JonY 
Subject: Re: [Mingw-w64-public] New bug fix from v5.x release soon 


On 10/27/2017 02:39 AM, Liu Hao wrote:

With this patch the crash in question shall not happen on i686 and
x86_64 any more. Pushed to master.


Cherry-picked to v5.x.


Wonderful !!
Thanks to all involved for doing that.

Cheers,
Rob

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] New bug fix from v5.x release soon

[sisyphus1]

-Original Message- 
From: Liu Hao

Sent: Thursday, October 26, 2017 11:51 PM
To: mingw-w64-public@lists.sourceforge.net ; sisyph...@optusnet.com.au
Cc: JonY
Subject: Re: [Mingw-w64-public] New bug fix from v5.x release soon

The attached patch should fix the problem. This is a quick fix and I don't 
have time to test it, please test so we can push this patch before this 
release.


Is there a link that will tell me specifically what I need to do - ie what 
to download and patch, and what toolchain I should use to build it ?

I haven't actually built this stuff before.

Cheers,
Rob




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] New bug fix from v5.x release soon

[sisyphus1]

-Original Message- 
From: JonY via Mingw-w64-public

Sent: Thursday, October 26, 2017 10:03 PM
To: mingw-w64-public@lists.sourceforge.net
Cc: JonY
Subject: [Mingw-w64-public] New bug fix from v5.x release soon

Are there any bug fix commits from master that you think should go into 
v5.x?

Let me know ASAP, thanks.


Is https://sourceforge.net/p/mingw-w64/bugs/478/ being fixed ?

It's a bug that has continued to cause me grief over the last couple of 
years - largely because the perl5 developers have chosen to *not* work 
around it.


Cheers,
Rob





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

[sisyphus1]

-Original Message- 
From: Eli Zaretskii

Sent: Tuesday, September 12, 2017 3:19 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] Problems with using printf format specs with GCC 
7



Does Emacs do anything wrong in these cases?


Not sure what to make of the format warnings (I'll leave that to others), 
but I think the post that you cited does reveal an instance of Emacs doing 
something wrong wrt the redefining of _WIN32_WINNT.
This symbol appears to be redefined in Emacs source, having earlier been 
defined in _mingw.h:


C:/projects/emacs/nt/addpm.c:42:0: warning: "_WIN32_WINNT" redefined

Unless it's a mistake for _mingw.h to define this symbol in the first place, 
then I'm thinking that addpm.c should precede it's own definition with an 
'#undef _WIN32_WINNT'.


Cheers,
Rob




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

[sisyphus1]

-Original Message- 
From: Liu Hao

Sent: Thursday, June 22, 2017 11:46 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit 
compiler in strict ISO mode with all warnings enabled?



  So, I need to printf() uint64_t in my project, which is built in strict
ISO C11 mode and with all warnings enabled.

  If I try to use "%llu" I get warning that "unknown conversion type
character 'l' in format". If I use "%I64u" I get "ISO C does not support
the 'I64' ms_printf length modifier" warning.
  And, yes, I have _POSIX_C_SOURCE defined on compiler's command line.


In order to get C99 conforming `*printf()` functions you have to `#define 
__USE_MINGW_ANSI_STDIO 1` before inclusion of any standard headers. One 
preferable way to achieve that is adding `-D__USE_MINGW_ANSI_STDIO` into 
your CPPFLAGS.


This is what I invariably do, too.

However, in a recent post to a gmp mailing list ( 
https://gmplib.org/list-archives/gmp-bugs/2017-May/004162.html ), Keith 
Marshall discouraged this, warning that it was *not* guaranteed to continue 
to work into the future.


Here's the relevant bit (from that post) of what he had to say:

[--quote--]

I would also point out that, as a "__USE_*" feature test, users should *not*
define "__USE_MINGW_ANSI_STDIO" themselves; the correct way to enable it is
to enable any of the "__STRICT_ANSI__" standards options, or to stipulate
"_GNU_SOURCE", "_POSIX_C_SOURCE", or "_XOPEN_SOURCE" feature dependencies,
(the latter two with an associated version stipulation), any of which will
cause the MinGW runtime headers to enable "__USE_MINGW_ANSI_STDIO"
implicitly.  You may get away with an explicit definition today, but I will
offer no guarantee that a future MinGW Runtime release will not override any
such definition, just as GNU's glibc headers do for their "__USE_*" feature
tests.

[--end quote--]

AFAIK Keith's allegiance is with mpfr.org, and I don't know how/if those 
remarks relate to mingw-w64.


Any thoughts on that ?

Cheers,
Rob



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to access _Decimal64 functions in math.h

[sisyphus1]

-Original Message- 
From: JonY
Sent: Monday, May 08, 2017 8:47 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] How to access _Decimal64 functions in math.h

[snip]

>>
>> All I get is:
>>
>> C:\Users\sisyphus\AppData\Local\Temp\cc2vb9go.o:d64.c:(.text+0x2e):
>> undefined reference to `expd64'
>> collect2.exe: error: ld returned 1 exit status
>>
>> What else is needed ?
>>
>
> Unfortunately none of the math code is even implemented.
>
> The only part that somewhat works is the decimal float printf code, which 
> is buried under --enable-experimental in mingw-w64-crt. It isn't exactly 
> widely tested either.

Oh  I'll adjust my level of excitement accordingly ;-)

Thanks for the quick response !

Cheers,
Rob







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] How to access _Decimal64 functions in math.h

[sisyphus1]

Hi,

math.h prototypes a number of _Decimal32, _Decimal64 and_Decimal128 
functions - eg:

_Decimal64 __cdecl expd64(_Decimal64 _X);

But when I try to compile (gcc -o d64.exe d64.c):

/***/
/* d64.c */
#include 

int main(void) {

_Decimal64 x = 2.3DD, ret;

ret = expd64(x);

return 0;
}

/***/

All I get is:

C:\Users\sisyphus\AppData\Local\Temp\cc2vb9go.o:d64.c:(.text+0x2e): 
undefined reference to `expd64'
collect2.exe: error: ld returned 1 exit status

What else is needed ?

Cheers,
Rob



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005

[sisyphus1]

-Original Message- 
From: Mateusz Mikuła
Sent: Saturday, March 11, 2017 12:17 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005

> POSIX mkdir() is deprecated in favor of _mkdir() [1] and the reason of 
> deprecation is already explained here [2].

So ... how do I see the associated "deprecation" warning when compiling a 
program that contains a call to "mkdir" ?


C:\_32\C>type try.c

#include 
#include 


int main(void) {
  mkdir("foo");
  printf("done\n");
  return 0;
}

C:\_32\C>gcc -o try.exe try.c -Wall

C:\_32\C>gcc -o try.exe try.c -Wdeprecated

C:\_32\C>gcc -o try.exe try.c -Wpedantic

C:\_32\C>gcc --version
gcc (i686-posix-sjlj-rev1, Built by MinGW-W64 project) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



> [1] https://msdn.microsoft.com/en-gb/library/ms235326(v=vs.140).aspx
> [2] https://stackoverflow.com/a/33358701/5940067

It initially amused me to think that [2] should be classified as an 
explanation - as it tells us that MS did something that was perhaps 
unnecessary (which doesn't really "explain" why they did it).
But of course, in the broader sense of the meaning of "explanation", it does 
provide informative elaboration.

Cheers,
Rob



--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005

[sisyphus1]

-Original Message- 
From: Grégory Vanuxem
Sent: Saturday, March 11, 2017 2:02 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005


> But here comes my problem :
> In FriCAS there is a function to create a directory :
>
> --
> /* Make a directory returning 0 for success and -1 for failure */
>
> int
> makedir(char *path)
> {
> #ifdef S_IRWXO
>return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );
> #else
>return ( mkdir (path) );
> #endif
> }
> -

Is it the case that,in your earlier builds, S_IRWXO was *not* defined ?
And this is the first time you've built with S_IRWXO defined ?

My belief is that mkdir() must only ever be called on Windows with *one*
argument.
Therefore the correct thing for FricAS to do would be to replace:

#ifdef S_IRWXO
with:
#if defined(S_IRWXO) && !defined(_WIN32)

At least, that's the approach I've always taken.

I have no knowledge of what "MINGW_ATTRIB_DEPRECATED_MSVC2005" is about.

Cheers,
Rob


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

[sisyphus1]

-Original Message- 
From: sisyph...@optusnet.com.au
Sent: Friday, July 15, 2016 10:31 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

> .deps/exceptions.Tpo -c -o exceptions.lo exceptions.c
> Xexceptions.Tpo -c -o exceptions.lo exceptions.lo
> libtool: warning: libobj name 'exceptions.Tpo -c -o exceptions.lo 
> exceptions.lo' may not contain shell special characters.
> rm: unknown option -- c
> Try 'rm --help' for more information.

Turns out that the gcc-6.1.1 compiler that I downloaded contains malware - 
in the form of its own 'make'exe'.
That 'make.exe' is unsuitable for building mpfr in the msys shell - but it's 
the one that was getting used.
Removing it from the compiler's bin directory ensures the MSYS/MSYS2 shell's 
'make.exe' is used, and the build of mpfr then proceeds normally and 
successfully.

Cheers,
Rob 


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

[sisyphus1]

-Original Message- 
From: Vincent Torri
Sent: Friday, July 15, 2016 8:41 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

> isn't it in the texinfo package ?

Indeed it is - thank you.

Having installed texinfo, the build now proceeds for an extra second or so 
before terminating with:

#
Making all in doc
make[1]: Entering directory 'C:/_64/comp/mpfr-10613/doc'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory 'C:/_64/comp/mpfr-10613/doc'
Making all in src
make[1]: Entering directory 'C:/_64/comp/mpfr-10613/src'
C:/_64/gcc-mingw-611/gcc-6-win64/bin/make  all-am
make[2]: Entering directory 'C:/_64/comp/mpfr-10613/src'
C:/_64/msys64/usr/bin/sh.exe ../libtool  --tag=CC   --mode=compile 
gcc -D__USE_MINGW_ANSI_STDIO -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DLT_OBJDIR=\".libs/\" 
 -DHAVE_DOUBLE_IEEE_LITTLE_ENDIAN=1 -DHAVE_LITTLE_ENDIAN=1 
-DTIME_WITH_SYS_TIME=1 
 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 
-DHAVE_STRUCT_LCONV_DECIMAL_POINT=1 
 -DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 
-DHAVE_SETLOCALE=1 
 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SIGNAL=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1  
-DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_PRINTF_MAXLM=\"j\" -DMPFR_HAVE_NORETURN=1 
-DMPFR_HAVE_BUILTIN_UNREACHABLE=1 
 -DMPFR_HAVE_CONSTRUCTOR_ATTR=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 
-DHAVE_DENORMS_FLT=1 
 -DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 
 -DHAVE_NEARBYINT=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DMPFR_USE_THREAD_SAFE=1 
 -DMPFR_USE_C11_THREAD_SAFE=1 -DMPFR_WANT_DECIMAL_FLOATS=1 
-DMPFR_WANT_FLOAT128=1 
 -DMPFR_USE_STATIC_ASSERT=1 -DHAVE_ATTRIBUTE_MODE=1 -DPRINTF_L=1 -DPRINTF_T=1 
 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -DMPFR_LONG_WITHIN_LIMB=1 -I.   
-IC:/_64/msys_611/1.0/local/include 
  -Wall -Wmissing-prototypes -Wpointer-arith -O2 -pedantic -fomit-frame-pointer 
 -m64 -mtune=sandybridge -march=sandybridge -MT exceptions.lo -MD -MP -MF 
.deps/exceptions.Tpo -c -o exceptions.lo exceptions.c
Xexceptions.Tpo -c -o exceptions.lo exceptions.lo
libtool: warning: libobj name 'exceptions.Tpo -c -o exceptions.lo 
exceptions.lo' may not contain shell special characters.
rm: unknown option -- c
Try 'rm --help' for more information.
libtool: compile: 
 gcc -D__USE_MINGW_ANSI_STDIO -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
"-DLT_OBJDIR=\\.libs/\" -DHAVE_DOUBLE_IEEE_LITTLE_ENDIAN=1 
-DHAVE_LITTLE_ENDIAN=1 
 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 
-DHAVE_SYS_TIME_H=1 
 -DHAVE_STRUCT_LCONV_DECIMAL_POINT=1 -DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1 
-DHAVE_STDINT_H=1 
 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SIGNAL=1 
-DHAVE_LONG_LONG=1 
 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_PRINTF_MAXLM=\"j\" 
-DMPFR_HAVE_NORETURN=1 
 -DMPFR_HAVE_BUILTIN_UNREACHABLE=1 -DMPFR_HAVE_CONSTRUCTOR_ATTR=1 
-DMPFR_HAVE_FESETROUND=1 
 -DHAVE_DENORMS=1 -DHAVE_DENORMS_FLT=1 -DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 
-DHAVE_TRUNC=1 
 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 
 -DMPFR_USE_THREAD_SAFE=1 -DMPFR_USE_C11_THREAD_SAFE=1 
-DMPFR_WANT_DECIMAL_FLOATS=1 
 -DMPFR_WANT_FLOAT128=1 -DMPFR_USE_STATIC_ASSERT=1 -DHAVE_ATTRIBUTE_MODE=1 
-DPRINTF_L=1 
 -DPRINTF_T=1 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -DMPFR_LONG_WITHIN_LIMB=1 -I.  
-IC:/_64/msys_611/1.0/local/include -Wall -Wmissing-prototypes -Wpointer-arith 
 -O2 -pedantic -fomit-frame-pointer -m64 -mtune=sandybridge -march=sandybridge 
 -MT exceptions.lo -MD -MP -MF .deps/exceptions.Tpo -c -o exceptions.lo 
exceptions.c" -o exceptions.Tpo -c -o exceptions.lo exceptions.o
gcc.exe: error: exceptions.o: No such file or directory
gcc.exe: fatal error: no input files
compilation terminated.
rm: unknown option -- c
Try 'rm --help' for more information.
make[2]: *** [Makefile:769: exceptions.lo] Error 1
make[2]: Leaving directory 'C:/_64/comp/mpfr-10613/src'
make[1]: *** [Makefile:441: all] Error 2
make[1]: Leaving directory 'C:/_64/comp/mpfr-10613/src'
make: *** [Makefile:484: all-recursive] Error 1
#

This is the same error as I get in the msys shell when trying to build with 
gcc-6.1.1.

However, as I noted in my first post, there's no such problem with my 
mingw-w64 port of gcc-5.3.0.
I'm therefore predisposed to thinking that it's *not* an mpfr bug.

Maybe some bug in the way libtool interacts with gcc-6.1.1 ??
I mean, this excerpt from the above looks really odd to me:

libtool: warning: libobj name 'exceptions.Tpo -c -o exceptions.lo 
exceptions.lo' may not contain shell special characters.
rm: unknown option -- c
Try 'rm --help' for more information.

And I don't yet rule out the possibility that it's a PEBCAK - though I 
*have* made considerable efforts to ensure that's not the case.

Cheers,
Rob





--
What NetFlow Analyzer 

[Mingw-w64-public] [MSYS2] How do I install makefinfo

[sisyphus1]

Hi,

Using dongsheng's gmp-6.1.1 (win32 threads, seh) build.

I'm trying to build mpfr (svn revision 10613) in the msys2 shell and getting 
hammered early on in the 'make' stage with:

###
make[1]: Entering directory 'C:/_64/comp/mpfr-10613/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
rm -rf $backupdir && mkdir $backupdir && \
if (C:/_64/msys64/usr/bin/sh.exe /c/_64/comp/mpfr-10613/missing 
makeinfo --version) >/dev/null 2>&1; then \
  for f in mpfr.info mpfr.info-[0-9] mpfr.info-[0-9][0-9] mpfr.i[0-9] 
mpfr.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if C:/_64/msys64/usr/bin/sh.exe /c/_64/comp/mpfr-10613/missing 
akeinfo  --enable-encoding -I . \
-o mpfr.info mpfr.texi; \
then \
  rc=0; \
  CDPATH="${ZSH_VERSION+.}:" && cd .; \
else \
  rc=$?; \
  CDPATH="${ZSH_VERSION+.}:" && cd . && \
  $restore $backupdir/* `echo "./mpfr.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
/c/_64/comp/mpfr-10613/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
 You should only need it if you modified a '.texi' file, or
 any other file indirectly affecting the aspect of the manual.
 You might want to install the Texinfo package:
 
 The spurious makeinfo call might also be the consequence of
 using a buggy 'make' (AIX, DU, IRIX), in which case you might
 want to install GNU make:
 
make[1]: *** [Makefile:365: mpfr.info] Error 127
make[1]: Leaving directory 'C:/_64/comp/mpfr-10613/doc'
make: *** [Makefile:484: all-recursive] Error 1
###

Now, I'm not so sure that I really do need makeinfo, but my old msys shell 
seems to have it and I'm therefore guessing it must surely be available for 
msys2.
At least, if I can install makeinfo, I will surely get past this error.
However:

#
sisyphus@Owner-PC311012 MSYS /c/_64/comp/mpfr-10613
$ pacman -Ss makeinfo

sisyphus@Owner-PC311012 MSYS /c/_64/comp/mpfr-10613
#

(I guess it's possible that I had built makeinfo from source for that old 
msys shell.)

This same mpfr source builds trivially in the msys shell using gcc-5.3.0 
(posix threads, sjlj) but when I switch to the above 6.1.1 compiler I have 
no end of trouble (both in msys and msys2 shells).
And the only way I could build gmp-6.1.1 with this gcc-6.1.1 compiler was to 
build in the msys2 shell - though, again gmp-6.1.1 built fine in the msys 
shell with gcc-5.3.0.

Any pointers as to why this gcc-6.1.1 compiler is creating its own unique 
problems would also be gratefully received.

Cheers,
Rob 


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] complex: Add clog10*.

[sisyphus1]

-Original Message- 
From: JonY 
Sent: Sunday, March 20, 2016 10:52 AM 
To: mingw-w64-public@lists.sourceforge.net 
Subject: Re: [Mingw-w64-public] [PATCH] complex: Add clog10*. 

On 3/17/2016 22:36, Nakai Yuta wrote:
>> Hi All,
>> 
>> This patch implements clog10/clog10f/clog10l in libmingwex.
>> Please review:)
>> 

Sorry - I missed the original post.

No clog10q ? (For completeness.)

Cheers,
Rob



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Should i686 compilers allow the -m64 switch ?

[sisyphus1]

From: Ruben Van Boxem
Sent: Friday, January 22, 2016 4:59 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Should i686 compilers allow the -m64 switch 
?
2016-01-20 13:55 GMT+01:00 :

> I would say the 4.X.x behaviour is the expected one and GCC 5.3.0 is in 
> error. Could be that there is a reason for this though, so I'll leave it 
> to the experts.

In an offlist discussion about the problems with gmp, it was suggested to me 
that this new behaviour with 5.3.0 was added for cross-compilation 
capability.
It would be good to receive confirmation from the experts.

(Incidentally, specifying ABI=32 to configure provides a good fix to that 
gmp problem.)

Cheers,
Rob





--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Should i686 compilers allow the -m64 switch ?

[sisyphus1]

Hi,

Probably 2 dumb questions - my only excuse is that I haven't been forced to 
consider them before. And that's not a very good excuse.
My other sin is that this post pretty much repeats the question I've asked 
in:
http://sourceforge.net/p/mingw-w64/mailman/message/34780084/

With all of the mingw-w64 4.x.x i686 compilers that I have used (and there 
have been a few), any attempt to use the -m64 switch has been a fatal error:
sorry, unimplemented: 64-bit mode not compiled in

But then I downloaded the 5.3.0 i686-posix-sjlj toolchain from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.3.0/threads-posix/sjlj/i686-5.3.0-release-posix-sjlj-rt_v4-rev0.7z/download

It *does* allow the -m64 switch to be used.

So:

Question 1:
Given that the 4.x.x i686 compilers do not allow the -m64 switch, why should 
a 5.3.0 i686 compiler allow the -m64 switch to work ?

Question 2:
Conversely, given that the 5.3.0 i686 compiler allows the -m64 switch, why 
do the 4.x.x i686 compilers *not*  allow it ?

I may have follow-up questions, depending upon the answers to those two 
questions.

Cheers,
Rob




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] i686-posix-sjlj and gmp

[sisyphus1]

From: Ruben Van Boxem
Sent: Tuesday, January 19, 2016 7:24 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] i686-posix-sjlj and gmp
2016-01-19 7:07 GMT+01:00 :

>> Is this as expected with the i686-posix-sjlj compiler when moving from 
>> 4.x.x to 5.x.x ? (It's not something I was expecting.)

>
> I would say it's a bug in GMP's configure magic. If I remember correctly, 
> it was horrendously bad in detecting compiler target architecture around 
> the 4.x-5.x era.

I haven't struck this trouble with any of the 4.x.x compilers that I use.

> I solved it then by explicitly setting --host and --build, as well as 
> passing in CC and CXX, although I'm not sure these will be necessary for 
> the configure step to get the right results.

Thanks for the tip. I'll see if I can get the same approach to work.

> I can try to take a look tonight if it's still a problem for you.

By all means take a look - though I'm quite happy to continue on using the 
trouble-free 4.x.x compilers for a while.  Mainly I use 4.9.2 (i686 and 
x86_64), but I also use a couple of older ones.
I'd like to eventually switch to 5.3.0, and I was just "testing the water", 
so to speak.
So I guess it's a problem for me ... but it's a problem that doesn't have to 
be solved straight away :-)

Despite it's unexpected configuration, the i686 (5.3.0) shared and static 
builds of gmp-6.1.0 were fine, and all tests passed.
It wasn't until it came to building current mpfr svn repo source against 
those gmp builds that strange things started to happen. All of those 
"strange things" involved  pop-ups complaining about an "0xc07b" 
exception and, according to google, that error typically signifies a 32-bit 
vs 64-bit mismatch.
To me, this raised the following possibilities:
1) that the 5.3.0 i686-posix-sjlj toolchain was misconfigured;
2) that my gmp-6.1.0 build was misconfigured;
3) that the mpfr configure process was flawed.

At least I now know that with 5.x.x i686 builds, GMP_LIMB_BITS should be 32 
(not 64) and __GMP_CFLAGS should contain "-m32" (not "-m64") - as was the 
default with the 4.x.x i686 toolchains.
(I *expected* that would be the case ... but I wasn't entirely sure.)

> I'm assuming here there was no mixup in compiler packaging and the 5.3.0 
> toolchain does indeed target i686 like it should (I have no reason to 
> doubt this).

I have no reason to doubt this either ... but is there an easy way to verify 
?

Thanks Ruben. (One of the compilers I still use is an x86_64 4.7.x 
cross-compiler that you built.)

Cheers,
Rob



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] i686-posix-sjlj and gmp

[sisyphus1]

From: Ruben Van Boxem
Sent: Tuesday, January 19, 2016 7:24 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] i686-posix-sjlj and gmp
2016-01-19 7:07 GMT+01:00 :


> I'm assuming here there was no mixup in compiler packaging and the 5.3.0 
> toolchain does indeed target i686 like it should (I have no reason to 
> doubt this).

Well ... this 5.3.0 i686 compiler can be run in 64-bit mode - ie the "-m64" 
switch is not a fatal error, but it *is* a fatal error with the 4.x.x i686 
compilers.

Is this change in i686 behaviour from 4.x.x to 5.3.0 expected and accepted ?

As regards gmp's configure process, I think it simply detects that "-m64" is 
permitted, and therefore runs with it.

Cheers,
Rob




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] i686-posix-sjlj and gmp

[sisyphus1]

-Original Message- 
From: sisyph...@optusnet.com.au
Sent: Tuesday, January 19, 2016 10:29 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] i686-posix-sjlj and gmp


> From: Ruben Van Boxem


>> I solved it then by explicitly setting --host and --build, as well as 
>> passing in CC and CXX, although I'm not sure these will be necessary for 
>> the configure step to get the right results.

> Thanks for the tip. I'll see if I can get the same approach to work.

"--host=i686-pc-mingw32" is setting ABI=32 (instead of ABI=64).
I'll test further tomorrow. (It's getting late over here.)

Cheers,
Rob 


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] i686-posix-sjlj and gmp

[sisyphus1]

Hi,

On Windows 7, when I build gmp-6.1.0 in the msys shell using gcc-4.9.2 
(i686-posix-sjlj), ABI is set to 32 and the created gmp.h contains entries 
such as:

#define GMP_LIMB_BITS  32
and
#define __GMP_CFLAGS 
"-m32 -O2 -pedantic -fomit-frame-pointer -mtune=sandybridge -march=sandybridge"

(And the same holds for previous 4.x.x i686 compilers that I've used.)

A couple of days ago I grabbed gcc version 5.3.0 (i686-posix-sjlj-rev0, 
Built by MinGW-W64 project) from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.3.0/threads-posix/sjlj/i686-5.3.0-release-posix-sjlj-rt_v4-rev0.7z/download

When I use that compiler to build gmp-6.1.0, ABI is set to 64 and the 
created gmp.h contains entries such as:

#define GMP_LIMB_BITS  64
and
#define __GMP_CFLAGS 
"-O2 -pedantic -fomit-frame-pointer -m64 -mtune=sandybridge -march=sandybridge"

Is this as expected with the i686-posix-sjlj compiler when moving from 4.x.x 
to 5.x.x ? (It's not something I was expecting.)

Cheers,
Rob



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem casting long double to __float128

[sisyphus1]

-Original Message- 
From: sisyph...@optusnet.com.au
Sent: Saturday, March 07, 2015 12:20 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] Problem casting long double to __float128

 Hi,

 With the 64-bit gcc-4.9.2 compiler available from:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/sjlj/

 I have the issue that casting a long double inf to a __float128 results in 
 a __float128 nan.
 No such problem in casting a double inf - or with gcc-4.8.2 or 4.7.3.

Sorry - I *thought* it was a bug (which it is), but I wasn't sure about 
casting of floats (though I should have been).

Anyway, I found the conclusive info in appendix A of Kernighan  Ritchie 
(2nd edition):

[quote]
A6.4 Floating Types

When a less precise floating point value is converted to an equally or more 
precise floating type, the value is unchanged.
[end quote]

Cheers,
Rob 


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Problem casting long double to __float128

[sisyphus1]

Hi,

With the 64-bit gcc-4.9.2 compiler available from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/sjlj/

I have the issue that casting a long double inf to a __float128 results in a 
__float128 nan.
No such problem in casting a double inf - or with gcc-4.8.2 or 4.7.3.

Here's the demo program:

/***/

/* filename is bug492.c */
/*
built with:
   gcc -o bug492.exe bug492.c -lquadmath
*/

#ifndef __USE_MINGW_ANSI_STDIO
#define __USE_MINGW_ANSI_STDIO 1
#endif

#include stdio.h
#include quadmath.h
#include stdlib.h
#include float.h

int main(void) {
__float128 my_inf1, my_inf2;
double d;
long double ld;
char buf1[8], buf2[8];

  d = strtod (inf, NULL);
ld = strtold(inf, NULL);

printf(%e %Le\n, d, ld);


my_inf1 = (__float128) d;
my_inf2 = (__float128)ld;

quadmath_snprintf(buf1, 6, %Qe, my_inf1);
quadmath_snprintf(buf2, 6, %Qe, my_inf2);
printf(%s %s\n, buf1, buf2);

return 0;

}

/***/

Using the above gcc-4.9.2 it outputs:
inf inf
inf nan

Using the other mingw64 compilers that I have at my disposal (both 64-bit 
and 32-bit gcc-4.7.3 and gcc-4.8.2) it outputs:
inf inf
inf inf

Is this a bug in 4.9.2 ? ... or is there something inherently unguaranteed 
about casting a long double to a __float128 ?

Cheers,
Rob



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] quadmath bugs

[sisyphus1]

-Original Message- 
From: Óscar Fuentes
Sent: Sunday, November 02, 2014 8:51 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] quadmath bugs

 Here's the demo for verification of those crashes:

 [snip]

 Your test case runs with no crash (after uncommenting the *q function
 calls) on MinGW-w64 as distributed by MSYS2, which uses the latest
 MinGW-w64 runtime from Git and gcc 4.9.2.

That's good news, indeed !!
Thanks.

Cheers,
Rob 


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] quadmath bugs

[sisyphus1]

Hi,

CC'ing kmx (Strawberry Perl developer), FHI.

In quadmath.h there's a long list of math library function prototypes, 
beginning with acosq() ... through to ynq().

On 6/10/2013 I reported (to this list) a problem with expq crashing - and I 
still haven't struck a mingw-w64 compiler where this has been fixed. 
(Haven't tried anything later than 4.8.2, but.)
I've now found that expq, coshq, nearbyintq, tgammaq, and fmaq all cause 
runtime crashes when called. The rest of those math library functions seem 
fine, however.

Here's the demo for verification of those crashes:


#include stdio.h
#include quadmath.h

int main(void) {

   __float128 rop, op1 = 2.5Q, op2 = 3.6Q, op3 = 6.7Q;

   rop = expm1q(op1);
   printf(1 done\n);

   rop = cosq(op1);
   printf(2 done\n);

   /* The following, when uncommented, all crash */

   /* rop = expq(op1);*/
   /* rop = coshq(op1);*/
   /* rop = nearbyintq(op1);*/
   /* rop = tgammaq(op1);*/
   /* rop = fmaq(op1, op2, op3);*/

   printf(Done\n);

   return 0;
}



Built with:
gcc -o expq.exe expq.c -lquadmath

Latest mingw-w64 compilers that I've tried are the 32-bit and 64-bit 4.8.2 
compilers that ship with the 32-bit and 64-bit builds of Strawberry Perl 
5.20.0.
I've also checked with 64-bit 4.7.0 (which was one of Ruben's builds).
And I've also got a 4.7.3 that shipped with an earlier Strawberry Perl 
build.

With all of those compilers, the behaviour is the same.

If you require any further info (or these issues have already been 
addressed) please let me know.

And thank you for the excellent efforts you guys continue to make.

Cheers,
Rob



--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] How do I file a bug report ?

[sisyphus1]

Hi,

I've read the faq and visited http://sourceforge.net/p/mingw-w64/bugs/.
I've even searched the wiki.
But I haven't been able to work out how to file a bug report.

Back on Oct 6th, I reported to this list a bug in quadmath.h's expq() 
function - but I can't find any ticket for it.
I'm thinking that if that bug hasn't already fallen through the cracks, it 
very soon will.

So ... how do I best formalize the reporting of this bug ?

Cheers,
Rob 


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How do I file a bug report ?

[sisyphus1]

-Original Message- 
From: Óscar Fuentes

 sisyph...@optusnet.com.au writes:

 I've read the faq and visited http://sourceforge.net/p/mingw-w64/bugs/.
 I've even searched the wiki.
 But I haven't been able to work out how to file a bug report.

 You need a SF account. Log in with it and you will see a Create ticket
 on the left side of the page.

Thanks ... and done !!

Cheers,
Rob


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] quadmath.h's expq() crashes at runtime.

[sisyphus1]

-Original Message- 
From: JonY
Sent: Monday, October 07, 2013 12:00 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] quadmath.h's expq() crashes at runtime.

 On 10/6/2013 20:31, sisyph...@optusnet.com.au wrote:
  Hi,
 
  Here's the simple demo:
 
  /***
  #include quadmath.h
 
  int main (void) {
__float128 r;
r = expq(2.0Q);
return 0;
  }
 
  ***/
 
  With recent MinGW64 ports of gcc, that program builds ok, but running it
  results in a crash.
  Seems to happen with 4.6.3, 4.7.0 and 4.8.1 (both 32-bit and 64-bit
  versions); I haven't tried any other versions.
 
  No such problem with mingw.org's gcc-4.7.0, nor with gcc-4.6.3 on 
  Ubuntu.
 

 Confirmed:

 Program received signal SIGSEGV, Segmentation fault.
 fesetenv (envp=envp@entry=0x28fe40) at ../misc/fesetenv.c:59
 59  __asm__ volatile (ldmxcsr %0 : : m (_mxcsr));
 (gdb) list
 54env.__unused1 = 0x;
 55__asm__ volatile (fldenv %0 : : m (env)
 56  : st, st(1), st(2), st(3), 
 st(4),
 57  st(5), st(6), st(7));
 58if (__mingw_has_sse ())
 59  __asm__ volatile (ldmxcsr %0 : : m (_mxcsr));
 60  }
 61
 62return 0;
 63  }
 (gdb) p _mxcsr
 $1 = -1

 I'm not too clear what the asm code mean, Kai?

I guess I should file a bug report about this, so that it doesn't get lost.
Where's the place for that ?

Cheers,
Rob 


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] quadmath.h's expq() crashes at runtime.

[sisyphus1]

Hi,

Here's the simple demo:

/***
#include quadmath.h

int main (void) {
  __float128 r;
  r = expq(2.0Q);
  return 0;
}

***/

With recent MinGW64 ports of gcc, that program builds ok, but running it 
results in a crash.
Seems to happen with 4.6.3, 4.7.0 and 4.8.1 (both 32-bit and 64-bit 
versions); I haven't tried any other versions.

No such problem with mingw.org's gcc-4.7.0, nor with gcc-4.6.3 on Ubuntu.

Cheers,
Rob 


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] status of MSYS?

[sisyphus1]

From: Jim Michaels
Sent: Friday, August 09, 2013 9:23 PM
To: mingw64 users
Subject: [Mingw-w64-public] status of MSYS?

 it was said that cURL should be easy to build with mingw-w64. I have been 
 unable to build anything using MSYS other than using my own batch files as 
 a build environment. something is just not configured, and there's no 
 manual, and I am not a full-fledged *nix nut. MSYS just doesn't work.

I recently built curl-7.31.0 with mingw64. Had to do a bit of hacking, but 
much of that was probably because I was building against static libs.

Here's my notes:

###
In the configure script, precede every -lz with 
-lssh2 -lssl -lcrypto -lgdi32 -lz .
Replace -lidn with -lidn -liconv.
Replace -lrtmp with -lrtmp -lwinmm
Insert '#define CARES_STATICLIB 1' in the code in configure that checks that 
c-ares is good and recent enough.
In src/Makefile and tests/libtest/Makefile
precede every '-lcares' with '-lrtmp -lwinmm '.

Configure command:
./configure --prefix=C:/_64/msys/1.0/local --disable-shared --enable-static 
CPPFLAGS=-IC:/_64/msys/1.0/local/include 
LDFLAGS=-LC:/_64/msys/1.0/local/lib --enable-ipv6 --enable-ares 
--with-librtmp=C:/_64/msys/1.0/local/librtmp 
 --with-ssl --with-zlib  CC=x86_64-w64-mingw32-gcc 
CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld 
NM=x86_64-w64-mingw32-nm RANLIB=x86_64-w64-mingw32-ranlib 
OBJDUMP=x86_64-w64-mingw32-objdump STRIP=x86_64-w64-mingw32-strip

The --with-librtmp arg looks wrong. (librtmp is not in 
C:/_64/msys/1.0/local/librtmp). But whenever I altered it, configure broke, 
and I got sick of trying to find a correct setting that worked. In the end 
I stayed with the incorrect setting *because* it worked.
###

I think (but am not sure) that you could ignore a lot of that if you're 
building against dll's. (There would certainly be no need to define 
CARES_STATICLIB.)
Do your gcc, g++, ld, etc. executables have the 'x86_64-w64-mingw32-' prefix 
to their names ? If not, you can ignore the CC, CXX, LD, etc. settings in my 
./configure command.

I don't think it's exactly *easy* to build - especially if you decide to 
build ssl, librtmp, zlib, cares, libidn, libiconv, libssh2 and any others 
that might take your fancy. But it's do-able.
Some of the tests in the test suite failed for me - I think it's just that 
they weren't windows-friendly, but I don't really know.

Hope there's something there that helps.

Cheers,
Rob 


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw-w64 builds of gmp and mpfr

[sisyphus1]

 JonY 10wa...@gmail.com wrote:

  This a little more serious - those references are, indeed, not defined
  in libmpc.a. This smells to me like a bug in mpc itself. (Again, I'll
  have to take a closer look when time permits.)
 
 
 Hi,
 this looks like a real problem, I haven't encountered it before.
 
 I'll investigate further once I get the time; or until xeno shows up on 
 irc, he's been doing trying to make a win64 toolchain too. I'm sure he 
 has something to say.

I hacked my way past this problem as follows:

In both src/set_x.c and src/set_x_x.c I changed:

#if HAVE_INTTYPES_H
to
#if 1

and I changed

#ifdef _MPC_H_HAVE_INTMAX_T
to 
#if 1

Then ran 'make distclean' and started afresh. All was then fine, and all tests 
built and passed.

It seems that, somehow, HAVE_INTTYPES_H is untrue and _MPC_H_HAVE_INTMAX_T is 
undefined at the 'make' stage, but HAVE_INTTYPES_H is true and 
_MPC_H_HAVE_INTMAX_T is defined during the 'make check' stage.

I figured (perhaps incorrectly) that this was a problem with the mpc source, 
and posted to the mpc-discuss mailing list. My post there still awaits 
moderator approval as the post is just over their allowable 40kb in size. (I 
think it's the config.log which I sent as an attachment with that post that's 
providing most of that 40kb.)

Cheers,
Rob

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public