Compiling this pixel shader:
float4 main() : SV_TARGET
{
bool4 b = bool4(true, false, true, false);
return asfloat(b);
}
with the command fxc.exe test.hlsl /T ps_5_0 fails:
Microsoft (R) Direct3D Shader Compiler 6.3.9600.16384 (using C:\Program Files (x86)\Windows Kits\8.1\bin\x64\D3DCOMPILER_47.dll)
Copyright (C) 2013 Microsoft. All rights reserved.
test.hlsl(13,12-21): error X3013: 'asfloat': no matching 1 parameter intrinsic function
test.hlsl(13,12-21): error X3013: Possible intrinsic functions are:
test.hlsl(13,12-21): error X3013: asfloat(float|half|int|uint)
compilation failed; no code produced
It works with an older version of the shader compiler though:
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Utilities\bin\x64\fxc.exe" /T ps_5_0 test.hlsl
Microsoft (R) Direct3D Shader Compiler 9.29.952.3111
Copyright (C) Microsoft Corporation 2002-2009. All rights reserved.
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
//
// fxc /T ps_5_0 a.hlsl
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------ ------
// no Input
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------ ------
// SV_TARGET 0 xyzw 0 TARGET float xyzw
//
ps_5_0
dcl_globalFlags refactoringAllowed
dcl_output o0.xyzw
mov o0.xyzw, l(1.000000,0,1.000000,0)
ret
// Approximately 2 instruction slots used
The MSDN page on asfloat does not mention that this changed, and lists the bool overload.
Is this a bug? Am I doing something wrong? Was this intrinsic removed intentionally? What should I use instead? (I actually used it in combination with asfloat(all(...)).)
asfloat(bool) should never have worked. asfloat (and asdouble) is essentially the HLSL equivalent of *reinterpret_cast<float*>(&x). This makes some sense on the integer data, but bool is problematic. The bit-field pattern of bool is ill-defined in HLSL so in theory it could be anything.
The compiler was updated somewhere in the Windows 8 era (i.e. post the DirectX SDK being declared legacy per MSDN) to "fix" this behavior. The #43 legacy DirectX SDK version of the D3DCompiler DLL was the last released compiler to accept asfloat on a bool.
The MSDN page was never updated to reflect this, so I've filed a doc bug to correct that.
Related
I'm using QtCreator 4.11.2 , installed via MSYS2, with ClangCodeModel enabled.
Here is my program (this is the result of creating a New Non-QT Plain C Application):
#include <stdio.h>
#include <stdbool.h>
_Bool a;
bool b;
int main()
{
printf("Hello World!\n");
return 0;
}
The .pro file is unchanged from the default:
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += \
main.c
The annotation compiler highlights an error saying stdbool.h cannot be found.
But it does not give an error for _Bool a; , so it is clearly running in C99 mode but has some problem with include paths. The "Follow symbol under cursor" option works, opening stdbool.h.
My question is: How do I configure include paths for the annotation compiler or otherwise fix this problem?
I have been unable to figure out how to set options for the annotation compiler or even which compiler binary it is using . Under Tools > Options > C++ > Code Model > Diagnostic Configuration it lets me add -W flags but does not let me add -I flags, a red message pops up saying the option is invalid.
Under Tools > Options > C++ Code Model inspector, there are no diagnostic messages, and the Code Model Inspecting Log shows stdbool.h being correctly found and parsed, as msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/stdbool.h.
If I disable the ClangCodeModel plugin then there are no errors , but I would like to use the clang version if it can be made to work as in general it has good diagnostics.
The result of clang --version in a shell prompt is:
clang version 10.0.0 (https://github.com/msys2/MINGW-packages.git 3f880aaba91a3d9cdfb222dc270274731a2119a9)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: F:\Prog\msys64\mingw64\bin
and if I compile this same source code using clang outside of QtCreator, it compiles and runs correctly with no diagnostics. So the annotation compiler is clearly not the same as the commandline clang?
The Kit I have selected in QtCreator is the autodetected Desktop Qt MinGW-w64 64bit (MSYS2)
The exact same symptoms occur if I make a Plain C++ project and try to include stdbool.h (which is required to exist by the C++ Standard, although deprecated), although interestingly it does accept <cstdbool>.
I have found a workaround of sorts: including in the .pro file the line:
INCLUDEPATH += F:/Prog/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/
causes the annotation compiler to work correctly, however this is undesirable as I'd have to keep changing it whenever I switch Kits because it also passes this to the actual build compiler, not just the annotation compiler.
Create file stdbool.h in C:\msys64\mingw64\x86_64-w64-mingw32\include and copy paste this code:
/* Copyright (C) 1998-2017 Free Software Foundation, Inc.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.
GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<http://www.gnu.org/licenses/>. */
/*
* ISO C Standard: 7.16 Boolean type and values <stdbool.h>
*/
#ifndef _STDBOOL_H
#define _STDBOOL_H
#ifndef __cplusplus
#define bool _Bool
#define true 1
#define false 0
#else /* __cplusplus */
/* Supporting _Bool in C++ is a GCC extension. */
#define _Bool bool
#if __cplusplus < 201103L
/* Defining these macros in C++98 is a GCC extension. */
#define bool bool
#define false false
#define true true
#endif
#endif /* __cplusplus */
/* Signal that all the definitions are present. */
#define __bool_true_false_are_defined 1
#endif /* stdbool.h */
Note
Creating a manual file stdbool.h works for me but its a sketchy and a temporary solution for now. Don't use this if you feel its too sketcy. I would rather use a alternative solution than this hack if it exist. This solution might not be good but it still works for me.
UPDATED: Added complete example and compiler information
I have Eclipse 2019-03 (4.11.0) with CDT 9.7.0.20190309 and the build-in compiler reports false positive errors while using std::index_sequence in C++17:
#include <gtest/gtest.h>
#include <utility>
#include <array>
class Sample {
public:
template<std::size_t N >
std::size_t get_percentage( void ) {
return N;
}
template<std::size_t... Is>
inline std::array<std::size_t, sizeof...(Is)> calculate_percentages( std::index_sequence<Is...> ) noexcept {
return { this->get_percentage<Is>()... };
}
template<std::size_t N>
inline std::array<std::size_t, N> get_percentages( void ) noexcept {
return this->calculate_percentages( std::make_index_sequence<N>() );
/* ^^^^^^^^^^^^^^^^^^^^^ : Invalid arguments ' Candidates are: std::array calculate_percentages(std::integer_sequence) ' */
}
};
TEST( IntegerSequence, InvalidArgumentsError ) {
Sample test;
std::array<std::size_t, 5> data = test.get_percentages<5>();
for( int i = 0; i < 5; i++ ) {
std::cout << data[i] << std::endl;
}
}
int main( int argc, char ** argv ) {
testing::InitGoogleTest( &argc, argv );
return RUN_ALL_TESTS();
}
But the normal compilation succeeds without any problem.
My CDT GCC Built-in Compiler Settings in
Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers is as follows:
${COMMAND} ${FLAGS} -E -P -v -dD -std=c++17 "${INPUTS}"
The same applies for CDT Cross GCC Built-in Compiler Settings.
Rebuilding the index does not helped in there.
The GCC version I am using:
gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Many thanks in advance to anyone willing to help...
The problem is caused by the fact that the standard library that comes with gcc 8 and newer uses a new compiler intrinsic called __integer_pack to implement std::make_integer_sequence (and related utilities like std::make_index_sequence).
Eclipse CDT's parser does not currently understand the __integer_pack intrinsic, and therefore it has trouble correctly parsing code that uses std::make_integer_sequence / std::make_index_sequence with these newer gcc versions.
I filed a CDT bug to track adding support for the __integer_pack intrinsic.
Meanwhile, a workaround you could employ is to use gcc 7 or older. If you need gcc 8 or newer to actually build your code, you could still tell Eclipse the look at the standard library headers of e.g. gcc 7 by replacing ${COMMAND} in the mentioned "built-in compiler settings" configuration with g++-7.
UPDATE: The Eclipse bug is now fixed, with the fix targeting CDT's 9.11 release (scheduled to be part Eclipse 2020-03).
I am trying to build an F# project on TeamCity. Unfortunately the build agent does not have F# installed so I have added the FSharp.Compiler.Tools nuget package to my project.
When teamcity tries to build my project I get the following error (on a brand new project created from the visual studio class library template).
[Fsc] Microsoft (R) F# Compiler version 4.1
[15:12:00][Fsc] Copyright (c) Microsoft Corporation. All Rights Reserved.
[15:12:02][Fsc]
[15:12:02][Fsc] C:\TeamCity\work\3c40581f0aabd3be\Source\MyProject\AssemblyInfo.fs(43, 1): error FS0010: Incomplete structured construct at or before this point in definition
[15:12:03][Step 8/21] Error message is logged
The project builds fine locally, both in VS2017 and using MSBuild from the command prompt.
Is there any way to fix this? I don't have access to install F# on the build agent.
Edit: This is the contents of AssemblyInfo.fs:
namespace MyProject.AssemblyInfo
open System.Reflection
open System.Runtime.CompilerServices
open System.Runtime.InteropServices
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[<assembly: AssemblyTitle("MyProject")>]
[<assembly: AssemblyDescription("")>]
[<assembly: AssemblyConfiguration("")>]
[<assembly: AssemblyCompany("")>]
[<assembly: AssemblyProduct("MyProject")>]
[<assembly: AssemblyCopyright("Copyright © 2017")>]
[<assembly: AssemblyTrademark("")>]
[<assembly: AssemblyCulture("")>]
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[<assembly: ComVisible(false)>]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[<assembly: Guid("7a1189cf-d923-4367-991c-d95b1f045712")>]
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [<assembly: AssemblyVersion("1.0.*")>]
[<assembly: AssemblyVersion("1.0.0.0")>]
[<assembly: AssemblyFileVersion("1.0.0.0")>]
do
()
Ok so it seems GitVersion was being called on the teamcity agent and was appending an AssemblyInformationalVersion attribute to the end of AssemblyInfo.fs (after the do ()). Adding an empty AssemblyInformationalVersion above the do () block fixed the issue: gitversion then modified the value of the existing attribute instead of adding a new one.
My product is being migrated from Delphi 6 to the newer Delphi XE3. The Delphi 6 compiler used to output list of files that were compiled to an executable:
Borland Delphi Version 14.0
Copyright (c) 1983,2002 Borland Software Corporation
ProjectName.dpr(X)
...
PathToSomeUnit.pas(X)
...
PathToSomeIncludedFile.inc(X)
...
X lines, X.XX seconds, X bytes code, X bytes data.
where "X" mean some numbers
We have an internal software for analyzing dependencies between applications and particular files - units and included files. This software uses the dcc32 console output (like this one above) as its input.
With the new Delphi XE3 we no longer call dcc32 directly, but we use MSBuild. Unfortunately, the console output is not the same as with Delphi 6. When the "Quiet compile" option is disabled, the console output has multiple blank lines in place of the compiled file list.
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
[multiple blank lines]
X lines, X.X seconds, X bytes code, X bytes data. (TaskId:65)
With the /verbosity:diagnostic parameter it looks as follows
Embarcadero Delphi for Win32 compiler version 24.0 (TaskId:65)
Copyright (c) 1983,2012 Embarcadero Technologies, Inc. (TaskId:65)
(TaskId:65)
(TaskId:65)
(TaskId:65)
(TaskId:65)
(TaskId:65)
(TaskId:65)
...
X lines, X.X seconds, X bytes code, X bytes data. (TaskId:65)
When calling dcc32 directly, there was a similar problem, but it was resolved with the "-B" compiler switch (-B = Build all units).
I tried a similar approach with MSBuild by adding /p:DCC_AdditionalSwitches=-B but still it outputs multiple blank lines.
Here's a possible solution:
Back up your files, etc.
Open a .NET Framework SDK v2.0 command prompt.
Disassemble Borland.Build.Tasks.Delphi.dll (located in your $(BDS)\bin directory):
ildasm Borland.Build.Tasks.Delphi.dll /out=Borland.Build.Tasks.Delphi.il
Edit Borland.Build.Tasks.Delphi.dcctask.xml (created by the previous step) and comment out the Ignore subnode of the OutputParsing node.
Reassemble it:
ilasm Borland.Build.Tasks.Delphi.il /dll
Register a strong name exception for it:
sn -Vr Borland.Build.Tasks.Delphi.dll
If you turned off the quiet mode as described in this answer, building your Delphi projects with MSBuild should now show the detailed compiler output.
Add --depends to DCC32 command line or /p:DCC_OutputDependencies=true
to msbuild, it will output a .d file that can be easily parsed, like the example below:
C:\publico\BUILD\temp\YourDPR.exe: YourDPR.dpr \
C:\blabla blabla\FrameWork\Base\biblioteca\dcus\unit15.dcu \
C:\blabla blabla\FrameWork\Base\biblioteca\dcus\unit13.dcu \
C:\bla bla\bla\LIBD5\Units\unit12.dcu \
C:\blabla blabla\FrameWork\Base\biblioteca\rxlib\units\unit1.dcu \
C:\blabla blabla\FrameWork\Base\biblioteca\rxlib\units\unit13.dcu \
C:\bla bla\bla\LIBD5\Units\unit1.dcu \
C:\bla bla\bla\LIBD5\Units\unit12.dcu \
Ps. You can hide those blank msbuild lines with /p:DCC_Hints=false;
Two IDL files, testbase.idl
module Test{
enum JobType{
TYPE1,
TYPE2,
TYPE3
};
struct UserContext{
string name;
string ssoToken;
};
};
testhello.idl:
#include "testbase.idl"
module Test
{
interface Hello
{
void createJob(in UserContext type);
};
};
and Hello.mpc content is:
project(testbaseIDL): taoidldefaults, anytypecode {
idlflags += -Wb,stub_export_macro=TEST_BASE_STUB_Export -Wb,stub_export_include=test_base_stub_export.h -Wb,skel_export_macro=TEST_BASE_SKEL_Export -Wb,skel_export_include=test_base_skel_export.h
IDL_Files {
testhello.idl
}
custom_only = 1
}
project(testhelloIDL): taoidldefaults, anytypecode {
idlflags += -Wb,stub_export_macro=TEST_HELLO_STUB_Export -Wb,stub_export_include=test_hello_stub_export.h -Wb,skel_export_macro=TEST_HELLO_SKEL_Export -Wb,skel_export_include=test_hello_skel_export.h
IDL_Files {
testhello.idl
}
custom_only = 1
}
project(test_base_server): naming, iortable, utils, avoids_corba_e_micro, anytypecode {
sharedname = test_base_server
after += *IDL
Source_Files {
testbaseS.cpp
}
Header_Files{
testbaseS.h
testbaseC.h
test_base_skel_export.h
}
dynamicflags += TEST_BASE_SKEL_BUILD_DLL TEST_BASE_STUB_BUILD_DLL
}
project(test_base_client): naming, iortable, utils,anytypecode {
sharedname = test_base_client
dynamicflags += TEST_BASE_STUB_BUILD_DLL
Source_Files {
testbaseC.cpp
}
Header_Files{
test_base_stub_export.h
testbaseC.h
}
}
project(testhelloserver): naming, iortable, utils, avoids_corba_e_micro,anytypecode {
sharedname = test_hello_server
dynamicflags += TEST_HELLO_SKEL_BUILD_DLL
libs += test_base_server test_hello_client test_base_client
Source_Files {
testhelloS.cpp
}
Header_Files{
testhelloS.h
testbaseS.h
test_hello_skel_export.h
}
}
project(testhelloclient): naming, iortable, utils,anytypecode {
sharedname = test_hello_client
dynamicflags += TEST_HELLO_STUB_BUILD_DLL
libs += test_base_client
Source_Files {
testhelloC.cpp
}
Header_Files{
testhelloC.h
testbaseC.h
test_hello_stub_export.h
}
}
I want to do some demo. The mpc would generate 4 main projects(testbaseClient, testbaseserver, testhelloServer and testhelloClient) and each projects would generate one dll and library and all of them are used as skeleton and stub for each IDL.
In VS2008, after building testUDL, testbaseclient, testbaseServer, the links for both testbaseserver and testbaseclient fail because link can not find some symbols. The error messages are:
1>testhelloC.obj : error LNK2019: unresolved external symbol "bool __cdecl operator::marshal(class TAO_OutputCDR &)" (?marshal#?$In_Var_Size_Argument_T#UUserContext#Test##VAny_Insert_Policy_Stream#TAO###TAO##UAE_NAAVTAO_OutputCDR###Z)
1>testhelloC.obj : error LNK2019: unresolved external symbol "void __cdecl operator::any_insert(class CORBA::Any *,struct Test::UserContext const &)" (?any_insert#?$Any_Insert_Policy_Stream#UUserContext#Test###TAO##SAXPAVAny#CORBA##ABUUserContext#Test###Z)
1>testhelloS.obj : error LNK2001: unresolved external symbol "void __cdecl operatortesthelloS.obj : error LNK2019: unresolved external symbol "bool __cdecl operator>>(class TAO_InputCDR &,struct Test::UserContext &)" (??5#YA_NAAVTAO_InputCDR##AAUUserContext#Test###Z) referenced in function "public: virtual bool __thiscall TAO::In_Var_Size_SArgument_T::demarshal(class TAO_InputCDR &)" (?demarshal#?$In_Var_Size_SArgument_T#UUserContext#Test##VAny_Insert_Policy_Stream#TAO###TAO##UAE_NAAVTAO_InputCDR###Z)
1>.\test_hello_serverd.dll : fatal error LNK1120: 3 unresolved externals
I understand the error: unresolved external symbol happens only if link could not find those symbol from itself or dependent libraries. Therefore, I added
libs += test_base_server test_base_client
for both testhelloclient and testhelloserver. After regenerating all project, the result is the same. The "unresolved external symbol" still there.
I suspect the two generated base library are wrong and I use command:
dumpbin /EXPORTS
to export all symbol and none reported unresolved external symbol are there.
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test_base_clientd.dll
File Type: DLL
Section contains the following exports for test_base_clientd.dll
00000000 characteristics
526C30F9 time date stamp Sat Oct 26 18:15:37 2013
0.00 version
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 00003130 ??4_Init_locks#std##QAEAAV01#ABV01##Z = ??4_Init_locks#std##QAEAAV01#ABV01##Z (public: class std::_Init_locks & __thiscall std::_Init_locks::operator=(class std::_Init_locks const &))
Summary
1000 .data
2000 .idata
3000 .rdata
1000 .reloc
1000 .rsrc
9000 .text
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test_base_serverd.dll
File Type: DLL
Section contains the following exports for test_base_serverd.dll
00000000 characteristics
526C2AEE time date stamp Sat Oct 26 17:49:50 2013
0.00 version
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 00003130 ??4_Init_locks#std##QAEAAV01#ABV01##Z = ??4_Init_locks#std##QAEAAV01#ABV01##Z (public: class std::_Init_locks & __thiscall std::_Init_locks::operator=(class std::_Init_locks const &))
Summary
1000 .data
2000 .idata
3000 .rdata
1000 .reloc
1000 .rsrc
9000 .text
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test_base_serverd.lib
File Type: LIBRARY
Exports
ordinal name
??4_Init_locks#std##QAEAAV01#ABV01##Z (public: class std::_Init_locks & __thiscall std::_Init_locks::operator=(class std::_Init_locks const &))
Summary
E1 .debug$S
14 .idata$2
14 .idata$3
4 .idata$4
4 .idata$5
16 .idata$6
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test_base_clientd.lib
File Type: LIBRARY
Exports
ordinal name
??4_Init_locks#std##QAEAAV01#ABV01##Z (public: class std::_Init_locks & __thiscall std::_Init_locks::operator=(class std::_Init_locks const &))
Summary
E1 .debug$S
14 .idata$2
14 .idata$3
4 .idata$4
4 .idata$5
16 .idata$6
Then what I am confused is that:
1) Would link requires all symbol available during making library project. What my past experience in unix is that all symbol is required only if it is on making executable file.
2) How to resolve this issue here? Should I add some arguments for testIDL projects?
[UPdate]:
Added all *C.cpp for testhelloclient and all *C.cpp and *S.cpp would make compilation work.
However, this is not as I expected. I want to compile each IDL into two libraries: one is for stub and another is for skeleton. Then in the future, I only need to deliver stub/skeleton with corresponding header files for other projects. It is unnecessary for skeleton/sub application to compile any of cpp files generated by IDL when .lib/.dll and header file is available.
Currently, none of *.lib files generated above contain symbol from *C.cpp or *S.cpp(the dumpbin result is similar as post previous, only 1 function). And other application would still report unresolve symbols because .lib does not contain any export symbols.
I read MSDN: http://msdn.microsoft.com/en-us/library/ms235636%28v=vs.90%29.aspx this afternoon. For export symbol of dll, the function is declared as:
static __declspec(dllexport) double Add(double a, double b);
but idl generated c header files seems not follow this way..
VC seems much different with GCC in Linux. Is there some solution?It is impossible for I to add _declsepc for each functions in IDL generated header files? The issue is simplified as: none of symbols is export in library generated from IDL in VC(I renamed title for more clarification)
[More update]
I go back to the tao_idl command, it seems it is caused by options like: -Wb,skeleton_export_include="headerfile.h" export_macro..
It seems all these files and macros are generated....Is there any better to gernated .mpc file and are these headerfile.h and macros?
[UPDATE]
It now works with updated mpc file(see above). The export files are generated by generate_export_file.pl which is in $ACE_ROOT/bin directory. The command is like:
generate_export_file.pl TEST_HELLO_STUB > test_hello_stub_export.h
Thanks all.
You have to add anytypecode also as base project in the other projects in the IDL file, not only with the IDL file itself. Also just use naming instead of namingexe, you only need to use the naming service stubs, not the full service implementation