I am having some problems compiling a UPC code with complex numbers on my laptop
(Mac OS-X; code will eventually run on a Linux CentOS machine) . I was trying to use FFTW in the code, but that returned a lot of errors.
#include </Users/avinash/Programs/fftwinstall/include/fftw3.h>
Error during remote HTTP translation:
upcc: error during UPC-to-C translation (sgiupc stage):
In file included from code1xc.upc:9:
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: warning: type defaults to `int' in declaration of `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: warning: data definition has no type or storage class
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
/Users/avinash/Programs/fftwinstall/include/fftw3.h:373: syntax error before `fftwq_complex'
......
Then I did some google searching and I came across this link – https://hpcrdm.lbl.gov/pipermail/upc-users/2013-December/001758.html
Apparently, BUPC doesn't work with complex numbers on some platforms - http://upc.lbl.gov/docs/user/index.shtml
Programs which #include complex.h, and/or tgmath.h do not work on
certain platforms.
So tried to compile this simple code using complex.h mentioned in the online query and even that returned errors.
#include <upc.h>
#include <complex.h>
int main()
{
return 0;
}
Error during remote HTTP translation:
upcc: error during UPC-to-C translation (sgiupc stage):
In file included from code1xc.upc:7:
/usr/include/complex.h:45: syntax error before `cacosf'
/usr/include/complex.h:46: syntax error before `cacos'
/usr/include/complex.h:47: syntax error before `cacosl'
/usr/include/complex.h:49: syntax error before `casinf'
/usr/include/complex.h:50: syntax error before `casin'
....
So, what exactly am I doing wrong ? I will appreciate any help. Is this an issue only for Berkeley UPC or for GNU UPC as well ? My project requires shared complex arrays. I think there must be a way as FFTs have been mentioned many times in online lectures.
Thanks for your help !!
Portable UPC programs do not rely upon C99's complex.h header, because it is not universally supported by all compilers/systems. Instead they often define their own complex type as a two-element struct.
For example see this simple FT implementation
Another common approach is to keep separate arrays of real and imaginary components, depending on the needs of the application and the data layout expected by any client math libraries.
However neither of these is likely to be helpful if you need to complex trigonometry or use a library that relies specifically on C99 complex. Assuming you have a C compiler that supports complex, you could use it to compile a serial module linked to your UPC program. Alternatively you could try the clang UPC frontend, which I believe supports C99 complex on some platforms.
Related
I have been facing issues with using boost::asio::io_service::run in Linux, very very similar to this: creating a boost::asio worker thread with boost::thread under linux.
I see that the answer for that question is
"The error is be that boost::asio::io_service::run is overloaded, in which case you have to resolve the ambiguity."
Can someone tell me how does one resolve this ambiguity for it? Thanks.
I am in RHEL 7.7, coding using an Eclipse IDE. My Code segment is:
std::vector<boost::thread> threadPool;
boost::assio::io_service IOService;
.
.
threadPool.pushback(boost::thread(boost::bind(&boost::asio::io_service::run, &IOService)));
I get the error "Invalid overload of 'boost::asio::io_service::run' "
I see that boost::asio::io_service::run has two overloads:
std::size_t boost::asio::io_service::run()
std::size_t boost::asio::io_service::run(boost::system::error_code &ec)
I don't know how to resolve the ambiguity as they have the same return. If I try to add in a variable like this:
threadPool.pushback(boost::thread(boost::bind(&boost::asio::io_service::run(), &IOService)));
I get the error:
"Invalid Arguments 'Candidates are unsigned long int run()' "
and I don't know what to do.
Can someone teach a confused idiot like me what should i do? Is it an environment problem, a linking problem or a declaration problem?
EDIT 1: Using lambdas gives the error
'Address of overloaded function with no contextual type information'
which makes no sense and I assume is merely reiterating the ambiguity of the function.
This error does not show up in the Console window, which details the results of the Make, only in the Errors window. This makes me think it purely a IDE syntax check type error? GCC version is 4.8.5.
This is my code :
int x=65;
char ch{x};
And this is the warning when compiled with `-std=C++11 flag:
Narrowed conversion from "int to char"
But I think there should be an error as x is not a constant and we are initializing ch with a non-constant value. What actually happens?
You're right that the standard treats this as an error, and allows implementations to flat out reject this code.
However, implementations are almost never required to reject code that does not conform to the standard. They have to diagnose the problem, but if they attach the label "warning" to it and continue to accept the code, there is no problem.
In this case, C++11 made perfectly well-formed C++03 code into an error (not entirely your code, but char ch[] = {x}; used to be valid), so compilers have a good reason to treat it as only a warning: they want to accept as much formerly valid code as reasonable, or users might have a good reason to switch to another compiler.
clang will give you an error:
main.cpp:23:9: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list [-Wc++11-narrowing]
gcc as far as I remember decided to issue warning as there is too many source code that would be broken by such decision.
when you initialize variable using uniform initialization then narrowing conversions are forbidden.
MingGW's gcc (4.8.1) reports the following error (and more to come) when I try to compile Expstack.c:
parser.h:168:20: error: field '__p__environ' declared as a function
struct term *environ;
where 'environ' is declared inside 'struct term{ ... }'. In unistd.h you find
char **environ
but nowhere a '__p__environ'.
Some other fields are declared likewise, but are accepted. Subsequent errors related to environ are reported as follows
Expstack.c:1170:38: error: expected identifier before '(' token
case Term_src: return e->item.src->environ;
^
Cygwin's gcc (4.8.3) accepts these constructs and has done so over various versions since
2006 at least, and gcc with various versions of Linux before that.
The source text uses CRLF despite my attempts to convert to DOS, and this is my only guess for an explanation.
I'll appreciate clues or ideas to fix the problem, but renaming the field is not especially attractive and ought to be totally irrelevant.
This is very unlikely to have to do with CR/LF.
The name ought to be irrelevant but it isn't: this one relates to the Windows integration that MinGW does and Cygwin does not, as alluded to in http://sourceforge.net/p/mingw/mailman/message/14901207/ (that person is trying to use an extern environ that it expects to be defined by the system. Clearly, the fashion in which MinGW developers have made this variable available breaks the use of the name as a struct member).
You should report this as a MinGW bug. Unpleasant as it may be, in the interim, renaming the member is the simplest workaround. It is possible that a well-placed #undef environ might help, but no guarantees.
I'm currently trying to compile a snippet of ASN.1 code. It looks as follows:
RFC1213-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental FROM RFC1155-SMI
OBJECT-TYPE FROM RFC-1212;
mypersonaltest OBJECT IDENTIFIER ::= { experimental 1 }
tester OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS optional
DESCRIPTION "This is a test"
::= { mypersonaltest 1 }
END
Now I'm always getting an error on the line SYNTAX INTEGER:
ASN.1 grammar parse error near line 9 (token "SYNTAX"): syntax error, unexpected TOK_SYNTAX, expecting TOK_PPEQ
Actually, this should work according my example I got here. What am I doing wrong?
This looks like an old version of that specification that uses ASN.1 MACRO notation instead of ASN.1 Information Object Classes. The MACRO notation was removed from ASN.1 in 1994. Please consider finding a newer version of your specification that used Information Object Classes instead of the obsolete MACRO notation.
It is possible that the tool you are using does not support ASN.1 MACRO notation (which was removed from ASN.1 in 1994). You could try using the free online compiler at http://asn1-playground.oss.com/ which I believe still supports MACRO notation. Note that the definition of OBJECT-TYPE must be seen by the compiler before "tester" (which uses the OBJECT-TYPE macro) is parsed.
I will repeat, that you will save yourself many headaches if you use a version of your ASN.1 specification that uses Information Object Classes rather than the obsolete ASN.1 MACRO notation.
It should be OBJECT-TYPE, not OBJECT TYPE. There is something wrong with the MIB document, and you should try to find a proper version of it.
I'm fairly new to C++, and I'm likely in over my head, but that's the way it goes.
I'm working with a fairly large Win32 C++ project that uses Winsock for its network communications. I'm in the process of trying to convert a bunch of its thread management over to boost, but once I added the references to the boost libraries and what-not, I'm getting about 30 errors on this particular line of code:
bind(mLocalSocketFd, (struct sockaddr *) &localServerAddress, sizeof(localServerAddress));
The errors include things like:
error C2602: 'std::tr1::_Result_of2<_Fty,_Farg0,_Farg1>::_Type' is not a member of a base class of 'std::tr1::_Result_of2<_Fty,_Farg0,_Farg1>'
error C2868: 'std::tr1::_Result_of2<_Fty,_Farg0,_Farg1>::_Type' : illegal syntax for using-declaration; expected qualified-name
error C2784: 'bool std::operator <(const std::vector<_Ty,_Ax> &,const std::vector<_Ty,_Ax> &)' : could not deduce template argument for 'const std::vector<_Ty,_Ax> &' from 'std::tr1::_Bind_fty<_Fty,_Ret,_BindN>'
error C2784: 'bool std::operator <(const std::vector<_Ty,_Ax> &,const std::vector<_Ty,_Ax> &)' : could not deduce template argument for 'const std::vector<_Ty,_Ax> &' from 'std::tr1::_Bind_fty<_Fty,_Ret,_BindN>'
I presume that somehow I've managed to tell this particular file ("NetServer.cpp") to use the boost version of bind(), but for the life of me, I can't figure out where that's happening. The only portion of boost that I'm using is the boost/thread.hpp, and I'm not doing any namespace using's anywhere in NetServer.cpp or in the header files that it links to.
Any suggestions as to what I'm doing wrong, or how to troubleshoot it? It's obviously some stupid newbie thing, but I can't figure it out.
There's a Boost function called bind() which is a totally different thing from Winsock's bind().
You have two options if you need both functions available in a given module:
Don't say "using namespace boost". Instead, explicitly qualify uses of Boost in your code. I prefer this option since Boost is a third-party library and its short names may conflict both with other third-party libraries and with future versions of C++ that adopt Boost features. Occasionally I will say "using namespace boost" within a single function if it contains several uses of Boost.
Explicitly qualify the use of the global Winsock bind():
::bind(mLocalSocketFd, ...
As you can see from MSVC's cryptic error message, your bind call goes to std::tr1::bind.
So, probably you're using namespace std;.
As #Warren Young indicated, ::bind will direct your call to the unqualified bind identifier - which then is WinSock's in your case.
I've just encountered the same issue, and found an official Microsoft answer here: http://connect.microsoft.com/VisualStudio/feedback/details/500364/how-to-avoid-conflicts-between-tr1-bind-and-winsock-bind-function
Short version: Even if you are not calling boost namespace, I guess you have a using namespace std somewhere, and since I guess you are using VS2010, it has the tr1 extension, so using namespace std acts like using namespace boost for the bind() function with VS2010.
If you ever have anything call using namespace std in advance then
you make all of the names in namespace std available to unqualified
name lookup. Therefore, both Winsock's bind() and 's
bind() are considered during overload resolution, and because
's bind() is a template, it will usually win, but fail to
compile later.
Solution:
To fix this, call ::bind() when you want Winsock's bind(), and
std::bind() if you ever want 's bind(). When you call
::bind(), you're asking the compiler to look in the global namespace
only.
Or alternatively, don't use namespace std.