The following:
#include
int main()
{
const bool a =(rand() % 20) > 5;
const bool b =(rand() & 1) == 1;
int x = rand() % 5, y = rand() % 2, z = rand() % 3, c = rand() % 4, d =
rand() % 5;
if (a & b) d = y * c;
else if (a & !b) c = 2 * d;
else if (!a &
On 15/04/2021 10:40 am, Frosku wrote:
On Wed Apr 14, 2021 at 9:49 PM BST, Paul Koning via Gcc wrote:
My answer is "it depends". More precisely, in the past I would have
favored those who decline because the environment is unpleasant -- with
the implied assumption being that their objections
On 15/04/2021 11:09 am, Adrian via Gcc wrote:
Eric S. Raymond :
Speaking as a "high functioning autist", I'm aware of the difficulties that
some of us have with social interactions - and also that many of us
construct a persona or multiple personae to interact with others, a
phenomenon known
On 30/03/2021 1:18 am, Richard Kenner wrote:
I think I will leave this discussion up to those who have more
familiarity with the guy than I do. There's no doubt that some of the
stuff Stallman has written creeps me the hell out, and I think it was
more the tone of the OP I objected to.
I
We are not talking about some single recent incident, but about
decades of problematic behavior. At the last face-to-face GNU Tools
Cauldron, everybody I talked to about it had some story about being
harassed by RMS, had witnessed such harassment or heard from or knew
someone who had been.
I
at 23:01, Soul Studios wrote:
Hi all,
recently have been working on a new version of the plf::colony container
(plflib.org) and found GCC9 was giving 10-12% worse performance on a
given benchmark than GCC8.
Previous versions of the colony container did not experience this
performance loss going from
Hi all,
recently have been working on a new version of the plf::colony container
(plflib.org) and found GCC9 was giving 10-12% worse performance on a
given benchmark than GCC8.
Previous versions of the colony container did not experience this
performance loss going from GCC8 to GCC9.
However
I guess the phrasing is a bit weak, "some users" obviously has to refer
to a significant proportion of users, "easy to avoid" cannot have too
many drawbacks (in particular, generated code should be of equivalent
quality), etc.
-Wclass-memaccess fits the "easy to avoid" quite well, since a
Not sure how kosher it is to address several replies in one email, but
I'm going to attempt it as there are overlapping topics:
Martin:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some classes have user-defined copy and default
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
Having benchmarked the alternatives memcpy/memmove/memset definitely
makes a difference in various scenarios.
The bypass of littering code with needless reinterpret_cast's
UPDATE: My bad.
The original compiler feature detection on the test suite was broken/not
matching the correct libstdc++ versions.
Hence the emplace_back/emplace_front tests were not running.
Told you so :-P
However, it does surprise me that GCC doesn't check this code.
It's a dependent
It's never called.
I added a call to abort() to that function, and the tests all pass. So
the function is never used, so GCC never compiles it and doesn't
notice that the return type is invalid. That's allowed by the
standard. The compiler is not required to diagnose ill-formed code in
It's never called.
I added a call to abort() to that function, and the tests all pass. So
the function is never used, so GCC never compiles it and doesn't
notice that the return type is invalid. That's allowed by the
standard. The compiler is not required to diagnose ill-formed code in
In the following case GCC correctly throws an error since
simple_return_value is returning a pointer, not a reference:
"#include
int & simple_return_value(int )
{
return
}
int main()
{
int temp = 42;
return simple_return_value(temp);
}"
However in deeply-nested
Doesn't look like I can create a GCC bugzilla account, but 7 years? Wow.
On 20/06/2017 3:48 p.m., Eric Gallager wrote:
On 6/19/17, Soul Studios <m...@soulstudios.co.nz> wrote:
Just noticed this:
while(something)
{
// stuff
if (num_element
Just noticed this:
while(something)
{
// stuff
if (num_elements == 0)
{
break;
--current_group;
}
}
doesn't trigger a warning in GCC 5.1, 6.3 and 7.1. The line after
"break;" is unused, probably should be before the break, ie.
The main problem with __assume is that it should never be used.
Literally, if you have to use it, then the code it refers to should
actually be commented out.
ps. This is a bit of a simplification - I should have stated, if the
assumption is wrong, it can lead to dangerous code which breaks.
Does this approach make sense in general? If it does I can probably
come up with more measurements.
Sounds good to me-not sure why there hasn't been more response to this, it
seems logical-
if functions can make assumptions such as pointerA != pointerB then that
leads the way for avoiding
Hi there-
quick question,
does deque as defined in libstdc++ allocate upon initialisation or upon
first insertion?
Trying to dig through the code but can't figure it out.
Reason being, it's insertion graphs seem to show a surprisingly linear
progression from small amounts of N to large
Hi guys,
I was wondering if any of you could explain this performance for me:
www.plflib.org/colony.htm#benchmarks
(full disclosure, this is my website and benchmarks - I just don't under
the std::list results I'm getting at the moment)
If you look at the iteration performance graphs, you'll
21 matches
Mail list logo
