On Sun, Sep 9, 2012 at 1:36 PM, Jonathan Wakely wrote:
> Also, why does random.cc contain a non-member function called
> _M_strotoul,
Copy&paste. Used to be in the class. Should be changed now.
On 30 August 2012 17:33, Ulrich Drepper wrote:
> On Thu, Aug 30, 2012 at 11:52 AM, Hans-Peter Nilsson
> wrote:
>>> From: Ulrich Drepper
>>> Date: Tue, 28 Aug 2012 05:57:08 +0200
>>
>> This patch (commit r190787) broke build for non-_GLIBCXX_USE_RANDOM_TR1
>> targets. (See libstdc++-v3/configure
On Thu, Aug 30, 2012 at 11:52 AM, Hans-Peter Nilsson
wrote:
>> From: Ulrich Drepper
>> Date: Tue, 28 Aug 2012 05:57:08 +0200
>
> This patch (commit r190787) broke build for non-_GLIBCXX_USE_RANDOM_TR1
> targets. (See libstdc++-v3/configure.ac and its crossconfig.m4 for a
> list.)
Should be fixe
> From: Ulrich Drepper
> Date: Tue, 28 Aug 2012 05:57:08 +0200
This patch (commit r190787) broke build for non-_GLIBCXX_USE_RANDOM_TR1
targets. (See libstdc++-v3/configure.ac and its crossconfig.m4 for a
list.)
> Index: libstdc++-v3/include/bits/random.h
> ==
On 8/29/12 4:49 PM, Ulrich Drepper wrote:
On Wed, Aug 29, 2012 at 9:48 AM, Paolo Carlini wrote:
Minor nit: are you sure we need to
open a new minor version for the new symbol? Because it seemed to me that
4.7.x was behind by one.
I have 4.7 installed and that version already defines the symbol
On Wed, Aug 29, 2012 at 9:48 AM, Paolo Carlini wrote:
> Minor nit: are you sure we need to
> open a new minor version for the new symbol? Because it seemed to me that
> 4.7.x was behind by one.
I have 4.7 installed and that version already defines the symbols
defined in version 3.4.17. This is a
Hi,
On 8/28/12 1:41 PM, Ulrich Drepper wrote:
On Tue, Aug 28, 2012 at 4:44 AM, Paolo Carlini wrote:
Again, without context, I think this is not the point: random_device is meant
to be just a simple high level wrapper
around things like dev/random, inspired by facilities like dev/random on uni
On Tue, Aug 28, 2012 at 9:14 AM, Andi Kleen wrote:
\> RDRAND is more for cryptographic purposes (key generation etc.), it's not
> supposed to replace pseudo random generators for simulations.
And that's exactly what random_device is for. It's not an random
number engine like the rest. It's supo
Ulrich Drepper writes:
>
> Anyway, another change in the patch is support for a less expensive
> implementation on Ivy Bridge processors. That processor has the
> rdrand instruction. The code uses it if the instruction is usable.
> Has been tested on real hardware. This is not the type of
> arc
On Tue, Aug 28, 2012 at 8:42 AM, Marc Glisse wrote:
> Thank you for your answers. My main concern was whether it was best to
> implement __get_random_word in libstdc++, or __builtin_random in gcc. But it
> looks like your solution of doing it in libstdc++ makes more sense (at least
> for now).
Th
On Tue, 28 Aug 2012, Ulrich Drepper wrote:
On Tue, Aug 28, 2012 at 3:47 AM, Marc Glisse wrote:
I assume they are different enough that they can't all be abstracted
behind a nice common builtin (with default implementation in libgcc
and/or a macro advertising fast implementations of it) :-(
W
On Tue, Aug 28, 2012 at 3:47 AM, Marc Glisse wrote:
> I assume they are different enough that they can't all be abstracted
> behind a nice common builtin (with default implementation in libgcc
> and/or a macro advertising fast implementations of it) :-(
What is different is the way to interact wi
On Tue, Aug 28, 2012 at 4:44 AM, Paolo Carlini wrote:
> Again, without context, I think this is not the point: random_device is meant
> to be just a simple high level wrapper
> around things like dev/random, inspired by facilities like dev/random on
> unix-like OSes. The brutal "fall back" we ha
Hi again,
Marc Glisse ha scritto:
>On Mon, 27 Aug 2012, Ulrich Drepper wrote:
>
>> This is done in the attached patch. It's rather ugly because of the
>> business with the TR1 support. Is this really still needed? Can't
>we
>> remove that? It really makes not much sense for a random_device t
Hi,
Marc Glisse ha scritto:
>On Mon, 27 Aug 2012, Ulrich Drepper wrote:
>
>> This is done in the attached patch. It's rather ugly because of the
>> business with the TR1 support. Is this really still needed? Can't
>we
>> remove that? It really makes not much sense for a random_device to
>be
On Mon, 27 Aug 2012, Ulrich Drepper wrote:
This is done in the attached patch. It's rather ugly because of the
business with the TR1 support. Is this really still needed? Can't we
remove that? It really makes not much sense for a random_device to be
predictable.
Er, I haven't read the cont
16 matches
Mail list logo
