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.
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 t
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
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
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_ins
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:
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
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
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.
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
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+
11 matches
Mail list logo
