http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59509
--- Comment #1 from Albert Zeyer ---
Sorry, that was the error from my real app. From the test case, the error is:
test_prodtempl.cpp:24:6: error: redefinition of 'template
decltype (prod(a, b)) operator*(const T1&, const T2&)'
auto operator*(co
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ich at az2000 dot de
Test case:
namespace X {
template struct Mat{};
template struct MatExpr {};
template
MatExpr prod(Mat const& A, Mat const& B) { return MatExpr(); }
};
struct Mat2 {};
templat
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ich at az2000 dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45272
--- Comment #132 from ich at az2000 dot de 2009-07-22 20:54 ---
So that means that this C++ example could crash under certain circumstances
(depending on how far the compiler is optimising here)?
#include
#define third ((double)atoi("1")/atoi("3"))
int
--- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 ---
Will this workaround-patch be included in 4.4.1? Because otherwise the whole
4.4.1 release will be pretty much useless for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
--- Comment #10 from ich at az2000 dot de 2009-06-03 15:00 ---
Thanks a lot, works just fine. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
--- Comment #4 from ich at az2000 dot de 2009-06-01 21:36 ---
It runs now for >200 minutes, so I really think this is not normal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
--- Comment #3 from ich at az2000 dot de 2009-06-01 18:36 ---
Created an attachment (id=17943)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17943&action=view)
source file after preprocessor
This is the specific source after the preprocessor.
--
http://gcc.gnu.org/b
--- Comment #2 from ich at az2000 dot de 2009-06-01 18:35 ---
This only happens with -O3. Without specific optimisation, it compiles just
fine. With all other GCC versions I have tried so far (GCC 4.4, GCC 4.3, GCC
4.0 and a lot others) it works fine (with any possible optimisation
--- Comment #1 from ich at az2000 dot de 2009-06-01 18:32 ---
gdb> c
q
^C
Program received signal SIGINT, Interrupt.
___
Error while running hook_stop:
Value can't be converted to integer.
0x007
akes forever and doesn't really process
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ich at az2000 dot de
GCC host triplet: amd64
GCC target triplet: amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
--- Comment #5 from ich at az2000 dot de 2009-06-01 18:02 ---
Perhaps that was anyway clear from the report, but I didn't noted the most
important point directly: The problem occurs only with -O3. If I don't set a
specific optimisation, it works.
--
http://gcc.gnu.or
--- Comment #4 from ich at az2000 dot de 2009-06-01 16:52 ---
Created an attachment (id=17941)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17941&action=view)
source file after preprocessor
I just created the temporary source file (via -save-temps) and attached it.
--
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ich at az2000 dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40322
--- Comment #3 from ich at az2000 dot de 2009-06-01 16:34 ---
I have commented out the check in tree-ssa-pre.c:2501, and then, after eating
up about 8GB memory (that was all available), I got this:
c++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <h
--- Comment #2 from ich at az2000 dot de 2009-06-01 14:50 ---
The specific file which fails has a lot of inline code, perhaps that is the
reason for failing. There are certain reasons why we want to have that inline.
This is the file if you want to take a look:
http
--- Comment #1 from ich at az2000 dot de 2009-06-01 14:40 ---
Sorry, it was revision 148004.
I also tried with rev 148039, same error:
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In
function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*,
ority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ich at az2000 dot de
GCC host triplet: amd64
GCC target triplet: amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
--- Comment #129 from ich at az2000 dot de 2009-05-18 14:24 ---
I am a bit wondering if this bug is also for the case (a < b) && (b < a) ==
true. Is it?
Because if so, this becomes way more serious, as for example std::set
is broken then (and depending on the STL impl
--- Comment #4 from ich at az2000 dot de 2009-05-18 13:38 ---
Created an attachment (id=17888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17888&action=view)
simpler test case (now for wrong ordering case 1)
I was able to reproduce the first case now ("wrong ord
--- Comment #3 from ich at az2000 dot de 2009-05-18 13:17 ---
Some compiler information:
a...@acompneu ~/Programmierung $ g++ -Os -v -ggdb test_order.cpp -o test_order
&&
./test_order
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/g
--- Comment #2 from ich at az2000 dot de 2009-05-18 13:16 ---
This is a real problem, because in my real application, I tried to use a very
similar order in a std::set, defined like this:
struct CustomOrder {
bool operator()(const Tmp* a, const Tmp* b) const
--- Comment #1 from ich at az2000 dot de 2009-05-18 13:11 ---
Created an attachment (id=17887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17887&action=view)
testcase (c++)
This is the test code. I am hitting the "wrong ordering 2" code.
--
http://gcc
ignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ich at az2000 dot de
GCC build triplet: tried with GCC 4.1.2, 4.3.2 and 4.4.0
GCC host triplet: Gentoo Linux i386
GCC target triplet: Linux i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
--- Comment #7 from ich at az2000 dot de 2009-03-15 00:58 ---
Hm yea, I thought already about that. But I cannot think of a good (and easy)
definition when an assert() should be checked at compile time and whether not.
And thus, I am not sure if that is something which belongs into the
--- Comment #5 from ich at az2000 dot de 2009-03-15 00:10 ---
(In reply to comment #4)
> Also - I admit not having studied in detail all your requirements, sorry about
> that - I suppose you would be interested in static_assert, available with
> -std=c++0x, in gcc4.3.x (and
--- Comment #2 from ich at az2000 dot de 2009-03-14 19:48 ---
Really thanks a lot for that hint.
I did a small assert-implementation by my own:
http://openlierox.svn.sourceforge.net/viewvc/openlierox/include/cassert?view=markup
Btw., it seems that Apples GCC (even 4.2) does not
ary: check assert() at compile time if possible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ich at az2000 dot
28 matches
Mail list logo
