[Mingw-w64-public] problems with _ftime import using non standard msv runtimes

Hi, using a fully static build toolchain: gcc.exe (rev0, Built by MinGW-W64 project) 4.8.2 build with the mingw-build scripts (github) on msys2 (Windows7) I've problems with the import of symbols only available on msvcrt. I use a customized 'specs' to ensure exclusive msvcr90 runtime dependancy

Re: [Mingw-w64-public] problems with _ftime import using non standard msv runtimes

/niXman/mingw-builds/issues/340 . using __ftime64 instead of _ftime would allow winpthread as well as openMP usage with runtime MSVCR90 and higher. _ftime in included in msvcrt only. Both symbols are equivalent, unless _USE_32BIT_TIME_T is defined. Cheers, Carl 2013-12-19 12:56 GMT+01:00 Carl

Re: [Mingw-w64-public] Debugging with GDB

You can also use backtrace-mingw: http://code.google.com/p/backtrace-mingw/ a much more recent version (public domain) is found here: http://wiki.eduke32.com/wiki/Building_EDuke32_on_Windows http://wiki.eduke32.com/wiki/Acquiring_the_EDuke32_Source_Code (see daily snapshots) compile it with:

[Mingw-w64-public] FPU control word on startup

Hi, during tests with my mingw builds variant mingw-w64-for-python https://bitbucket.org/carlkl/mingw-w64-for-python/downloads I stumpled upon a flaw in mingw-w64 FPU handling on startup. This is issued at mingw-w64 builds of numpy https://github.com/numpy/numpy/issues/5194 and test failures when

Re: [Mingw-w64-public] FPU control word on startup

the computation precision or long double size. see also http://www.exploringbinary.com/when-doubles-dont-behave-like-doubles/ 2014-11-23 11:08 GMT+02:00 Kai Tietz ktiet...@googlemail.com: 2014-11-23 9:17 GMT+01:00 Ozkan Sezer seze...@gmail.com: On 11/12/14, Carl Kleffner cmkleff

Re: [Mingw-w64-public] FPU control word on startup

of this decision. BTW. see Kahan about long doubles (in Java, though), http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf 2014-11-23 18:03 GMT+02:00 Carl Kleffner cmkleff...@gmail.com: What I'm talking about ist the following: CRT_fp10.o on startup executes FNINIT. According to http

Re: [Mingw-w64-public] FPU control word on startup

be the default for long doubles, even if Microsoft does differently. On Mon, Nov 24, 2014 at 3:57 AM, Carl Kleffner cmkleff...@gmail.com wrote: I don't see the point, why computation accuracy has to be set to 0x37f per default. Usually computations are done with single or double precision

Re: [Mingw-w64-public] FPU control word on startup

Hi Kai, you may take notice of some inconsistent behaviour. The master thread starts with extended precision. Newly created threads start with the MSVC standard double precision. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761175 #include pthread.h #include stdio.h void *thread_fun(void

Re: [Mingw-w64-public] FPU control word on startup

the caller. Unfortunately this is not garenteed by the CRT (blame Windows or me if I missed something). New threads seems to start with default values. Should be documented. 2014-11-25 21:58 GMT+01:00 Kai Tietz ktiet...@googlemail.com: 2014-11-25 21:49 GMT+01:00 Carl Kleffner cmkleff...@gmail.com: Hi

Re: [Mingw-w64-public] gfortran, open mp and floating point precision

The Windows ABI - see https://msdn.microsoft.com/en-us/library/ms235286.aspx - differes from the System V ABI - see http://www.x86-64.org/documentation/abi.pdf. MingW-W64 sets the x87 FPU control word register to extended precision. The 'standard' for Windows however is 'double precision'. See

Re: [Mingw-w64-public] gfortran, open mp and floating point precision

Hi, 2015-02-03 4:25 GMT+01:00 K. Frank kfrank2...@gmail.com: Hi Carl (and Pieter)! On Mon, Feb 2, 2015 at 5:29 PM, Carl Kleffner cmkleff...@gmail.com wrote: The Windows ABI - see https://msdn.microsoft.com/en-us/library/ms235286.aspx - differes from the System V ABI - see http

Re: [Mingw-w64-public] Universal CRT and Python support

Just one note, the underlying mingw-w64 C99 math routines could rely on the supplied math routines from the universal crt IMHO. Is this an foreseeable option for the future? 2015-05-19 10:21 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com: Now without zip... 015-05-19 10:17 GMT+02:00

Re: [Mingw-w64-public] [AD] UltraGDB-1.0.1 is now available, for FREE

That's great! Just curious: is gdb.exe to be expected to be configured with python? 2015-06-18 15:41 GMT+02:00 Xu,Chiheng chiheng...@gmail.com: Hi, folks, UltraGDB-1.0.1 is now available for FREE. On user's request, we now provide 32-bit version of installers. We also tested our product on

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

Edward, I'm really flashed about the enormous patience and tolerance from this community. However, you may or may not noticed, that there are different builds with configurations for mingw-w64 based toolchains available. What you need for your purpose is a toolchain that is based on statically

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

2015-06-23 10:18 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com: 2015-06-23 9:31 GMT+02:00 Alexpux alex...@gmail.com: 23 июня 2015 г., в 10:22, Ruben Van Boxem vanboxem.ru...@gmail.com написал(а): 2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es: So moving cc1plus.exe to

Re: [Mingw-w64-public] AVX support is broken in 64-bit mode! Will there ever be a fix?

"Intel® Architecture Instruction Set Extensions Programming Reference" lists the SIMD instructions with explicit 32 byte alignment requirements: *Table 2-6. SIMD Instructions Requiring Explicitly Aligned MemoryRequire 32-byte alignmentVMOVDQA ymm, m256VMOVDQA m256, ymmVMOVAPS

Re: [Mingw-w64-public] AVX support is broken in 64-bit mode! Will there ever be a fix?

Another link: https://connect.microsoft.com/VisualStudio/feedback/details/805738/visual-studio-2013-c-compiler-considers-unaligned-avx-data > Bill [MSFT] 13.05.2014 > This is by design. With /arch:AVX the default for vector memory access is unaligned. 2015-09-24 11:26 GMT+02:00 Carl Kl

Re: [Mingw-w64-public] Proposal for a C11 header and announcement of mcfgthread, a library that implements efficient C11 and C++11 thread support without using winpthread

Hi, most of the mcfgthread code is LGPL licenced (MCFLicense.txt ). Is this set in stone, or is it foreseen to change it to a more liberal licence? Another question is: is it still possible to use pthreads (via winpthreads) if gcc

Re: [Mingw-w64-public] Any more commits before v5.x branches out?

I would like to add a patch for math/fpclassify.c: --- mingw-w64/mingw-w64-crt/math/fpclassify.c2015-06-05 10:13:07.997781400 +0200 +++ mingw-w64/mingw-w64-crt/math/fpclassify.cmingwpy working copy @@ -17,7 +17,6 @@ and sets C1 flag (signbit) if neg */ int __fpclassify (double _x) {

Re: [Mingw-w64-public] Any more commits before v5.x branches out?

here it is. I tested this patch with master. Carl 2016-02-23 14:40 GMT+01:00 JonY <jo...@users.sourceforge.net>: > On 2/23/2016 17:40, Carl Kleffner wrote: > > I would like to add a patch for math/fpclassify.c: > > > > --- mingw-w64/mingw-w64-crt/math/fpclassif

Re: [Mingw-w64-public] Revert [ca451a] Handle __CTOR_LIST__ internally within mingw-w64

I can confirm, that gcc5.3.0 also fails with this commit, see https://github.com/mingwpy/mingwpy/issues/7. carl 2016-03-01 21:31 GMT+01:00 Martell Malone : > You have my go ahead to apply. > > There is a header setting for when building gcc or rather libgcc to > specify

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Just link your example with CRT_Fp8.o: g++ -O2 -std=gnu++11 main.cpp \mingw64\x86_64-w64-mingw32\lib\CRT_fp8.o With that it is ensured that the intermediate precision of the FPU is double precision even for the main thread. In the C99 standard this is FLT_EVAL_METHOD=1 The problem with

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Just to be sure: _fpreset() maps to either __asm__ ("fninit") // FPU extended precision or (* __MINGW_IMP_SYMBOL(_fpreset))() // FPU double precision Is this correct? depending on wether CRT_fp10.o is linked in (default for upstream mingw-w64) or CRT_fp8.o. My best guess is, that

Re: [Mingw-w64-public] __attribute__((__force_align_arg_pointer__)) and callbacks when SSE is enabled

Hi, what about making "-mincoming-stack-boundary=2" as a default for i686? Carl 2016-04-20 14:28 GMT+02:00 Kai Tietz : > Hi, > > this issue has bitten me some times already, too. Nevertheless I > don't think that adding this attribute to WINAPI, APIENTRY, ... are >

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

drmingw can be used to display post mortem information. It containes an embeddable library called ExcHndl too. Regards Carl 2017-05-26 22:13 GMT+02:00 Vincent Torri : > Hello > > On Fri, May 26, 2017 at 9:50 PM, Edward Diener >

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

Hi niXman, all 32bit builds are blocked by sf: "This file may contain malware and the automatic download has been disabled." 2017-08-21 21:50 GMT+02:00 niXman : > > Hi, > > The new builds of MinGW-W64 based on GCC-7.2.0 is uploaded. > MinGW-w64 master branch is used. >

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

Hi, in view of all the contributions you've done for us, you really deserve our gratitude. Hopefully we see more of you later and good luck with the job search. Cheers, Carl 2018-06-01 15:32 GMT+02:00 : > -Original Message- From: niXman > Sent: Friday, June 01, 2018 6:12 AM > To:

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 Donnell

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

TDIO 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 #

Re: [Mingw-w64-public] MinGW64 AVX Code Generation on Windows 64 Bit

Hi, this question is related to two mingw-w64 bug reports: (1) "Error: invalid register for .seh_savexmm" #681 Assembler Error: invalid register for .seh_savexmm when compiling with avx-512 https://sourceforge.net/p/mingw-w64/bugs/681/ see also: Bug 65782 - Assembly failure (invalid register for

Re: [Mingw-w64-public] sizeof long

The 64-bit compiler within cygwin64 supports the ILP64 data model, see https://cygwin.com/cygwin-ug-net/programming.html 2018-04-17 17:12 GMT+02:00 Vincent Torri : > On Tue, Apr 17, 2018 at 4:58 PM, wrote: > > Hi, > > > > Why is it that on

Re: [Mingw-w64-public] sizeof long

Sorry typo: the LP64 data modell is valid for the cygwin64 toolchain. That means long is 8 bytes. 2018-04-17 17:17 GMT+02:00 Carl Kleffner <cmkleff...@gmail.com>: > The 64-bit compiler within cygwin64 supports the ILP64 data model, see > https://cygwin.com/cygwin-ug-net/programming.h

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

Hi Nixman, is mingw-w64 trunk used, or the latest release? It is not clear from build-info.txt. Carl 2018-03-24 9:05 GMT+01:00 niXman : > Hi, > > > The new builds of MinGW-W64 based on 'GCC-7.3.0' and 'MinGW-w64 v5.x > branch' as 'rev0' was uploaded. > > > 32-bit: >

Re: [Mingw-w64-public] Posix versus Win32 binaries

BTW, what happend to https://github.com/lhmouse/mcfgthread? Is this a possible usable fast posix alternative? Carl Am Di., 3. März 2020 um 16:10 Uhr schrieb Liu Hao : > 在 2020/3/3 23:01, Vincent Torri 写道: > > > > but technically speaking, it can be implemented with the native > > condition

Re: [Mingw-w64-public] bug in sin(pi) ?

One could think about using OpenLibm. Julia is using OpenLibm as its math implementation. There is a nice comparison of glibc, OpenLibm, Musl and Intel as well AMD math implementations: "Accuracy of Mathematical Functions in Single, Double, Extended Double and Quadruple Precision" Paul Zimmermann

Re: [Mingw-w64-public] bug in sin(pi) ?

This behaviour is described here: Intel Underestimates Error Bounds by 1.3 quintillion in great detail. A possible solution could be the usage of the SLEEF Vectorized Math Library

Re: [Mingw-w64-public] MINGW trademark claims

FYI, in 2009 Earnie Boyd, MinGW project leader wrote the following: *https://sourceforge.net/p/mingw/mailman/message/21560977/ Re: [Mingw-users] The Fedora cross-compiler projectFrom: Earnie Boyd - 2009-02-12

Re: [Mingw-w64-public] MINGW trademark claims

FYI , you can find this: https://www.spi-inc.org/projects/mingw/ Am Sa., 8. Mai 2021 um 16:08 Uhr schrieb sisyphus : > On Sat, May 8, 2021 at 11:13 PM Zach Bacon wrote: > > > Because of trademarks, if it has mingw in the name, then it could > > constitute as a violation, regardless if it has

Re: [Mingw-w64-public] Setting Floating-Point Operation Precision Changes With Gcc 10.3

uch again for your help. >> >> Benjamin >> >> -Ursprüngliche Nachricht- >> Von: Carl Kleffner [mailto:cmkleff...@gmail.com] >> Gesendet: Donnerstag, 6. Mai 2021 16:50 >> An: mingw-w64-public@lists.sourceforge.net >> Betreff: Re: [Mingw-w64-pub

Re: [Mingw-w64-public] Setting Floating-Point Operation Precision Changes With Gcc 10.3

e that it makes the compilation results behave > different from the documentation in float.h? > > Benjamin > > -Ursprüngliche Nachricht- > Von: Carl Kleffner [mailto:cmkleff...@gmail.com] > Gesendet: Donnerstag, 6. Mai 2021 14:38 > An: mingw-w64-public@lists.sourceforge.net &g

Re: [Mingw-w64-public] Setting Floating-Point Operation Precision Changes With Gcc 10.3

This already helps me a lot. Thank you for your research. But I guess that > this is not perfect yet, is it? > > Benjamin > > -Ursprüngliche Nachricht- > Von: Carl Kleffner [mailto:cmkleff...@gmail.com] > Gesendet: Donnerstag, 6. Mai 2021 15:59 > An: mingw-w64-public@list

Re: [Mingw-w64-public] Setting Floating-Point Operation Precision Changes With Gcc 10.3

mingw-w64-public@lists.sourceforge.net; Carl Kleffner < > cmkleff...@gmail.com> > Betreff: Re: [Mingw-w64-public] Setting Floating-Point Operation Precision > Changes With Gcc 10.3 > > 在 2021-05-04 22:46, Carl Kleffner 写道: > > I can't reproduce this behaviour. With gcc-10.3

Re: [Mingw-w64-public] Setting Floating-Point Operation Precision Changes With Gcc 10.3

gt; > -Ursprüngliche Nachricht- > Von: Carl Kleffner [mailto:cmkleff...@gmail.com] > Gesendet: Donnerstag, 6. Mai 2021 16:50 > An: mingw-w64-public@lists.sourceforge.net > Betreff: Re: [Mingw-w64-public] Setting Floating-Point Operation Precision > Changes With Gcc 10.3 >

Re: [Mingw-w64-public] Setting Floating-Point Operation Precision Changes With Gcc 10.3

I can't reproduce this behaviour. With gcc-10.3 on msys2/ucrt64 as well as msy2/mingw64 I get consistent results, regardless if I link CRT_fp10.o, CRT_fp8.o or none of them. Cheers Carl Am Di., 4. Mai 2021 um 14:52 Uhr schrieb Benjamin Bihler < benjamin.bih...@compositence.de>: > Hello, > > I

Re: [Mingw-w64-public] MinGW64 AVX Code Generation on Windows 64 Bit

Hi all, please review and comment on https://github.com/msys2/MINGW-packages/pull/8317 . The idea of this binutils patch is to create unaligned rather than aligned instructions at the assembler stage (as.exe) regardless of the created assembler code by the user or the compiler. This is done by

Re: [Mingw-w64-public] Invalid DLL when linking VS2019 (vc142) lib

Hi, bad.pyd has a strange section .voltbl at the beginning. good.pyd looks as expected. (pyd-files are DLLs as used by CPython) Carl Am Sa., 22. Jan. 2022 um 15:11 Uhr schrieb Matthew Brett < matthew.br...@gmail.com>: > Hi, > > On Sat, Jan 22, 2022 at 12:40 PM Martin Storsjö wrote: > > > >

Re: [Mingw-w64-public] Invalid DLL when linking VS2019 (vc142) lib

I opened an github issue on that topic: https://github.com/matthew-brett/dll_investigation/issues/1 Carl Am Sa., 22. Jan. 2022 um 15:56 Uhr schrieb Carl Kleffner < cmkleff...@gmail.com>: > Hi, > > bad.pyd has a strange section .voltbl at the beginning. good.pyd looks as > expe

Re: [Mingw-w64-public] Broken linker in gcc?

Hi, I got exactly this error trying to include a MS Visual C build library during the link process. If this library contains a .voltbl section you will encounter this error. Maybe something of this kind is in your path to the libraries you don't get while manually running the link command. best