This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

2.10.0: Possible bug with Clang 5.0.1-2 on cygwin 64 bit (Win 10 N) when optimizing code


It looks like there is a bug in clang in cygwin when using optimizations (found by a contributor). You can find details on

Here is his comment in question:
After thoroughly researching this matter, I settled on a less-than-ideal, yet working, solution. I currently have the combination of Cygwin and Clang dispatching through calc_pmk (four times, in a loop) like non-Intel processors would do (see sha1-sse2.h near the end-of-file.)

In my research, I determined that Clang uses the same calling convention as GCC, and more precisely; the standard Windows x64 calling convention. This uses the registers rcx, rdx, and r8, in this order, for the first three parameters passed.

When Clang is told to NOT use optimizations (-O0), the code works perfectly and all unit-tests pass.

However, as soon as ANY optimizations (even code size related ones) are enabled; a disassembly shows that the parameters to our assembly functions are never actually loaded into the registers; and therefore, everything fails.

It seems as if this is a bug in Clang and the patches applied to it, by the Cygwin project.

If anyone is up to discussing this matter with Cygwin's team or with Clang's team, please drag me in to the conversation. Otherwise, I am considering this bug fixed, as of commit 3d3237e.

You can find "cygcheck -s -v -r > cygcheck.out" attached to this email

Attachment: cygcheck.out
Description: Text document

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]