[Bug target/35766] a?a+C:0 can be done branchless

2008-12-29 Thread to dot roma dot from dot bugcc at qwertty dot com 


--- Comment #3 from to dot roma dot from dot bugcc at qwertty dot com  
2008-12-29 13:07 ---
Right you are, GCC is smart enough to do this optimization now. Version 4.2.4
(g++ -v below) has just compiled the code without branching. However, the
Debian version of GCC 4.3 failed to do so half a year ago. Something must have
changed since then and backported to 4.2?

Anyway I think the problem has been resolved.

[home PC, Ubuntu, uses sbb]
~/src :) g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

[server, Debian, also uses sbb now]
~/src :) g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)


-- 


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

[Bug c++/35766] New: Should cast pointers and references more efficiently and safely

2008-03-30 Thread to dot roma dot from dot bugcc at qwertty dot com 
In C++, when there’s a class with multiple inheritance and one wants to cast a
pointer to it to the type of a base class which is not the first in the list,
like in this code:

class D: public B1, B2 { . . . };
D* d = get_some_D_possibly_NULL();
B2* b = d;

the pointer must be offset according to the position of the B2 subobject within
D. At the same time, if the pointer is NULL, it must remain NULL (4.10/3).
However, the situation is different when ‘this’ pointers or references are
cast, neither of which can be NULL.

g++ (tested on 3.4, 4.2 and 4.3) does this in a very straightforward way, at
least on x86-32:

cmpl$0, -12(%ebp)
je  .L30
movl-12(%ebp), %eax
addl$12, %eax
movl%eax, -24(%ebp)
jmp .L32
.L30:
movl$0, -24(%ebp)
.L32:

If a reference is cast this way, GCC avoids comparison with 0 and a conditional
jump. At the same time, MSVC is more smart in this respect:

; esi = the pointer
; edi = esi + offset
negesi
sbbesi, esi
andesi, edi

MSVC uses this branchless code for references as well, even though this check
is needless for standard-conforming code. GCC should adopt this approach as
well. It serves two purposes: firstly, it’s a small performance increase and
secondly, some programmers have come to expect NULL references and ‘this’
pointers to be casted successfully, even though it’s UB. For example, as
recently as yesterday someone posted on a forum that he returns NULL from
methods if this==NULL in order to be sure expressions like X* p =
x->foo()->bar() do not crash. They will -- when he uses GCC to compile the
code.

Even though programmers are supposed to know that static_cast(0)->foo() is
UB and null references are as well, most see no reason why that should
fail--but such a reason does exist. Having GCC handle this seems less evil than
crashing unpredictably.

Bottom line: GCC should use more efficient code as MSVC does, which will give a
performance increase (even though unnoticeable in most cases) and, more
importantly, will cause certain code to behave as expected, even though it’s
erroneous.


-- 
   Summary: Should cast pointers and references more efficiently and
safely
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: to dot roma dot from dot bugcc at qwertty dot com


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

[Bug libstdc++/42273] New: atomic_2.h:111: = instead of == in if

2009-12-04 Thread to dot roma dot from dot bugcc at qwertty dot com 
Is it a silly bug or a contrived way of calling __sync_synchronize regardless
of the required memory_order?

--- atomic_2.h  2009-12-04 11:23:26.0 +0200
+++ atomic_2.h  2009-12-04 11:23:35.0 +0200
@@ -108,7 +108,7 @@
{
  // write_mem_barrier();
  _M_i = __v;
- if (__m = memory_order_seq_cst)
+ if (__m == memory_order_seq_cst)
__sync_synchronize();
}
 }


-- 
   Summary: atomic_2.h:111: = instead of == in if
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: to dot roma dot from dot bugcc at qwertty dot com


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