[cfe-dev] Building latest llvm/clang targeting mingw-64/gcc-6.2 on Windows

[Edward Diener via cfe-dev]

On 12/27/2016 6:49 PM, Reid Kleckner via cfe-dev wrote:
> On Tue, Dec 27, 2016 at 2:30 PM, Edward Diener via cfe-dev
> <cfe-dev at lists.llvm.org
> <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     I really appreciate your taking a look at this. If I report this
>     issue to GCC I will need to reduce it to code which shows the bug.
>     Since I am not a clang developer it is difficult for me to know
>     which llvm/clang source illustrates this problem, so I can reduce it
>     to a bug report.
>
>
> I went ahead and filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936

Thanks !

>
> Thanks for the offer, though. I linked the pre-processed source off of
> there, which could be further reduced.
>
>
>     You said that the problem goes away when you "disable frame pointer
>     omission". Does this mean that compiling with "-fomit-frame-pointer"
>     temporarily solves the problem ?
>
>
> Compiling with -fno-omit-frame-pointer hides the problem. Compiling with
> -O0 also hides the problem.

When I compiled with -O0 the problem still occurred. When instead I 
compiled with -fno-omit-frame-pointer the problem disappeared.

>
>
>     Also do you have any idea why the bug occurs for 32-bit generation
>     and not 64-bit code generation ?
>
>
> It has to do with thiscall being the default C++ member function calling
> convention, which is 32-bit only.

Ah !!! Makes sense.