Re: cygwin64 problems after update: gcc 4.8.3-2, cygcheck -p

2014-09-30 Thread Agner Fog
On 7/6/2014 04:15, Lakhsa wrote: G'Day, after having updated my cygwin64 installation (Win7-64) for OpenSSL development I have encountered 2 problems: * compiling for 32-bit with '-m32 -i686' now fails with internal compiler error: in extract_insn, at recog.c:2154 * cygcheck -p

Re: Why is __unix__ defined, and not __WINDOWS__ ?

2019-05-12 Thread Agner Fog
But the compiler generates a Windows executable following most of the Windows ABI (object file format, calling convention, etc.) On 12/05/2019 21.53, Hans-Bernhard Bröker wrote: Am 12.05.2019 um 20:22 schrieb Agner Fog: I have noticed that the gcc and clang compilers have defined

Re: Bug report. Clang sqrtl(-1) causes access violation

2019-05-10 Thread Agner Fog
$ uname -a CYGWIN_NT-10.0 DESKTOP-08PNUTF 3.0.6(0.338/5/3) 2019-04-06 16:18 x86_64 Cygwin $ clang --version clang version 5.0.1 (tags/RELEASE_501/final) Target: x86_64-unknown-windows-cygnus Thread model: posix InstalledDir: /usr/bin On 10/05/2019 21.54, Jose Isaias Cabrera wrote: Agner

Re: Bug report. Clang sqrtl(-1) causes access violation

2019-05-10 Thread Agner Fog
I can't believe that The Agner Fog posted on the Cygwin mailing list! This is the place to post bug reports, right? On 10/05/2019 15.50, Jose Isaias Cabrera wrote: Agner Fog, on Friday, May 10, 2019 08:57 AM, wrote... > >Bug description: > >The sqrtl function under Clang caus

Re: Why is __unix__ defined, and not __WINDOWS__ ?

2019-05-13 Thread Agner Fog
On 13/05/2019 07.39, Brian Inglis wrote: Not quite I believe Cygwin 64 bit programs follow the Unix 64 bit LP64 C programming memory model and the System V AMD64 ABI *NOT* the Windows 64 bit ILP64 C programming memory model and Microsoft x64 calling convention; see:

Bug report. Clang sqrtl(-1) causes access violation

2019-05-10 Thread Agner Fog
Bug description: The sqrtl function under Clang causes an access violation when the argument is negative. This error occurs only under Cygwin. This error occurs only with the sqrtl function, not with sqrt or sqrtf Attached: sqrt.cpp: program to reproduce the error. Compile clang sqrt.cpp

Why is __unix__ defined, and not __WINDOWS__ ?

2019-05-12 Thread Agner Fog
I have noticed that the gcc and clang compilers have defined the preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 when compiling a windows executable. Why is this? A C/C++ program will check for these macros if it wants to know which operating system you are compiling

Re: Inefficient use of 64-bit addresses in Clang

2019-08-13 Thread Agner Fog
It's a difference in memory model. clang 6.0.0 under ubuntu with --target=x86_64-pc-cygwin gives relative addresses, unless you specify -mcmodel=large. Cygwin clang with -mcmodel=small does the right thing: use relative addresses. The -mcmodel=small option appears to work differently for

Re: Clang is using the wrong memory model

2019-08-16 Thread Agner Fog
On 16/08/2019 11.52, Corinna Vinschen wrote: 2 GB. Think errno accessed from another DLL. Your application works only by chance. Good example. errno appears to be a global variable for historical reasons, but errno is implemented as a macro that translates to a call to the imported

Re: Clang is using the wrong memory model

2019-08-18 Thread Agner Fog
the more efficient small memory model. Agner On 17/08/2019 10.16, Corinna Vinschen wrote: Oe Aug 17 07:31, Agner Fog wrote: So errno was a bad example but you can try accessing e.g. __ctype_ptr__, __progname, optarg, h_errno, or use FE_DFL_ENV from another DLL, just for kicks

Re: Clang is using the wrong memory model

2019-08-18 Thread Agner Fog
On 18/08/2019 13.57, Corinna Vinschen wrote: Nope, Cygwin uses the Windows loader. Then, how do you do the extra linking? What is producing the "Cygwin runtime failure" message when loading/linking a DLL fails? If the medium model is wasteful in clang, that's a clang optimization

Clang is using the wrong memory model

2019-08-16 Thread Agner Fog
as it is undocumented. I will ask you to please join the discussion at https://bugs.llvm.org/show_bug.cgi?id=42983 so that we can clarify how to solve this problem. On 14/08/2019 07.51, Agner Fog wrote: It's a difference in memory model. clang 6.0.0 under ubuntu with --target=x86_64-pc

Re: Clang is using the wrong memory model

2019-08-16 Thread Agner Fog
e point me to a description of the DSO and pseudo-relocation. I cannot find it. But I suppose it inserts 64-bit addresses into some sort of GOT or PLT without using the traditional linker. Agner On 16/08/2019 13.11, Corinna Vinschen wrote: On Aug 16 12:38, Agner Fog wrote: On 16/08/2019 11.52, Corinn

Re: Clang is using the wrong memory model

2019-08-16 Thread Agner Fog
/2019 10.26, Corinna Vinschen wrote: On Aug 16 08:06, Agner Fog wrote: Cygwin Clang is using -mcmodel=medium as default for Win64, according to my tests, while the right model is -mcmodel=small -mcmodel=small is *only* the right model if the target is native Windows. If the target is a Cygwin

Clang collapses on template with 64 parameters

2019-08-06 Thread Agner Fog
Here's another bug report. Cygwin Clang fails when compiling a complicated program with big templates. The same program compiles OK on Linux clang. I have not made a minimal test case because smaller cases compile ok. The test case is too big for attaching to a mailing list, so I have made

Inefficient use of 64-bit addresses in Clang

2019-08-06 Thread Agner Fog
Clang is using 64-bit absolute addresses when accessing static data in 64-bit mode. This is inefficient because it requires an extra 10-bytes long instruction for loading an address into a register every time it needs to access static data. All other compilers use relative addresses. Example: