[Bug middle-end/42255] [4.3 Regression] broken generated code when using -fprofile-arcs and -O2
--- Comment #6 from gael dot guennebaud at gmail dot com 2010-06-11 14:05 --- Created an attachment (id=20893) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20893action=view) A new test case preprocessed with gcc 4.3.4 for -fno-guess-branch-probability Hi, here is a new test case showing a very similar issue when compiling with -O2 only. To be crystal clear, when compiling this example with -O2 only, then the program returns the error: Test cwiseops(Matrixfloat, 1, 1()) failed in /home/gael/Coding/eigen2/test/cwiseop.cpp (80) test_ei_isApprox(m4.setConstant(s1), m3) and valgrind report a Use of uninitialised value of size 8. On the other hand, when compiling with -O2 -fno-guess-branch-probability, then the program terminates fine, and valgrind report no error. Since the -fguess-branch-probability optimization seems to be related to -fprofile-arcs, I believe both examples exhibits the same bug. I hope that helps. Also, this example (as the previous one) works fine with gcc 3.4, 4.0.1, 4.1, 4.2, 4.4, 4.5, Intel's ICC, and various versions of MSVC. -- gael dot guennebaud at gmail dot com changed: What|Removed |Added Attachment #19210|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
[Bug middle-end/42255] [4.3 Regression] broken generated code when using -fprofile-arcs and -O2
--- Comment #3 from gael dot guennebaud at gmail dot com 2010-03-15 18:25 --- Created an attachment (id=20111) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20111action=view) the test case preprocessed with 4.3.3 Oops, indeed it seems I messed up the first time. This one is gcc 4.3 approved! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
[Bug c++/31816] If a function foo is defined before declaring a template class AT, overloaded version of foo defined after the class declaration will not be available within class AT.
--- Comment #5 from gael dot guennebaud at gmail dot com 2010-02-02 20:44
---
I hit the same issue, and according to c++ standard, here we have a _dependent_
lookup, and so the qHash(int*) overloads should be found.
Here is an example directly taken from the C++ standard (14.6, #9):
#include iostream
void f(char) {std::cout char ;}
templateclass T void g(T t)
{
f(1); // f(char)
f(T(1)); // dependent
f(t); // dependent
}
void f(int) {std::cout int ;}
int main()
{
g(2);// will cause one call of f(char) followed
// by two calls of f(int)
g('a'); // will cause three calls of f(char)
}
according to the c++ standard, the output should be:
char int int char char char
but gcc (4.x) returns:
char char char char char char
so, bug or non-bug ?
--
gael dot guennebaud at gmail dot com changed:
What|Removed |Added
CC||gael dot guennebaud at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31816
[Bug debug/42255] New: Regression: broken generated code when using -fprofile-arcs and -O2
The attached program fails when compiled with -fprofile-arcs -O2. This is a unit test of a matrix library, and by failing I mean that it detects a wrong behavior. Valgrind reports an Conditional jump or move depends on uninitialised value(s). It works fine with gcc 4.2.4 and 4.4.1 regardless of the compilation options. It also works also fine with 4.3.3 if we remove the -fprofile-arcs flag. By fine, I also mean valgrind does not report any error. -- Summary: Regression: broken generated code when using -fprofile- arcs and -O2 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gael dot guennebaud at gmail dot com GCC build triplet: 4.3.3 GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
[Bug debug/42255] Regression: broken generated code when using -fprofile-arcs and -O2
--- Comment #1 from gael dot guennebaud at gmail dot com 2009-12-02 14:48 --- Created an attachment (id=19210) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19210action=view) the preprocessed test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #1 from gael dot guennebaud at gmail dot com 2009-06-24 08:07 --- Created an attachment (id=18055) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18055action=view) a complete example showing the problem usage: Works: g++ -O3 instr_dependency.cpp -o instr_dependency ./instr_dependency Fails: g++ -O3 instr_dependency.cpp -o instr_dependency -DFAST ./instr_dependency -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #3 from gael dot guennebaud at gmail dot com 2009-06-24 10:53
---
There is a compilable example attached to comment #1.
Furthermore, I can reproduce the problem with gcc 4.1.3, 4.2.4, 4.3.2, and
4.4.0, so I don't think it is a duplicate of PR40141.
FYI, in the meantime I workaround the issue using inline assembly:
inline __m128 ploadu(const float* from)
{
__m128 res;
asm(movsd %[from0], %[r]
: [r] =x (res) : [from0] m (*from), [dummy] m (*(from+1)) );
asm(movhps %[from2], %[r]
: [r] +x (res) : [from2] m (*(from+2)), [dummy] m (*(from+3)) );
return res;
}
but that's not as portable as intrinsics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #4 from gael dot guennebaud at gmail dot com 2009-06-24 11:12
---
some additional info:
- compiling with -fno-strict-aliasing fix the issue, so perhaps this is not a
real bug but a feature ?
- on the other hand using the may_alias type attribute for casting does not
help:
inline __m128 ploadu(const float* from) {
typedef double __attribute__((may_alias)) doubleA;
typedef __m128 __attribute__((may_alias)) __m128A;
__m128 r;
r = (__m128A)(_mm_load_sd( (const doubleA*)(from) ));
r = _mm_loadh_pi(r, (const __m64*)(from+2));
return r;
}
I guess this is because the const doubleA* is then casted to a const
double* when calling the _mm_load_sd() function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
