[Bug libstdc++/55047] New: operator() in std::exponential_distribution may call log(0)

2012-10-23 Thread hyounes at google dot com 


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



 Bug #: 55047

   Summary: operator() in std::exponential_distribution may call

log(0)

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hyou...@google.com





The implementation of operator() for std::exponential_distribution is:



  template

result_type

operator()(_UniformRandomNumberGenerator& __urng,

   const param_type& __p)

{

  __detail::_Adaptor<_UniformRandomNumberGenerator, result_type>

__aurng(__urng);

  return -std::log(__aurng()) / __p.lambda();

}



If I understand this correctly, __aurng() returns a value in [0,1).  This

leaves the possibility of computing -log(0)/lambda, which I expect to be Inf. 

On the other hand, -log(1)/lambda will never occur, so the resulting value can

never be 0.  There are two problems with this implementation:



1. The actual range (0,Inf) U Inf is not consistent with the reported range of

[0,Inf) as computed by the min() and max() member functions.



2. -log(U01)/lambda is not the mathematically correct form for the inverse

transformation for the exponential distribution.  -log(1 - U01)/lambda is the

correct form.  This form also gives you the correct range of [0,Inf).  It is an

incorrect optimization to change 1-U01 to just U01 when U01 is [0,1).  It is

only correct if U01 is [0,1] or (0,1), but I do not believe that to be the case

here.



I believe the correct implementation should have the following return

statement:



  return -std::log(result_type(1) - __aurng()) / __p.lambda();



The same problem appears in several other distributions.  For example,

std::weibull_distribution.

[Bug c++/51714] New: internal compiler error: Segmentation fault with -std=c++11

2011-12-30 Thread hyounes at google dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51714

 Bug #: 51714
   Summary: internal compiler error: Segmentation fault with
-std=c++11
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hyou...@google.com


Created attachment 26205
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26205
Output from /usr/local/google/home/hyounes/gcc-svn-inst/bin/g++ -std=c++11 -c
dvlog.cc -save-temps

Command triggering bug:

/usr/local/google/home/hyounes/gcc-svn-inst/bin/g++ -v -std=c++11 -c dvlog.cc
-save-temps

(NOTE, the bug is not triggered if -std=c++11 is left out)

Compiler output:

Using built-in specs.
COLLECT_GCC=/usr/local/google/home/hyounes/gcc-svn-inst/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/google/home/hyounes/gcc-svn-inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/google/home/hyounes/gcc-svn/configure
--prefix=/usr/local/google/home/hyounes/gcc-svn-inst : (reconfigured)
/usr/local/google/home/hyounes/gcc-svn/configure
--prefix=/usr/local/google/home/hyounes/gcc-svn-inst
Thread model: posix
gcc version 4.7.0 20111229 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-c' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

/usr/local/google/home/hyounes/gcc-svn-inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus
-E -quiet -v -D_GNU_SOURCE dvlog.cc -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o dvlog.ii
ignoring nonexistent directory
"/usr/local/google/home/hyounes/gcc-svn-inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/google/home/hyounes/gcc-svn-inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/usr/local/google/home/hyounes/gcc-svn-inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu

/usr/local/google/home/hyounes/gcc-svn-inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward

/usr/local/google/home/hyounes/gcc-svn-inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
 /usr/local/include
 /usr/local/google/home/hyounes/gcc-svn-inst/include

/usr/local/google/home/hyounes/gcc-svn-inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-c' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

/usr/local/google/home/hyounes/gcc-svn-inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus
-fpreprocessed dvlog.ii -quiet -dumpbase dvlog.cc -mtune=generic -march=x86-64
-auxbase dvlog -std=c++11 -version -o dvlog.s
GNU C++ (GCC) version 4.7.0 20111229 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20111229 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.7.0 20111229 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20111229 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 10d42f4b16e2234d346a8379f60d056c
dvlog.cc: In function \u2018void Foo()\u2019:
dvlog.cc:31:34: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/44872] New: [C++0x] Cannot use move constructible class as value for std::map

2010-07-08 Thread hyounes at google dot com 
_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_create_node(_Args&& ...) [with _Args = const std::pair&, _Key = int, _Val = std::pair, _KeyOfValue =
std::_Select1st >, _Compare = std::less, _Alloc =
std::allocator >]’
/usr/include/c++/4.4/bits/stl_tree.h:881:   instantiated from
‘std::_Rb_tree_iterator<_Val> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_insert_(const std::_Rb_tree_node_base*, const
std::_Rb_tree_node_base*, const _Val&) [with _Key = int, _Val = std::pair, _KeyOfValue = std::_Select1st >, _Compare =
std::less, _Alloc = std::allocator >]’
/usr/include/c++/4.4/bits/stl_tree.h:1177:   instantiated from
‘std::pair::iterator, bool> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_insert_unique(const _Val&) [with _Key = int, _Val = std::pair, _KeyOfValue = std::_Select1st >, _Compare =
std::less, _Alloc = std::allocator >]’
/usr/include/c++/4.4/bits/stl_map.h:500:   instantiated from
‘std::pair,
std::_Select1st >, _Compare, typename
_Alloc::rebind >::other>::iterator, bool>
std::map<_Key, _Tp, _Compare, _Alloc>::insert(const std::pair&) [with _Key = int, _Tp = M, _Compare = std::less, _Alloc =
std::allocator >]’
move_map.cc:21:   instantiated from here
move_map.cc:15: error: deleted function ‘M::M(const M&)’
/usr/include/c++/4.4/bits/stl_pair.h:68: error: used here
In file included from /usr/include/c++/4.4/map:61,
 from move_map.cc:4:
/usr/include/c++/4.4/bits/stl_tree.h: In constructor
‘std::_Rb_tree_node<_Val>::_Rb_tree_node(_Args&& ...) [with _Args = const
std::pair&, _Val = std::pair]’:
/usr/include/c++/4.4/bits/stl_tree.h:136: note: synthesized method
‘std::pair::pair(const std::pair&)’ first required
here 
----------------


-- 
   Summary: [C++0x] Cannot use move constructible class as value for
std::map
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hyounes at google dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

2011-06-09 Thread hyounes at google dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436

--- Comment #26 from Haakan Younes  2011-06-09 
13:03:19 UTC ---
(In reply to comment #18)
> (In reply to comment #15)
> > Is it really so hard to code emplace methods? Can we somehow help?
> 
> It's not so hard, but we have limited resources and other priorities.
> 
> Patches welcome, see
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html

I started looking into it about a year ago, before you added insert(&&).  It
seems easy enough to add emplace for map, but what about set?

For map, the first argument to emplace is going to be the key (I believe).  We
can therefore determine if the key is already present in the map before we
construct the value object from the remaining arguments to emplace.

For set, the key is the value, so I don't see a way to avoid constructing the
value object from the arguments to emplace before you know if it should be
inserted.

Am I thinking about it the wrong way?

BTW, I have been happily using insert(&&) for maps for at least 6 months (GCC
built from trunk).  I strongly suspect it is available with GCC 4.6.  You
definitely do not need emplace to store unique_ptr values in a map.