gcc 25% slower than clang 3.5 for adding complex numbers
gcc 4.9.2 has worse performance than clang 3.5 when dealing with complex numbers. See bug 64410: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 For adding two arrays with complex numbers, clang's vectoriser is better able to exploit the layout of complex numbers. Inner loop produced by gcc: .L52: movsd (%r15,%rax), %xmm1 movsd 8(%r15,%rax), %xmm0 addsd 0(%rbp,%rax), %xmm1 addsd 8(%rbp,%rax), %xmm0 movsd %xmm1, (%rbx,%rax) movsd %xmm0, 8(%rbx,%rax) addq $16, %rax cmpq %rsi, %rax jne .L52 Inner loop produced by clang: .LBB0_145: movupd -16(%rbx), %xmm0 movupd -16(%rax), %xmm1 addpd %xmm0, %xmm1 movupd %xmm1, -16(%rdi) movupd (%rbx), %xmm0 movupd (%rax), %xmm1 addpd %xmm0, %xmm1 movupd %xmm1, (%rdi) addq $2, %rbp addq $32, %rbx addq $32, %rax addq $32, %rdi addl $-2, %ecx jne .LBB0_145
value not set via reference
Which compiler is correct here - gcc or clang?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Consider the following code:
#include
struct blah {
inline double setval(unsigned int& x) const
{
x = 123;
return 456.0;
}
};
int
main(int argc, char** argv) {
blah blah_instance;
unsigned int val = ;
std::cout << blah_instance.setval(val) << " val: " << val << std::endl;
std::cout << blah_instance.setval(val) << " val: " << val << std::endl;
return 0;
}
when compiled with gcc 4.9.2, the above program produces:
456 val: <-- unexpected
456 val: 123
when compiled with clang 3.5:
456 val: 123
456 val: 123
Clang has the least surprising result. Is gcc relying on a loophole in
C++ legalese to muck up the order of evaluation?
Re: value not set via reference
On 30 January 2015 at 16:58, James Dennett wrote: > It's hardly just a loophole: C++ doesn't specify the order of evaluation, > so the code is wrong (i.e., non-portable, as you've found). > > Arguably this is a design problem with IOStreams, given how > tempting it can be to write code that assumes left-to-right evaluation, > but it's not a compiler bug. Okay, but what is the reason for changing the "expected" (left-to-right) order of evaluation? Is there an optimisation benefit? If not, why change the order to something unexpected?
wrong mirror on GCC mirror sites page
The list of mirror sites seems to have a bug: https://gcc.gnu.org/mirrors.html The mirror for Australia is listed as: http://mirrors-au.go-parts.com/gcc | ..., thanks to Dan Derebenskiy (dderebens...@go-parts.com) at Go-Parts. Going to the above site leads to a car parts seller. How did this get into the mirror list?
Re: wrong mirror on GCC mirror sites page
On 9 March 2015 at 23:08, Jonathan Wakely wrote: >> How did this get into the mirror list? > > Because they said they would provide mirrors: > https://gcc.gnu.org/ml/gcc/2014-06/msg00251.html > https://gcc.gnu.org/ml/gcc/2014-07/msg00156.html Upon closer inspection there's actually more junk in the mirror list site: Australia: http://mirrors-au.go-parts.com/gcc Russia: http://mirrors-ru.go-parts.com/gcc UK: http://mirrors-uk.go-parts.com/gcc/ US: http://mirrors-usa.go-parts.com/gcc Perhaps all mirror sites need to be first checked before putting them up on the list.
Re: wrong mirror on GCC mirror sites page
On 9 March 2015 at 23:31, Jonathan Wakely wrote: > They do get checked before being added. Did you check them before > declaring them junk? :-) Apologies. I incorrectly assumed that any mention of the "go-parts" domain was link spam, based on the Australian mirror being broken.
thread_local broken in gcc 4.8 ?
According to http://gcc.gnu.org/gcc-4.8/cxx0x_status.html
the keyword "thread_local" is supported in gcc 4.8 when using -std=c++11
However, thread_local seems broken. Let's say we compile a multi-file
program that uses thread_local:
g++ a.cpp -c -o a.o -std=c++11
g++ b.cpp -c -o b.o -std=c++11
g++ a.o b.o -o prog -std=c++11
We get the following error:
b.o: In function `TLS wrapper function for foo_instance':
b.cpp:(.text._ZTW12foo_instance[_ZTW12foo_instance]+0x5): undefined
reference to `TLS init function for foo_instance'
collect2: error: ld returned 1 exit status
gcc --version
gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)
file foo.hpp:
class foo {
public:
inline foo() {}
inline ~foo() {}
inline double bar() { return 123.456; }
};
file a.cpp:
#include "foo.hpp"
thread_local foo foo_instance;
file b.cpp:
#include "foo.hpp"
extern thread_local foo foo_instance;
int main(int argc, char** argv) {
double bar = foo_instance.bar();
return 0;
}
Re: thread_local broken in gcc 4.8 ?
On Mon, Jan 6, 2014 at 6:25 PM, Jakub Jelinek wrote: > Wonder if the ctor is really trivial it wouldn't be better to treat it as > not needing dynamic initialization, rather than trying to initialize it > dynamically. This is actually a reduced case scenario. In the original case the constructor is not trivial. > So, please file this into bugzilla. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
proposal: remove thread_local from supported C++11 features
The page covering C++0x/C++11 support in GCC, ie. http://gcc.gnu.org/projects/cxx0x.html states that the "thread_local" keyword is supported since GCC 4.8. However, thread_local is currently (gcc 4.8.2) too broken to be of real use: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58672 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163 Unless there are plans to fix it in gcc 4.8.3, I propose that thread_local be removed from the list of supported C++11 features, or at the very least changed to "partial". Having the feature as "supported" is plainly false advertising.
Re: proposal: remove thread_local from supported C++11 features
Paolo Carlini wrote: > .. if you are willing to concretely help, please open a meta-bug with > "[meta-bug] thread_local" in the summary and blocked by all the issues you > mentioned. Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Re: proposal: remove thread_local from supported C++11 features
Jonathan Wakely wrote: > Only if you don't read the pages properly. > "Important: GCC's support for C++11 is still experimental. " > "GCC provides experimental support for the 2011 ISO C++ standard." > Anyway, removing it from the list would achieve nothing. Eh? thread_local doesn't work. Stating that it works (as the C++11 support page states) is not helpful either. Removing will at the very least communicate that this feature is not ready.
