Problem: MSVC creates different symbol names for 'extern "C" uint32 mulu32_high' when declared inside the cln namespace, and when defined inside it. Linking produces "unresolved external symbol" errors. ----- Which is allowed by the Standard (specifically, [dcl.link]). However, it also says: "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. [Note: because of the one definition rule (3.2), only one definition for a function or object with C linkage may appear in the program; that is, sucha function or object must not be defined in more than one namespace scope." ----- Solution: Moved declarations into global namespace and prefixed with cln_
Hi! On 09/10/2010 05:20 AM, Jan private wrote:
Problem: MSVC creates different symbol names for 'extern "C" uint32 mulu32_high' when declared inside the cln namespace, and when defined inside it. Linking produces "unresolved external symbol" errors.
----- Which is allowed by the Standard (specifically, [dcl.link]). However, it also says:
"At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. [Note: because of the one definition rule (3.2), only one definition for a function or object with C linkage may appear in the program; that is, sucha function or object must not be defined in more than one namespace scope." -----
Solution: Moved declarations into global namespace and prefixed with cln_
Thanks very much for submitting the patch. I see, however, three objections: 1) As it is, it won't work. Recursively greping for mulu32_high and those other extern "C" variables under src/base/ reveals that they are also used inside the assembler modules. Which is, of course, the entire reason why they must have C language linkage! This can should be fixed. 2) My reading of this section is that MSVC has a bug: "Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object." What do you mean when you write "Which is allowed by the standard [...]. However..."? Do you claim that your patch is fixing a problem in CLN or that it is working around a bug in MSVC? 3) I don't have access to MSVC. We've received many patches for CLN (and GiNaC, too) and applied most of them. Yet, it is still unclear to me what the status under MSVC is. Since patches keep coming in, I suppose that things are still not fully working. The way I see it is this: There are two major free compilers out there (GCC and Clang) that don't have any problem compiling the current git HEAD of both packages and it still looks like we are pampering around problems in an expensive piece of crap by a really big and annoying software manufacturer. This bothers me. Jan, please don't take this personal but you have to understand my position as one outsider who is irritated by a time-consuming continuous stream of little patches for compilation with MSVC. I will keep accepting patches for whatever compiler as long as they are not too disruptive. But I will only do so if the submitter explains what is accomplished with it: * Which compiler version has been used? * What exactly does the patch fix (a warning, a compile-time error, miscompilation)? * Are more workarounds necessary (compiler options, etc.)? You are, of course, more than welcome to review your patch under these criteria and resubmit it. Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello, On Mon, Feb 07, 2011 at 09:25:13AM +0100, Richard B. Kreckel wrote:
2) My reading of this section is that MSVC has a bug: "Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object." What do you mean when you write "Which is allowed by the standard [...].
Having an extern "C" variable/function in the namespace scope is allowed by the standard. However, there are some limitations which effectively deny the purpose of namespaces. That is, according to [dcl.link] "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object." For instance, in the code below namespace A { extern "C" int f(); } namespace B { extern "C" void f(); } A::f() and B::f() actually refer to the same function! In my opinion it's very confusing, and we'd better avoid using extern "C" functions (and variables) in the namespace scope.
However..."? Do you claim that your patch is fixing a problem in CLN or that it is working around a bug in MSVC?
The patch works around msvc bug, *and* it helps CLN to avoid potential problems. The name `mulu32_high' is generic enough, and if someone ever writes namespace mylibrary { extern "C" unsigned int mulu32_high; } we'll get an obscure bug.
3) I don't have access to MSVC. We've received many patches for CLN (and GiNaC, too) and applied most of them. Yet, it is still unclear to me what the status under MSVC is. Since patches keep coming in, I suppose that things are still not fully working.
I don't think this conclusion is correct. GCC-related patches keep coming in, too (to name few, commit 3c3275884, 44fa38df2, 352547eac, and so on). This doesn't mean that things are still not fully working, does it?
The way I see it is this: There are two major free compilers out there (GCC and Clang) that don't have any problem compiling the current git HEAD of both packages and it still looks like we are pampering around problems in an expensive piece of crap by a really big and annoying software manufacturer.
This is not completely correct: many (most?) of msvc-related patches fix buggy and/or nonportable code, such as incorrect iterator usage (incrementing end()), access beyond the vector limits, etc. Best regards, Alexei
Hi! On 02/08/2011 07:11 PM, Alexei Sheplyakov wrote:
The patch works around msvc bug, *and* it helps CLN to avoid potential problems. The name `mulu32_high' is generic enough, and if someone ever writes
namespace mylibrary { extern "C" unsigned int mulu32_high; }
we'll get an obscure bug.
Okay, thanks. The patch can be applied when it is completed. But the question remains: which version of MSVC stopped accepting the current code? This ought to be documented.
3) I don't have access to MSVC. We've received many patches for CLN (and GiNaC, too) and applied most of them. Yet, it is still unclear to me what the status under MSVC is. Since patches keep coming in, I suppose that things are still not fully working.
I don't think this conclusion is correct. GCC-related patches keep coming in, too (to name few, commit 3c3275884, 44fa38df2, 352547eac, and so on). This doesn't mean that things are still not fully working, does it?
But browsing through the commit log it becomes apparant that the GCC version for which a certain patch has become necessary is always well documented. On the other hand, this level of detail is absent in patches for M$. This is a remarkable pattern. So, when somebody asks me what version of that M$-compiler it's known to work with I'm absolutely clueless and don't even see a practical way to find out. Well, that irritates me. That said, I'll make it a habit to ask about compiler details before accepting a patch. And, please, let's also try to better document these details in the INSTALL file. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, here is a re-worked version of the patch. Compilers: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 (from the free Studio Express 2010 package) gcc and g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 Problem:
Having an extern "C" variable/function in the namespace scope is allowed by the standard. However, there are some limitations which effectively deny the purpose of namespaces. That is, according to [dcl.link]
"At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object."
For instance, in the code below
namespace A { extern "C" int f(); }
namespace B { extern "C" void f(); }
A::f() and B::f() actually refer to the same function! In my opinion it's very confusing, and we'd better avoid using extern "C" functions (and variables) in the namespace scope.
Second problem: MSVC has a bug where extern "C" declarations inside a namespace do not produce the same linker symbol as when they are used outside a namespace. The linker then produces "unresolved externals" error messages. Solution: Moved the following extern "C" declarations out of the cln namespace and prefixed them with cln_ : mulu32_high mulu64_high divu_16_rest divu_32_rest divu_64_rest N.B. There are more linker errors with MSVC, but I will address these in a separate patch. Best regards, Jan
Hi! On 02/14/2011 05:58 PM, Jan wrote:
here is a re-worked version of the patch.
Thank you.
Compilers: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 (from the free Studio Express 2010 package)
[...]
N.B. There are more linker errors with MSVC, but I will address these in a separate patch.
That confuses me. Is there a version of M$VC that I can add to the list of known platforms? Which one? Certainly not the one listed above, or am I misreading something? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, Richard! On Tue, Feb 15, 2011 at 10:00 AM, Richard B. Kreckel <kreckel@ginac.de> wrote:
Is there a version of M$VC that I can add to the list of known platforms?
No. There are more issues left, and these will be addressed by subsequent patches. Best regards, Alexei
participants (4)
-
Alexei Sheplyakov
-
Jan
-
Jan private
-
Richard B. Kreckel