: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jhand at austin dot rr.com
Created attachment 30235
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30235&action=edit
test_parse.cpp
In gcc-4.8.0 and gcc-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57489
Jim Hand changed:
What|Removed |Added
Version|unknown |4.8.1
Severity|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57489
--- Comment #1 from Jim Hand ---
One of my coworkers looked at the assembly and said that it appears g++ isn't
even generating code for the conditional "if (expected_v != actual_v ||
expected_i != actual_i)" when this occurs. It appears the compil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57489
--- Comment #3 from Jim Hand ---
Thanks Marc, that seems to allow the code to work properly. One thing that is
somewhat troubling, even though the code seems to work properly with the
parenthesis, is that changing the following without the parenth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57489
--- Comment #4 from Jim Hand ---
One of my coworkers, a former Intel employee, made the point that signed
integer overflow is precisely defined for X86, in that overflowing and then
underflowing will produce the correct value 100% of the time.
An
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57489
--- Comment #6 from Jim Hand ---
You are correct in that it is undefined in C.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57489
--- Comment #8 from Jim Hand ---
Do you not agree that the compiler is not handling this situation in a very
helpful manner? A warning at minimal would be helpful, but when there is code
that equivalently says the following and prints identical va
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jhand at austin dot rr.com
Created attachment 30499
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30499&action=edit
unordered_map.cpp
I have been looking at performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #3 from Jim Hand ---
As a simplification, I tried compiling the following code with gcc-4.6.3 into
assembly with gcc-4.6.3 and 4.8.1:
#include
bool contains(std::unordered_map a) {
return a.find(5) != a.end();
}
gcc-4.6.3 genera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #4 from Jim Hand ---
I compiled 4.9.0-20130714 today and ran the same tests. Here are the results
for the lookup loops with the times for each compiler:
4.6.3: 11536 microseconds
4.7.3: 12150 microseconds (5.3% slower than 4.6.3)
4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #6 from Jim Hand ---
Thanks for the information Francois. That makes a lot of sense for the erase()
case.
For a little more information, I also timed this with three boost
implementations and saw the following times for boost 1.47, 1.
11 matches
Mail list logo
