MINGW-packages: mingw-w64-i686-clang is built improperly

Hello, Some while ago I posted an issue regarding unordered_map and clang. This is still unfixed, and I well understand you because with a large number of headers included it is very hard to analyse. However, there are more similar cases.

Here some person supposedly had the same crash with -O3. Despite its validity the issue is unfixed and I was able to reproduce it with -O2 and -O3. Having it unfixed is understandable because it requires a lot of headers to track things down, having it closed is strange.

Since the second issue is closed, and since the first issue may not be related I created a new one. Here is a dead simple sample of code I extracted from iostream and friends to reproduce a crash:

struct A {
  char ok;
  void init();
  void method() {
    if (ok) init();
  }
};

static A a;
int main() {
  a.method();
}

Compile it with mingw-w64-i686-clang and use the following parameters:

clang++ -c -O2 t.cpp

These 12 lines of code are enough to isolate clang from any crazy library headers and are perfectly valid C++.

I verified the official clang 3.8.0 binary and had no issue with it. I did also check the same code on macOS where nothing similar exists either. All in all the issue is specific to your 32-bit builds of clang and according to the comments the issue is not present in cygwin as well.

Please fix it or remove clang from the package list. The compiler provided is not production ready and wastes the time of the people attempting to make the use of it.

Thanks 😃

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 16 (7 by maintainers)

Most upvoted comments

@yumetodo while reducing the bug I was constantly receiving a slightly different stack trace including the one similar to what you have. In many cases the output got simply corrupted (like those 0xffffffffffffffff), which looked to me in a way that a crash was simply delayed by some other condition. You could play with things to see this.

Even though you are somewhat right that it can only be speculated whether the issue is the same or not until it gets fixed, the crash itself is not the cause but a singal that the issue exists. Even if these crashes are caused by not the same functions (although I have strong doubts about it) it is very likely that the breach in them is caused by the same thing.

I’d rather not speculate but given that clang is qite multithreaded and the issue only happens on 32-bit binaries stack alignment might be related. Perhaps recompiling it with -mstackrealign could affect something.

vit9696 on Sep 17, 2016

I decided to give creduce a try with unordered_map in the background. Although it gave me something terrible I was able to identify the pattern I spotted and explained above fairly quickly after it finished. After some manual rewrite I ended up having pretty much the same example:

struct _Hashtable {
  void *_M_buckets;
  void _M_deallocate_buckets();
  ~_Hashtable() {
    if (_M_buckets)
      _M_deallocate_buckets();
  }
} a;

This makes some kind of a checklist:

A global variable (could be pointer or instance) of some class;
A member function prototype;
A class member that is not explicitly defined (static will not affect bug reproduction);
A member function call after that unevaluatable if condition;
Explicitly or implicitly called code function with an if condition.

At this step #886 can be closed I guess, since it is a duplicate. I do not see that being fixed without LLVM folks, can anybody get in touch with them and attempt to understand things? This looks like the same bug.

vit9696 on Aug 26, 2016