Clang v11.0 Bug

Started by MrBcx, October 14, 2020, 08:50:17 AM

Previous topic - Next topic

MrBcx

-FYI-

While putting Clang V11.0 through its paces today, I encountered a strange bug.

I have two batch files for compiling the 155 BCX console demos using clang -- they are identical
batch files except one uses -m32 and the other -m64.  I've been using these batch files for months,
as part of my BCX regression testing procedure.

What I encountered today involves only the batch file for compiling the console demos for 32-bit.
The batch file for creating 64-bit compiles correctly.   However, every one of the attempted 32-bit
compiles fail to complete and Clang issues these errors for all 155 console demos:

error: definition of builtin function '_InterlockedAnd64'
error: definition of builtin function '_InterlockedOr64'
error: definition of builtin function '_InterlockedXor64'
error: definition of builtin function '_InterlockedIncrement64'
error: definition of builtin function '_InterlockedDecrement64'
error: definition of builtin function '_InterlockedExchange64'
error: definition of builtin function '_InterlockedExchangeAdd64'

Clang V10.0 does not exhibit this bug and instead compiles
the 155 console demos just fine in both 32-bit and 64-bit.


I uninstalled Clang V11, rebooted, installed V10, rebooted, and now all is well again.

Now you know what I know.  -MrBcx-

jcfuller

I have no reason to compile for 32bit so this is a not a deal stopper for me.
Maybe a portent of thinks to come?
Only 64bit apps on a 64bit OS?

My results:
Formatted  C:\BcxAdp\Examples\Con_Demo\S00.c
Using Visual Studio BuildTools 2019
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.7.5
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
InsertOptArg Ver 1.0.0.9  an Optional Parameter fixup for a Generic c Compiler
Compiling "S00.c" To " a Windows Console App"
libcmt.lib(chkstk.obj) : fatal error LNK1112: module machine type 'x86' conflicts with target machine type 'x64'
clang-cl: error: linker command failed with exit code 1112 (use -v to see invocation)
Finished

MrBcx

I generated 155 .c files with 7.6.0..

MSVC 2015 compiled and linked all 155 demos in 32-bit and 64-bit

Ditto Clang v10

Ditto Mingw

Ditto Pelles

Ditto LccWin32 ( well, 32-bit, I gave up on Lcc-win64 long ago)

Life is good.

jcfuller

Kevin,

  With my install of 64bit LLVM 10 I cannot compile 32bit apps.
I did uninstall the 64bit version and installed the 32bit version and 32bit apps compiled.
I have not tried it with ver 11.0 as I don't need 32bit.

James

Robert

Quote from: MrBcx on October 14, 2020, 08:50:17 AM
-FYI-

While putting Clang V11.0 through its paces today, I encountered a strange bug.

I have two batch files for compiling the 155 BCX console demos using clang -- they are identical
batch files except one uses -m32 and the other -m64.  I've been using these batch files for months,
as part of my BCX regression testing procedure.

What I encountered today involves only the batch file for compiling the console demos for 32-bit.
The batch file for creating 64-bit compiles correctly.   However, every one of the attempted 32-bit
compiles fail to complete and Clang issues these errors for all 155 console demos:

error: definition of builtin function '_InterlockedAnd64'
error: definition of builtin function '_InterlockedOr64'
error: definition of builtin function '_InterlockedXor64'
error: definition of builtin function '_InterlockedIncrement64'
error: definition of builtin function '_InterlockedDecrement64'
error: definition of builtin function '_InterlockedExchange64'
error: definition of builtin function '_InterlockedExchangeAdd64'

Clang V10.0 does not exhibit this bug and instead compiles
the 155 console demos just fine in both 32-bit and 64-bit.


I uninstalled Clang V11, rebooted, installed V10, rebooted, and now all is well again.

Now you know what I know.  -MrBcx-

No problems here with LLVM 11.0


C:\dev\LLVM\bin\clang++ -m32 s29.cpp -o s29.exe


compiles and executes as expected.

jcfuller

Well crap!!
Robert,
  simple is best. I was trying to make it way too hard.
$ONEXIT "ASTYLE -pn $FILE$.c"
$ONEXIT "InsertOptArg $FILE$.c"
$ONEXIT "clang-cl -m32 $FILE$.c -o$FILE$.exe"

I did finally get the batch file to work.
Thank you.
  James

MrBcx

Quote from: jcfuller on October 14, 2020, 01:44:10 PM
Kevin,

  With my install of 64bit LLVM 10 I cannot compile 32bit apps.
I did uninstall the 64bit version and installed the 32bit version and 32bit apps compiled.
I have not tried it with ver 11.0 as I don't need 32bit.

James

JC,

I have Clang V10 64-bit installed.

Moments ago, I recompiled the 155 console apps for 32-bit.

Next, I  checked the Windows properties on several of those executables to insure they were, in fact, 32-bit and not 64-bit. They are indeed 32-bit, as the compatibility dialog allows me to set it all the way back to Windows 95.
If these were 64-bit apps, compatibility only lets you go back to Vista.


jcfuller

Kevin,
  I went back and reinstalled 64 bit ver 11.0 and all is fine after a bit of tweaking in my batch files.
Just compiled and ran a number of the console examples in both 32 and 64 bit with the "c" compilers using Mikes app.
As I said I am using clang-cl for both *.c  and *.cpp code.

All is well here with ver 11.0

James


MrBcx

Quote from: jcfuller on October 14, 2020, 08:18:05 PM
Kevin,
  I went back and reinstalled 64 bit ver 11.0 and all is fine after a bit of tweaking in my batch files.
Just compiled and ran a number of the console examples in both 32 and 64 bit with the "c" compilers using Mikes app.
As I said I am using clang-cl for both *.c  and *.cpp code.

All is well here with ver 11.0

James

Glad you got it sorted out. 

I tried V11 with 32-bit one more time but no bananas.  I'm beginning to think it has more to do
with MSVS 2015 than with Clang V11.  So, I'm sticking with V10 until there is a compelling reason
for me to change something.

jcfuller

Kevin,
  Why not just get the MSVC 2019 BUILD (No IDE) so we can all be on the same page? I have 2019 and 2017 on both my coding rigs (both build and the full ide). When I fire up Visual Studio Installer it lets me update (or not) all four. I just check for and run the latest from my batch files.


IF /I [%2] == [-m32] (
  SET XTYPE=x86
  GOTO gotit
)
IF /I [%2] == [-m64] (
  SET XTYPE=x64
)

IF EXIST "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" (
  ECHO Using Visual Studio BuildTools 2019
  CALL "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" %XTYPE%
  GOTO got_tools
)

         
IF EXIST "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" (
  ECHO Using Visual Studio Cummunity 2019
  CALL "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" %XTYPE%
  GOTO got_tools
)

IF EXIST "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" (
  ECHO Using Visual Studio BuildTools 2017
  CALL "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" %XTYPE%
  GOTO got_tools
)

IF EXIST "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" (
  ECHO Using Visual Studio Cummunity 2017
  CALL "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" %XTYPE%
  GOTO got_tools
)

IF DEFINED VS140COMNTOOLS (
  CALL "%VS140COMNTOOLS%..\..\VC\vcvarsall.bat" %XTYPE%
  GOTO got_tools
)


:got_tools



These were recently updated after an embarrassment here:
http://www.cplusplus.com/forum/windows/273083/
read down until I post my batch file.

freddie1 is the renowned Fred Harris.

James


MrBcx

Quote from: jcfuller on October 15, 2020, 05:07:48 AM
Kevin,
  Why not just get the MSVC 2019 BUILD (No IDE) so we can all be on the same page? I have 2019 and 2017 on both my coding rigs (both build and the full ide). When I fire up Visual Studio Installer it lets me update (or not) all four. I just check for and run the latest from my batch files.

( code snipped for brevity )

These were recently updated after an embarrassment here:
http://www.cplusplus.com/forum/windows/273083/
read down until I post my batch file.

freddie1 is the renowned Fred Harris.
James

JC,

1) "We" will never "all" be on the same page.   
2) I won't use VS17/19 or the (*cough*)  leaner Build Tools.  My tolerance for bloat has limits.
3) I like my batch files.
4) Fred Harris is a nice guy and a talented programmer.


jcfuller

#11
Quote
Kevin,
Bloat as in ?
James

JC,

Bloat, meaning  the many GB's of crap that MS seems intent defecating onto my SSD, much of it redundant DLL's, language files for every country on the planet, and thousands more that have nothing to do with the C++ compiler system that I selected to have installed.  THAT bloat.

Robert

Quote from: jcfuller on October 15, 2020, 01:33:12 PM
Kevin,
  Bloat as in ?
Bcx 7.5.9 built with VS2019 as a 64bit app with icon, manifest and version info comes in at 888KB.
Your CLANG build with VS2015 is 1032KB

James

Hi James:

What optimization flags have you got on the VS2019 command line?

jcfuller

Robert,
  I use my standard (fixed) VSCPP.BAT file.
Where %WARN% is /W1
%FN% -> bc.cpp
%F% -> bc
%WINVER% -> /DWINVER=_WIN32_WINNT_WIN10 /D_WIN32_WINNT=_WIN32_WINNT_WIN10
%VRES% here is empty because I compile the rc to res with GoRc after the third compile and use LineResToExe to add to bc.exe .
%SUBSYSTEM% -> /SUBSYSTEM:CONSOLE
%P4% - %P8% are empty

cl.exe  /O1 /Gd %WARN% /EHsc /MT %FN% /Fe"%F%.EXE" %WIN_VER% %VRES% %SUBSYSTEM%  %P4% %P5% %P6% %P7% %P8% /nologo /std:c++latest


James

Robert

Quote from: jcfuller on October 15, 2020, 03:32:35 PM
Robert,
  I use my standard (fixed) VSCPP.BAT file.
Where %WARN% is /W1
%FN% -> bc.cpp
%F% -> bc
%WINVER% -> /DWINVER=_WIN32_WINNT_WIN10 /D_WIN32_WINNT=_WIN32_WINNT_WIN10
%VRES% here is empty because I compile the rc to res with GoRc after the third compile and use LineResToExe to add to bc.exe .
%SUBSYSTEM% -> /SUBSYSTEM:CONSOLE
%P4% - %P8% are empty

cl.exe  /O1 /Gd %WARN% /EHsc /MT %FN% /Fe"%F%.EXE" %WIN_VER% %VRES% %SUBSYSTEM%  %P4% %P5% %P6% %P7% %P8% /nologo /std:c++latest


James

Thanks James. Smaller but slower.

I've given away my celice and have stopped flailing myself with chains and barbed wire and so too would not want to waste any more time than necessary.

Space is cheap, time is priceless.

Life is short,