On Sat, Jun 8, 2024 at 5:03 PM Jonathan Wakely wrote:
> I'm in two minds about backporting this one. It would be good to fix the
> non-conformance problem for the release branches, but it also
> potentially breaks some code that uses ranges::iota without including
> .
I say add the change as soon
On Mon, Jun 3, 2024 at 12:20 PM Florian Weimer wrote:
> Would it make sense to have a special function symbol for this, on which
> the debugger sets the breakpoint? […]
Jon and I discussed more details off-list. Hopefully a more complete
version is coming soon-ish.
Hey Jon,
I think we should give debuggers a chance to announce themselves by
providing an entry point they can call (in the inferior) which sets a
flag. A set flag plus a tracer PID would then be a sufficient
indicator. The remaining code should also stay but some additional
code can be added:
On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote:
> I would appreciate more eyes on this to confirm my conclusions about
> negative int_type values, and the proposed fix, make sense.
The way something like this is handled in glibc's ctype functions is
that both branches are considered. For i
On Mon, Jan 15, 2024 at 9:45 PM Jonathan Wakely wrote:
> I think I'm happy with this now. It has tests for all the new functions,
> and the performance of the charset alias match algorithm is improved by
> reusing part of .
>
> Tested x86_64-linux.
Looks good to me. Good work, Jon.
On Tue, Oct 18, 2022 at 2:56 AM Jason Merrill wrote:
> That makes sense; the file could say something to that effect.
I did that.
> Or the
> CSV file could live in the library directory, or a third directory.
The reasoning is that with the file living in the cp subdir we don't have
the s
Ping. Anyone having problems with this? And the governance of the file?
On Mon, Sep 12, 2022 at 1:51 PM Ulrich Drepper wrote:
> After my prior inquiry into the use of python as a build tool for
> maintainers didn't produce any negative comments and several active and
> eve
Ping! Anyone interested in this. I'm bootstrapping my trunk builds with
this patch without problems.
On Mon, Aug 22, 2022 at 9:09 PM Ulrich Drepper wrote:
> This is the second version of the proposed patch to add more identifiers
> to the known list to give hints about #include
This is the second version of the proposed patch to add more identifiers to
the known list to give hints about #include and version numbers.
Marek looked through the first version and found it acceptable but remarked
that the list is getting long and the sequential search performed by the
current
Any comment on this?
These changes are low-risk so the only real objection I can see is that
people don't deem these messages useful in the first place. I would hope,
though, that some editors/IDEs provide one-click solutions to add the
#includes.
On Fri, Aug 5, 2022 at 9:35 PM Ulrich Dr
In PR65320 Martin raised the point that the pretty printer for the C++
containers is inconsistent across the different types. It's also
inconsistent when it comes to showing different states (empty vs not) of
the same type.
In addition, IMO some more information should be printed like the templat
How about adding a few more names from the std namespace to get appropriate
hints? This patch compiles and the appropriate messages are printed. Is
there a problem with just adding more or even at some point all the symbols
of the standard library?
gcc/ChangeLog:
* cp/name-lookup.cc (ge
On Tue, Aug 10, 2021 at 4:03 AM Xionghu Luo via Gcc-patches
wrote:
> For this case, theorotically I think the master GCC will optimize it to:
>
> invariant;
> for (;;)
> if (unlikely_cond)
> for (;;)
> ;
>
> 'invariant' is moved out of outer loop, but with the patch, it will
On Fri, Jul 30, 2021 at 10:50 AM Jakub Jelinek wrote:
> I think for now it would be better to guard the omp_display_env_*
> in fortran.c with #ifndef LIBGOMP_OFFLOADED_ONLY
>
OK, easy enough. This compiles for me.
diff --git a/libgomp/fortran.c b/libgomp/fortran.c
index 76285d4376b..26ec8ce30
Hi,
On Fri, Jul 30, 2021 at 9:50 AM Tobias Burnus
wrote:
> this patch breaks offloading. The reason is that most code
> in env.c is enclosed in:
>
Indeed, normally I test that configuration but my setup currently has a few
problems.
Although the env vars aren't parsed for those targets it seem
I know OpenMP 5.1 is not really a focus yet but adding this new interface
should not be problematic. I stumbled across this part of the spec and the
functionality is really already mostly there in the form of
OMP_DISPLAY_ENV=verbose etc. This is just a function interface to the same
functionality
On 1/27/21 11:37 AM, Jakub Jelinek wrote:
> Would equality comparison against 0 handle the most common cases.
>
> The user can write it as
> __atomic_sub_fetch (x, y, z) == 0
> or
> __atomic_fetch_sub (x, y, z) - y == 0
> thouch, so the expansion code would need to be able to cope with both.
Plea
This is not yet implemented. Here is a patch.
2020-05-08 Ulrich Drepper
* include/bits/atomic_base.h (atomic_flag): Implement test
memeber function.
* include/std/version: Define __cpp_lib_atomic_flag_test.
* testsuite/29_atomics/atomic_flag/test/explicit.cc: New file
owing patch fixes this.
OK?
2019-11-12 Ulrich Drepper
* tree-dump.c (dequeue_and_dump): Print first tree operand
for VIEW_CONVERT_EXPR.
diff --git a/gcc/tree-dump.c b/gcc/tree-dump.c
index 51c0965861f..83eb29b7e2b 100644
--- a/gcc/tree-dump.c
+++ b/gcc/tree-dump.c
@@ -561,6 +
On Wed, Aug 28, 2019 at 1:47 AM Jose E. Marchesi
wrote:
> function integer_range_info(range_option, init, option)
> {
> if (range_option != "") {
> - start = nth_arg(0, range_option);
> - end = nth_arg(1, range_option);
> + init = init + 0;
> + start = nth_arg(0, ra
On Fri, Aug 9, 2019 at 9:50 AM Alexandre Oliva wrote:
> normal_mv_distribution maintains the variance-covariance matrix param
> in Cholesky-decomposed form. Existing param_type constructors, when
> taking a full or lower-triangle varcov matrix, perform Cholesky
> decomposition to convert it to t
'else if' which
is clearly always the case but the current code makes it unnecessarily
cumbersome to understand.
This is a highly annoying bug in the right circumstance. I have file
names generated based in the source file name and those include in some
situations dash
d the result).
The test suite shows no additional errors and given that only the
functions mentioned in the feature (allocate, empty, new, async) are
changed I think this is a patch which can be applied to the trunk. It
can catch real mistakes.
OK?
gcc/testsuite/ChangeLog
2019-02-20 Ulrich Dr
ional failures.
OK?
libstdc++-v3/
2019-02-14 Ulrich Drepper
PR libstdc++/88738
Warn about unused comparisons of shared_ptr/unique_ptr
* include/bits/c++config [_GLIBCXX_NODISCARD]: Define.
* include/bits/shared_ptr.h: Use it for ope
On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> As we aren't implementing OpenMP 5.0 fully yet and especially because
> we aren't implementing the new nesting ICV semantics, we shouldn't do it now,
> they are valid in OpenMP 4.5.
OK, that applies to omp_[gs]et_nested.
How about the lock symbols? All t
files implementing the
omp_[gs]et_nested functions had to be changed. I just use the pragma to
disable the warning temporarily instead of a more global option like
using -Wno-deprecated-declarations in the Makefile.
What do people think about this?
2019-01-02 Ulrich Drepper
Newly deprecated symbo
On Fri, Nov 2, 2018 at 10:36 AM Prathamesh Kulkarni
wrote:
> So, the patch adds another transform erf(x) > 1 -> 0
> which resolves the regression.
Why don't you match for any constant with absolute value >= 1.0
instead of just 1.0?
Not commenting on the correctness... but
On Mon, Jul 24, 2017 at 1:29 PM, Alexander Monakov wrote:
> + basic_block bb0 = bbs[0], bb1 = bbs[1];
> + if (bb_postorder[bb0->index] < bb_postorder[bb1->index])
> + bbs[0] = bb1, bbs[1] = bb0;
> +}
> + else if (__builtin_expect (n ==
opose the following patch.
[gcc/ChangeLog]
2017-07-21 Ulrich Drepper
* dwarf2out.c (output_file_names): Avoid double testing for
dwarf_version >= 5.
--- gcc/dwarf2out.c 2017-07-21 06:15:26.993826963 +0200
+++ gcc/dwarf2out.c-new 2017-07-21 10:29:03.382742797 +0200
@@
On Tue, Jul 18, 2017 at 7:57 AM, Michael Collison
wrote:
> This is the second version of a patch for Aarc64 to add a vectorized mersenne
> twister to libstdc++. The first version used intrinsics and included
> "arm_neon.h". After feedback from the community this version uses only GCC
> vector e
On Mon, Jul 10, 2017 at 8:43 PM, Thomas Koenig wrote:
> with the bump in the libfortran version that is needed with
> Paul's patch,
Isn't it time to start thinking about ABI compatibility just as for
the other libraries?
On Tue, Jun 6, 2017 at 12:07 PM, James Greenhalgh
wrote:
> We're a good number of years late to do that without causing some pain.
Well, it's pain for those who deserve it. Who thought it to be a
smart idea to pollute the global namespace?
It's a one-time deal.
> So we have a few solutions to
On Tue, Jul 5, 2016 at 6:06 AM, Richard Biener
wrote:
> I don't think all-all is a useful default. "optimized" may be though.
I relied on old documentation installed on one of my system.
Apparently the default changed to optimized-optall. So, no change to
the documentation needed if the general
Anyone?
On Mon, Jun 27, 2016 at 1:31 PM, Ulrich Drepper wrote:
> The manual says about -fop-info:
>
>If OPTIONS is omitted, it defaults to 'all-all', which means
> dump all available optimization info from all the passes.
>
> The current implementation (at at
The manual says about -fop-info:
If OPTIONS is omitted, it defaults to 'all-all', which means
dump all available optimization info from all the passes.
The current implementation (at at least recent gcc 6.1) don't follow
that, though. They just ignore the option in that case.
How about t
DEF_FUNCTION_TYPE_VAR_5
+#undef DEF_FUNCTION_TYPE_VAR_6
#undef DEF_FUNCTION_TYPE_VAR_7
#undef DEF_POINTER_TYPE
BT_LAST
On Wed, Sep 30, 2015 at 9:09 AM, Jakub Jelinek wrote:
> On Wed, Sep 30, 2015 at 09:05:45AM -0400, Ulrich Drepper wrote:
>> After some recent additions to builtin-types.de
After some recent additions to builtin-types.def the jit user of the
definitions hasn't been updated. OK to apply?
2015-09-30 Ulrich Drepper
* jit-builtins.c: Provide definition of DEF_FUNCTION_TYPE_VAR_6.
* jit-builtins.h: Likewise.
jit-builtins.c |5 +
On Mon, Jun 29, 2015 at 5:26 PM, David Malcolm wrote:
> I'm looking at ways to manage libgccjit API/ABI as per this thread:
> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01982.html
> by transitioning to using symbol versioning, so that the linker can tag
> subsets of libgccjit symbols in both li
A trivial patch to fix the URL of my paper referenced in the
documentation. The RH server isn't the canonical address even though it
will automatically redirect to the correct address. At least for now,
who knows.
OK?
gcc/ChangeLog
2015-03-02 Ulrich Drepper
* doc/invoke
On Mon, Jan 19, 2015 at 12:32 PM, Jonathan Wakely wrote:
> I would like to commit these two patches which complete the C++11
> library implementation:
I would definitely be in favor.
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html
Just a nit. Why wouldn't you check the value of the
On Mon, Dec 8, 2014 at 11:36 AM, David Malcolm wrote:
> Thanks. Overall this is good, a few nitpicks inline below:
I've made the changes and checked in the patch.
implementation. The path argument of the new
interface is used differently depending on the name. If the name is of
the form -l* then the -L option is used and a runpath is added.
Otherwise the path is used to locate the file.
Comments?
gcc/ChangeLog:
2014-12-06 Ulrich Drepper
* jit/
function to the C++ interface.
The third change it to the string option handling. Instead of just
using the pointer passed to the function the code now makes a copy
of the string.
OK?
gcc/ChangeLog:
2014-12-06 Ulrich Drepper
* jit/jit-playback.c (convert_to_dso): Use auto_vec instead
On Fri, Dec 5, 2014 at 2:24 PM, David Malcolm wrote:
> What's the use-case here? Sorry if I'm not getting at what this is for.
The use case is that a program wants to use library functions,
something common, not everything is self-contained and linked in
automatically (like libc). Currently you
must have been an oversight.
What do you think?
gcc/ChangeLog:
2014-12-05 Ulrich Drepper
* jit/libgccjit++.h (context): Add missing set_str_option
member function.
* jit/libgccjit.h (gcc_jit_int_option): Add
GCC_JIT_INT_OPTION_LINK_OPTIMIZATION_
+1,8 @@
+2014-12-01 Ulrich Drepper
+
+ * Makefile.in: Use LN_S instead of ln -s and remove file first
+ if it exists.
+
2014-12-01 Segher Boessenkool
* combine.c (try_combine): Use is_parallel_of_n_reg_sets some more.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index
On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse wrote:
> __x = result_type(2.0) * __aurng() - 1.0;
You're right, we of course need the negatives as well.
> Assuming the 2 coordinates are obtained through a rescaling x->2*x-1, if
> __sq is not exactly 0, it must be between 2^-103 and
Marc Glisse writes:
> On Sat, 9 Aug 2014, Ulrich Drepper wrote:
> Yes, you still need the normalization step (divide by the norm).
I guess we can do this.
How about the patch below? Instead of specializing the entire class for
_Dimen==2 I've added a class at the implementation l
On Sat, Aug 9, 2014 at 8:34 AM, Marc Glisse wrote:
> Oh, a comment saying exactly what you just said would be fine with me (or
> even nothing).
We might at some point use a different method than Box-Muller sampling
so I'm OK with the test.
> If you are going to specialize for dim 2, I imagine y
On Sat, Aug 9, 2014 at 3:15 AM, Marc Glisse wrote:
> While there, do we want to also reject infinite norms?
> I would have done: while (__sum < small || __sum > large)
> but testing exactly for 0 and infinity seems good enough.
I guess the squaring can theoretically overflow and produce infinity.
ihs and now the referenced bug is
already fixed. Good. Now also for a fix of the sphere distribution.
Unless someone objects I'll check in the patch below.
2014-08-08 Ulrich Drepper
* include/ext/random.tcc
(uniform_on_sphere_distribution::__generate_impl): Reject
ve
On Wed, Jul 23, 2014 at 6:29 AM, Jonathan Wakely wrote:
> As an aside, we already have divide-by-zero bugs in , it
> would be nice if someone could look at that.
I'll take a look at this soon.
On Wed, Jul 16, 2014 at 11:01 AM, Paolo Carlini
wrote:
> Right. And reset too. I'm going to test and apply the below.
Sorry for not reacting to this, I was away from the machines I could
have done that work on.
On Sun, Jul 13, 2014 at 12:25 PM, Paolo Carlini
wrote:
> I don't think so. It depends on the past of the two different
> uniform_on_sphere: each time each uniform_on_sphere calls _M_n(__urng) the
> state of *its own* _M_n changes, evolves from the initial state.
I indeed should use the normal_dis
On Sun, Jul 13, 2014 at 12:07 PM, Paolo Carlini
wrote:
> Sorry, I still don't get it. When operator() of x and y, two
> uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a
> different state, the numbers produced are in general different.
Correct. But in the case of this distr
On Sun, Jul 13, 2014 at 11:43 AM, Paolo Carlini
wrote:
> and I think: the normal distributions in x and y do have a non-trivial state
> (_M_saved, _M_saved_available) which, at any given moment, is different in x
> and y. Then the trivial inserter of x is called and the trivial extractor of
> y is
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> So I would just serialize _M_n here.
It has fixed parameters. This would mean unnecessary work. When you
try to use the parameter of the sphere distribution the normal
distribution will be reset. So there really is n
On Sun, Jul 13, 2014 at 5:24 AM, Paolo Carlini wrote:
> are these dummy implementations intended?
Yes. There is no state. The only parameter is the dimensionality
which is a template parameter.
On Sat, Jul 12, 2014 at 10:00 PM, Ulrich Drepper wrote:
> The patch is tested against the current tree without causing additional
> problems.
>
> OK?
Ignore the values.cc test case, it's a left-over from copying existing
tests and modifying them for a new distribution. This te
many dimensions. This
distribution by itself is useful but if I get some other code fully
implemented it will also form the basis for yet another, more
sophisticated distribution.
The patch is tested against the current tree without causing additional
problems.
OK?
2014-07-12 Ulrich Dr
On Thu, Jul 10, 2014 at 4:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> The title says it all.
>
> I've been bootstrapping and testing with this on x86_64-linux for a month.
>
> OK?
Looks good to me.
On Sat, Jun 28, 2014 at 6:53 PM, Marc Glisse wrote:
> There is always a risk, but then even with builtins I think there was a
> small risk that an RTL optimization would mess things up. It is indeed
> higher if we expose the operation to the optimizers earlier, but it would be
> a bug if an "optim
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse wrote:
> Ping,
>
> nobody has an opinion on this? Or some explanation why I am mistaken to
> believe that #pragma target makes it safer now?
>
> It would enable a number of optimizations, like constant propagation, FMA
> contraction, etc. It would also
ldn't interfere with any correct
code. Should this also go into 4.9?
2014-03-27 Ulrich Drepper
* config/i386/avx512fintrin.h (__v32hi): Define type.
(__v64qi): Likewise.
(_mm512_set1_epi8): Define.
(_mm512_set1_epi16): Define.
(_mm512_set4_epi3
On Mon, Mar 24, 2014 at 9:09 AM, Jakub Jelinek wrote:
> The following is recognized well:
>
> typedef char v32qi __attribute__((vector_size (32)));
> v32qi foo (char a)
> {
> return (v32qi) { a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a,
> a, a, a, a, a, a, a, a, a, a, a, a, a };
> }
On Mon, Mar 24, 2014 at 2:31 AM, Kirill Yukhin wrote:
> If list of missing intrinsics is big - maybe you could share it? I can
> help you implementing it.
So far only the set1 intrinsics. I'll see whether I can spot more.
> In general, I think _undefined idea is correct and the patch is doing
On Mon, Mar 24, 2014 at 1:50 AM, Kirill Yukhin wrote:
> Your patch is correct IMHO, but maybe it worst to add all missing
> `mm512_set1*' stuff?
>
> According to trunk and [1] we're still missing (beside mentioned by you)
> _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts.
Yes, more are missing
Another set of functions missing are those to set all elements of a
512-bit vector to the same float or double value. I think the patch
below uses the optimal code sequence for that. The patch requires the
previous patch introducing _mm*_undefined_*.
2014-03-19 Ulrich Drepper
On Tue, Mar 18, 2014 at 11:11 AM, Richard Biener
wrote:
> Btw, without this zeroing (where zero is also "undefined") this may
> be an information leak and thus possibly a security issue? That is,
> how is _mm_undefined_pd () specified?
People aren't accidentally using the _mm*_undefined_*() func
On Tue, Mar 18, 2014 at 7:13 AM, Richard Biener
wrote:
> extern __inline __m512
> __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> _mm512_undefined_ps (void)
> {
> __m512 __Y = __Y;
> return __Y;
> }
This provokes no warnings (as you wrote) and it doesn't clobber flags,
On Mon, Mar 17, 2014 at 7:39 AM, Ilya Tocar wrote:
> Do you know of any cases where xor is
> generated (except for destination in gather/scatter)
I don't have any code exhibiting this handy right now. I'll keep an eye out.
> but it also clobbers
> flags. Maybe just define it to setzero for no
On Sat, Mar 8, 2014 at 8:30 PM, Mike Stump wrote:
> Are they any plans to change the default language for C++?
Probably problematic for compatibility reasons. But how about adding
c++1, g++11, and c++14, and g++14 wrappers similar to c99?
I'd like to check in this patch which would improve the performance of
the distribution quite a bit by pulling constant computations into the
constructor. This patch will change the memory layout which can be
done easily only now. It also fixes one small bug in operator== and
in a comment.
OK?
On Sat, Mar 2, 2013 at 3:43 PM, Paolo Carlini wrote:
> Yes. Personally, I'm also eager to see your further performance improvements,
> but I'm afraid will have to wait for 4.9.0.
I checked in the code. The performance improvements need some
discussions. I need to do some more experimentation a
On Sat, Mar 2, 2013 at 5:21 AM, Paolo Carlini wrote:
> Exceptionally, I think we can ho ahead with this one too.
Shall I check in the two patches? I added the work-around for
copysign which is the only function used other than log, cos, acos,
sqrt.
On Fri, Mar 1, 2013 at 5:55 PM, <3dw...@verizon.net> wrote:
> I was looking at a paper: Modeling Data using Directional Distributions by
> Inderjit S. Dhillon and Suvrit Sra that looks
> like it would be very similar to your multi-variate normal distribution.
> These generalize von Mises to high
I have a few more distributions to be added. The triangle
distribution is the result of combining to uniform distributions and
therefore quite frequently used. The von Mises distribution (the
simple, 2D version) would be the first circular distribution.
The patch depends on the __math_constants
How about this patch then? As I said, I have code in need of
constants lined up and Edward likely also wants to take advantage of
them in some of his code.
Index: include/Makefile.am
===
--- include/Makefile.am (revision 196362)
+++
On Thu, Feb 21, 2013 at 12:38 PM, Benjamin De Kosnik wrote:
> Not seeing it.
>
> Say for:
>
> #include
>
> // A class for math constants.
> template
> struct __math_constants
> {
> // Constant @f$ \pi @f$.
> static constexpr _RealType __pie =
> 3.141592653589793238462643
How about the attached file as a start for . I used the
constexpr approach (instead of function calls) and replicated the
constants that are available in in Unix.
What other constants to add?
math
Description: Binary data
On Sun, Oct 21, 2012 at 12:11 PM, Paolo Carlini
wrote:
\>> @@ -70,7 +70,11 @@
>> {
>> timespec tp;
>> // -EINVAL, -EFAULT
>> +#ifdef CLOCK_MONOTONIC_RAW
>> + clock_gettime(CLOCK_MONOTONIC_RAW, &tp);
>> +#else
>> clock_gettime(CLOCK_MONOTONIC, &tp);
>> +#endif
>> re
On Wed, Sep 26, 2012 at 12:14 PM, Marc Glisse wrote:
>> Currently the random number engine interface is
>> inefficient since it returns a single number. What we need is an
>> additional interface to return vectors.
>
>
> Isn't the __generate interface good enough?
__generate is for the distribut
On Wed, Sep 26, 2012 at 7:32 AM, Jakub Jelinek wrote:
> Have you considered also an __AVX__ version handling 4 elements at a time?
> Without __AVX2__ one would need to cast __m256i to __m256d for and/or, as
> AVX1 doesn't have _mm256_and_si256 or _mm256_or_si256, but _mm256_and_pd
> or _mm256_or_p
header with optimizations for . No
changes to existing code needed, this is a straight-forward
specialization. Tested on x86_64-linux. More optimizations follow,
there is still quite a bit of inefficiency in the existing interfaces.
OK to commit?
2012-09-21 Ulrich Drepper
Optimize
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 Sat, Sep 8, 2012 at 7:17 AM, Uros Bizjak wrote:
> There are some other cpuid vendor signatures than AMD and Intel,
How about a patch with this complete list?
d-gcc-cpuid-signature
Description: Binary data
On Sat, Sep 8, 2012 at 7:17 AM, Uros Bizjak wrote:
> There are some other cpuid vendor signatures than AMD and Intel, and
> probably there will be some more.
Sure, if there are still people using those they can easily add those.
> IMO, anybody using __get_cpuid_max
> call should define accepted
The x86 cpuid instruction returns a processor ID and the
__get_cpuid_max function even explicitly makes the %ebx value directly
available. But users of that function have to use a cryptic constant.
How about adding a few macros to make this more transparent?
Index: gcc/config/i386/cpuid.h
=
On Thu, Sep 6, 2012 at 2:40 PM, Jack Howarth wrote:
> Okay for gcc trunk?
One typo:
> * configure.ac: Test for rdrnd support in assembler.
It's rdrand. I wouldn't be pedantic if the opcode wouldn't have
changed from rdrnd to rdrand at some point and using the old name
could be confusin
On Wed, Sep 5, 2012 at 6:08 AM, Paolo Carlini wrote:
> Uli, I'm not sure to understand why that commit of yours changed that
> specific regexp,
Completely unintended, I thought I mentioned this already. The
problem is emacs's whitespace mode which made those changes.
Another distribution missing is beta, related to the gamma
distribution. Instead of the complex formula I've used an iterative
process, similar to the one used for the normal distribution. There
is no real surprise here, there are two scalar parameters. Unless
someone things this distribution fo
On Fri, Aug 31, 2012 at 3:59 AM, Miles Bader wrote:
> Can this replace the current mersenne twister implementation in
> std:: once the endianness issue, etc, have been worked out?
No, it produces different numbers.
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
On Wed, Aug 29, 2012 at 11:43 AM, Paolo Carlini wro
> The substance isn't of course. But normally we don't have __gnu_cxx things
> in the same std header. Can't we have a new ext/random and put it in there?
> If we can separate the new code to it, I think people would not even object
> to the targ
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
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
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, 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
Especially after Carlo's comment from earlier that attention is paid
to not inlining unnecessarily it is surprising that the random_device
code is inlined even though it is not a template class.
How about not doing this and moving the definition into the library?
This is done in the attached patc
1 - 100 of 109 matches
Mail list logo
