[Bug c++/59509] template function definition. redefinition error

2013-12-14 Thread ich at az2000 dot de 
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*(const T1& a, const T2& b) -> decltype(prod(a, b)) {
  ^
test_prodtempl.cpp:19:6: note: 'template decltype
(X::prod(a, b)) operator*(const T1&, const T2&)' previously declared here
 auto operator*(const T1& a, const T2& b) -> decltype(X::prod(a, b)) {
  ^

[Bug c++/59509] New: template function definition. redefinition error

2013-12-14 Thread ich at az2000 dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59509

Bug ID: 59509
   Summary: template function definition. redefinition error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 {};

template
X::Mat prod(X::Mat const& A, Mat2 const& B) { return X::Mat(); }


template
auto operator*(const T1& a, const T2& b) -> decltype(X::prod(a, b)) {
return X::prod(a, b);
}

template
auto operator*(const T1& a, const T2& b) -> decltype(prod(a, b)) {
return prod(a, b);
}



int main() {}



I get the error:

mathutils.hpp:77:6: error: redefinition of 'template
decltype (prod(a, b)) operator*(const T1&, const T2&)'
 auto operator*(const T1& a, const T2& b) -> decltype(prod(a, b)) {
  ^
mathutils.hpp:72:6: note: 'template decltype
(viennacl::linalg::prod(a, b)) operator*(const T1&, const T2&)' previously
declared here
 auto operator*(const T1& a, const T2& b) -> decltype(viennacl::linalg::prod(a,
b)) {
  ^


It compiles fine with Clang 3.3.

[Bug middle-end/45272] New: comment about sqrt() implementation wrong: it is not from Carmack

2010-08-12 Thread ich at az2000 dot de 
The code:

/* sqrt() implementation: based on open source QUAKE3 code (magic sqrt
   implementation) by John Carmack.  Returns sqrt of X.  */

static double
mcf_sqrt (double x)
{
#define MAGIC_CONST10x1fbcf800
#define MAGIC_CONST20x5f3759df
  union {
int intPart;
float floatPart;
  } convertor, convertor2;

  gcc_assert (x >= 0);

  convertor.floatPart = x;
  convertor2.floatPart = x;
  convertor.intPart = MAGIC_CONST1 + (convertor.intPart >> 1);
  convertor2.intPart = MAGIC_CONST2 - (convertor2.intPart >> 1);

  return 0.5f * (convertor.floatPart + (x * convertor2.floatPart));
}


Read here:

http://en.wikipedia.org/wiki/Fast_inverse_square_root
http://www.beyond3d.com/content/articles/8/


-- 
   Summary: comment about sqrt() implementation wrong: it is not
from Carmack
   Product: gcc
   Version: unknown
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

[Bug rtl-optimization/323] optimized code gives strange floating point results

2009-07-22 Thread ich at az2000 dot de 


--- 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 main() {
  std::set m;
  m.insert(third);
  m.insert(third);
  return (m.find(third) != m.end()) ? 0 : 1;
}


Because this example only works if it is guaranteed that !(third < third &&
third > third), otherwise it would abort. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-07-15 Thread ich at az2000 dot de 


--- 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

[Bug tree-optimization/40323] [4.5 Regression] compiling just takes forever and doesn't really process

2009-06-03 Thread ich at az2000 dot de 


--- 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

[Bug tree-optimization/40323] compiling just takes forever and doesn't really process

2009-06-01 Thread ich at az2000 dot de 


--- 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

[Bug c++/40323] compiling just takes forever and doesn't really process

2009-06-01 Thread ich at az2000 dot de 


--- 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/bugzilla/show_bug.cgi?id=40323

[Bug c++/40323] compiling just takes forever and doesn't really process

2009-06-01 Thread ich at az2000 dot de 


--- 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).


-- 

ich at az2000 dot de changed:

   What|Removed |Added

  Component|tree-optimization   |c++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323

[Bug c++/40323] compiling just takes forever and doesn't really process

2009-06-01 Thread ich at az2000 dot de 


--- 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.
0x00780a0f in gimple_assign_single_p (gs=0x7f11dc839be0) at
../../gcc/gimple.c:1831
1831}
gdb> list
1826gimple_assign_single_p (gimple gs)
1827{
1828  return (gimple_code (gs) == GIMPLE_ASSIGN
1829  && get_gimple_rhs_class (gimple_assign_rhs_code (gs))
1830 == GIMPLE_SINGLE_RHS);
1831}
1832
1833/* Return true if GS is an assignment with a unary RHS, but the
1834   operator has no effect on the assigned value.  The logic is adapted
1835   from STRIP_NOPS.  This predicate is intended to be used in
tuplifying
gdb> print gs
$4 = (gimple) 0x7f11dc839be0
gdb> print *gs
$5 = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, gsops = {opbase = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops = 0x0}, op = {0x0}}, gsmem =
{membase = {opbase = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited
= 0x0, nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops =
0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2,
bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops
= 0x0}, vdef = 0x0, vuse = 0x0}, op = {0x7f11db7dccc0}}, omp = {gsbase = {code
= GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, body = 0x7f11db7df1d0}, gimple_bind = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, vars = 0x7f11db7df1d0, block = 0x0, body = 0x0}, gimple_catch
= {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, types = 0x7f11db7df1d0, handler =
0x0}, gimple_eh_filter = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0,
visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified = 0x0,
has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, types =
0x7f11db7df1d0, failure = 0x0}, gimple_phi = {gsbase = {code = GIMPLE_ASSIGN,
no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified =
0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, capacity
= 0xdb7df1d0, nargs = 0x7f11, result = 0x0, args = {{imm_use = {prev = 0x0,
next = 0x0, loc = {stmt = 0x7f11db7dccc0, ssa_name = 0x7f11db7dccc0}, use =
0x7f11dcb59a80}, def = 0x202205}}}, gimple_resx = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, region = 0xdb7df1d0}, gimple_try = {gsbase = {code =
GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf =
0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid =
0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, eval = 0x7f11db7df1d0, cleanup = 0x0}, gimple_wce = {gsbase =
{code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0,
plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74,
uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, cleanup = 0x7f11db7df1d0}, gimple_asm = {membase = {opbase =
{gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops =
0x0}, vdef = 0x0, vuse = 0x0}, string = 0x7f11db7dccc0 "\216", ni = 0x80, no =
0x9a, nc = 0xdcb5, op

[Bug c++/40323] New: compiling just takes forever and doesn't really process

2009-06-01 Thread ich at az2000 dot de 
 pad = 0x0, subcode = 0x74,
uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, cleanup = 0x7f11db7df1d0}, gimple_asm = {membase = {opbase =
{gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, def_ops = 0x7f11db7df1d0, use_ops =
0x0}, vdef = 0x0, vuse = 0x0}, string = 0x7f11db7dccc0 "\216", ni = 0x80, no =
0x9a, nc = 0xdcb5, op = {0x202205}}, gimple_omp_critical = {omp = {gsbase =
{code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0,
plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74,
uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, body = 0x7f11db7df1d0}, name = 0x0}, gimple_omp_for = {omp =
{gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, body = 0x7f11db7df1d0}, clauses = 0x0,
collapse = 0x0, iter = 0x0, pre_body = 0x7f11db7dccc0}, gimple_omp_parallel =
{omp = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, body = 0x7f11db7df1d0}, clauses = 0x0,
child_fn = 0x0, data_arg = 0x0}, gimple_omp_task = {par = {omp = {gsbase =
{code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0,
plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74,
uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block =
0x7f11dc83a120}, body = 0x7f11db7df1d0}, clauses = 0x0, child_fn = 0x0,
data_arg = 0x0}, copy_fn = 0x7f11db7dccc0, arg_size = 0x7f11dcb59a80, arg_align
= 0x202205}, gimple_omp_sections = {omp = {gsbase = {code = GIMPLE_ASSIGN,
no_warning = 0x0, visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified =
0x0, has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, body =
0x7f11db7df1d0}, clauses = 0x0, control = 0x0}, gimple_omp_single = {omp =
{gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, body = 0x7f11db7df1d0}, clauses =
0x0}, gimple_omp_continue = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0,
visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified = 0x0,
has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120},
control_def = 0x7f11db7df1d0, control_use = 0x0}, gimple_omp_atomic_load =
{gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0, visited = 0x0,
nontemporal_move = 0x0, plf = 0x0, modified = 0x0, has_volatile_ops = 0x0, pad
= 0x0, subcode = 0x74, uid = 0x0, location = 0x6480dd, num_ops = 0x2, bb =
0x7f11dc8865a0, block = 0x7f11dc83a120}, rhs = 0x7f11db7df1d0, lhs = 0x0},
gimple_omp_atomic_store = {gsbase = {code = GIMPLE_ASSIGN, no_warning = 0x0,
visited = 0x0, nontemporal_move = 0x0, plf = 0x0, modified = 0x0,
has_volatile_ops = 0x0, pad = 0x0, subcode = 0x74, uid = 0x0, location =
0x6480dd, num_ops = 0x2, bb = 0x7f11dc8865a0, block = 0x7f11dc83a120}, val =
0x7f11db7df1d0}}
gdb>


-- 
   Summary: compiling just takes 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

[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-01 Thread ich at az2000 dot de 


--- 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.org/bugzilla/show_bug.cgi?id=40321

[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-01 Thread ich at az2000 dot de 


--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321

[Bug other/40322] New: make clean fails (/bin/bash: -/: invalid option)

2009-06-01 Thread ich at az2000 dot de 
In revision 148041:

...
make[2]: Verlasse Verzeichnis
'/home/az/Programmierung/gcc-trunk/build/libiberty'
rm -f *.a required-list tmpmulti.out
rm -f libiberty.dvi libiberty.pdf libiberty.info* libiberty.html
make[1]: Verlasse Verzeichnis
'/home/az/Programmierung/gcc-trunk/build/libiberty'
/bin/bash: -/: invalid option
Usage:  /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--protected
--rcfile
--restricted
--verbose
--version
--wordexp
Shell options:
-irsD or -c command or -O shopt_option  (invocation only)
-abefhkmnptuvxBCHP or -o option
/bin/bash: -/: invalid option
Usage:  /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--protected
--rcfile
--restricted
--verbose
--version
--wordexp
Shell options:
-irsD or -c command or -O shopt_option  (invocation only)
-abefhkmnptuvxBCHP or -o option
/bin/bash: -/: invalid option
Usage:  /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--protected
--rcfile
--restricted
--verbose
--version
--wordexp
Shell options:
-irsD or -c command or -O shopt_option  (invocation only)
-abefhkmnptuvxBCHP or -o option
/bin/bash: line 0: test: !=: unary operator expected
make[1]: Betrete Verzeichnis
'/home/az/Programmierung/gcc-trunk/build/x86_64-unknown-linux-gnu/libgcc'
rm -f config.h stamp-h stmp-ldirs libgcc.map
Makefile:147: *** Rekursive Variable »AR_FOR_TARGET« referenziert sich
(schließlich) selbst.  Schluss.
make[1]: Verlasse Verzeichnis
'/home/az/Programmierung/gcc-trunk/build/x86_64-unknown-linux-gnu/libgcc'
make: *** [clean-stage3-target-libgcc] Fehler 2


-- 
   Summary: make clean fails (/bin/bash: -/: invalid option)
   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

[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-01 Thread ich at az2000 dot de 


--- 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 <http://gcc.gnu.org/bugs.html> for instructions.

Btw., I have some similar problem with GCC 4.4.0. It's also eating up all
memory there and dies in the end, for the same source file. It doesn't occur
with GCC 4.3 though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321

[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-01 Thread ich at az2000 dot de 


--- 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://openlierox.svn.sourceforge.net/viewvc/openlierox/src/common/PhysicsLX56_Projectiles.cpp?view=markup

I guess it cannot really be reproduced with a simple example as the problem is
probably the complexitiy here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321

[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-01 Thread ich at az2000 dot de 


--- 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*, const
LX56ProjAttribs&, const CVec&, const CVec&, CWorm*, TimeDiff,
ProjCollisionType)':
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp:129:
internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321

[Bug c++/40321] New: internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-01 Thread ich at az2000 dot de 
This is with GCC trunk, revision 148003:

...
[ 69%] Building CXX object
CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o
[ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/HTTP.o
[ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/Networking.o
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In
function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*, const
LX56ProjAttribs&, const CVec&, const CVec&, CWorm*, TimeDiff,
ProjCollisionType)':
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp:129:
internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o]
Fehler 1
make[2]: *** Warte auf noch nicht beendete Prozesse...


-- 
   Summary: internal compiler error: in compute_antic, at tree-ssa-
pre.c:2501
   Product: gcc
   Version: tree-ssa
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=40321

[Bug rtl-optimization/323] optimized code gives strange floating point results

2009-05-18 Thread ich at az2000 dot de 


--- 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 implementation, it will throw
assertions then).

If not, I guess my bug #40186 is not a duplicate of this bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug c++/40186] floating point comparison is wrong ( !(a < b) && (b > a) is true )

2009-05-18 Thread ich at az2000 dot de 


--- 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 ordering 1"). I also removed
some parts from the test case, it's much shorter now.

This occurs only with -Os now, in all other cases, I don't hit the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186

[Bug c++/40186] floating point comparision works wrong ( !(a < b) && (b > a) is true )

2009-05-18 Thread ich at az2000 dot de 


--- 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/gcc-4.4.0/work/gcc-4.4.0/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --enable-cld --enable-java-awt=gtk
--with-arch=i686 --enable-languages=c,c++,java,objc,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.0'
Thread model: posix
gcc version 4.4.0 (Gentoo 4.4.0) 
COLLECT_GCC_OPTIONS='-Os' '-v' '-ggdb' '-o' 'test_order' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -quiet -v -D_GNU_SOURCE
test_order.cpp -quiet -dumpbase test_order.cpp -mtune=generic -march=i686
-auxbase test_order -ggdb -Os -version -o /tmp/cc2REzjQ.s
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4/backward
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
GNU C++ (Gentoo 4.4.0) version 4.4.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0, GMP version 4.2.4, MPFR version
2.4.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 13a3af7fd37a02ca6104ed29e33fcca6
COLLECT_GCC_OPTIONS='-Os' '-v' '-ggdb' '-o' 'test_order' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o /tmp/cc5XznpU.o /tmp/cc2REzjQ.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-Os' '-v' '-ggdb' '-o' 'test_order' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o test_order
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0
-L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../.. /tmp/cc5XznpU.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../crtn.o
wrong ordering 2! 993.747, 993.747
d = 990.91854039579629898
v1 = 1600861594,1600861595
v2 = 1600861596,1600861593
8 chars: 3c7f1bcaf90d8f40
d = 990.91854039579629898
v1 = 5f6b359a,5f6b359b
v2 = 5f6b359c,5f6b3599
8 chars: 3c7f1bcaf90d8f40


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186

[Bug c++/40186] floating point comparision works wrong ( !(a < b) && (b > a) is true )

2009-05-18 Thread ich at az2000 dot de 


--- 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 {
return a->get() < b->get();
}
};

STLport gives this assertion when inserting Tmp pointers with equal values
(returned by get() function):

/usr/include/stlport/stl/debug/_tree.h(63): STL error : Invalid strict weak
ordering predicate, if pred(a, b) then we should have !pred(b, a)
/usr/include/stlport/stl/debug/_tree.h(63): STL assertion failure:
!_M_non_dbg_cmp(__rhs, __lhs) 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186

[Bug c++/40186] floating point comparision works wrong ( !(a < b) && (b > a) is true )

2009-05-18 Thread ich at az2000 dot de 


--- 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.gnu.org/bugzilla/show_bug.cgi?id=40186

[Bug c++/40186] New: floating point comparision works wrong ( !(a < b) && (b > a) is true )

2009-05-18 Thread ich at az2000 dot de 
When comparing the return value of two functions (which both return double and
do always return the same value), I have the case that (a < b) && (b < a)
(whereby they should be equal) in a real world application.

I tried to reproduce it, though in the test case, I have a slightly different
case, which should be also wrong: !(a < b) && (b > a) is true (whereby it
should be a == b).

Probably both problems are related.

The behaviour pretty much depend on the optimisation. With -O0 and -Os, I am
hitting the problem, but not so with -O1, -O2 and -O3.


-- 
   Summary: floating point comparision works wrong ( !(a < b) && (b
> a) is true )
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: 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

[Bug c++/39462] check assert() at compile time if possible

2009-03-14 Thread ich at az2000 dot de 


--- 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 C++
standard itself.

That is why I thought it would be the best to let the compiler do such a check
if possible (and that pretty much depends on the cleverness of the compiler)
and to just accept the situation that there could be cases where the value
could be known in theory already at compile time but the compiler doesn't catch
that.

static asserts are different again (and I don't think there are of no use).
There is a common intersection between what I want and what static asserts
would offer but this intersection is small and they will not really solve the
issue that it would be still very nice if the compiler could check asserts at
compile time if possible (and in that case, I think that static asserts are
only of little use; but it's of course hard to tell that, also because if not
all compiler supports compile-time checks on asserts, a lot of people will use
static asserts as a semi-alternative).

But I could also just be wrong with these thoughts. I am not really into the
GCC development and even after about 5 years of C++ development, I still see
more and more new and different ways of doing stuff in C++.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462

[Bug c++/39462] check assert() at compile time if possible

2009-03-14 Thread ich at az2000 dot de 


--- 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 4.4.x, of course):
> 
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
> 

Thanks, but static_assert is not an option. It would make things only more
complicated and can not cover a lot of cases.

I also don't really understand why there is something like a static_assert (I
am not sure how much I really would use an assert outside of a function). If a
compiler would be intelligent enough to check asserts at compile time if
possible, to differ between static_assert and assert only makes it more
complicated - mostly for the programmer.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462

[Bug c++/39462] check assert() at compile time if possible

2009-03-14 Thread ich at az2000 dot de 


--- 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 support that attribute. Any
alternative? But I guess you (GCC devs) are not responsible for that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462

[Bug c++/39462] New: check assert() at compile time if possible

2009-03-14 Thread ich at az2000 dot de 
I have a lot of cases where it would be possible (more or less trivial,
depending on the situation/code) to check if an assert() would fail at compile
time. In such cases, I would want that GCC gives a warning (or an error).

I understand that it's not possible to catch all cases but on such cases where
it is easy for GCC to do such a check, I would like that GCC does it and
reports it if it would fail.

For the warning itself: The warning should point out the line where the problem
is really caused (or all lines which could cause that problem). E.g., if I have
an inline function where the assert depends on the function argument, I would
like to get the line-nr where I call that function, not the line-nr of the
assert() itself.

(Just to avoid confusion: I am aware of static asserts but these are different
things and not an option in most cases where I use assert(). Also, I don't want
to make things harder for myself to figure out always when I can use an static
assert and when not. And anyway, there are still a lot of trivial cases where a
static assert is not possible but it would be still trivial for the compiler to
see that it would fail.)


-- 
   Summary: 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 de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462