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 [any_bin
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 an
Wow 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
$ 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
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 for,
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 the
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:
http://www.unix.org/ve
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
i
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:
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 Li
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_
On 16/08/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 i
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
functio
nt 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
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
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 problem,
16 matches
Mail list logo
