Ping.
On Fri, Aug 01, 2014 at 01:59:42PM +0200, Marek Polacek wrote:
> This is the first patch in a series that strives to improve C++ location info.
>
> The following is more like a base for another improvements, thus it contains
> only one small test. It adds a location_t parameter and a vecto
On 8/3/14 13:50, Chen Gang wrote:
> Excuse me, after tried, I still did not know hot to build the source
> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni".
> What I have done is:
>
> - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java
>make all-target-libj
For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
real world bug, but if another issues occur, it may lead things worse.
It passes "make && make check" under x86_64-apple-darwin13.3.0.
2014-08-09 Chen Gang
On 8/10/14 0:55, Chen Gang wrote:
> On 8/1/14 6:36, Jeff Law wrote:
>>
>> make
>> make check
>
> It is OK (I finish the 2 steps under Mac book).
>
>>
>
> Excuse me, I can not find it with `find ./ | grep "\.sum$"`
>
> [...]
>>
>
> After comparing, should the related ".sum" files be the sam
On Sun, Aug 10, 2014 at 12:27:47AM +0200, Thomas Koenig wrote:
>
> the attached patch fixes the regression by converting the arguments
> to dot_product to the proper types.
>
> Regression-tested on x86_64-unknown-linux-gnu.
>
> OK for all affected branches (trunk, 4.9 and 4.8)?
>
Yes.
--
Ste
Hello world,
the attached patch fixes the regression by converting the arguments
to dot_product to the proper types.
Regression-tested on x86_64-unknown-linux-gnu.
OK for all affected branches (trunk, 4.9 and 4.8)?
Thomas
2014-08-10 Thomas Koenig
PR fortran/61999
*
Hi,
tree-ssa-pre is checking that new dynamic type detection (get_dynamic_type)
catch all cases as old.
Firefox has somewhat obscure case when new code runs into placement new
paranoia earlier.
This patch fixes it and also fixes templates of last two testcases that had
unresolved tests.
Moore, Catherine writes:
> > -Original Message-
> > From: Steve Ellcey [mailto:sell...@mips.com]
> > Sent: Friday, August 08, 2014 3:42 PM
> > To: Moore, Catherine; matthew.fort...@imgtec.com; echri...@gmail.com;
> >
> > 2014-08-08 Steve Ellcey
> >
> > * config/mips/mips.h (ASM_SPEC
This patch fixes the issue that -pedantic -Wno-c90-c99-compat outside
C99 didn't disable the compat warnings (except -Wvariadic-macros that
is enabled by default). It turned out to be quite
hairy. Also I noticed a bug that -Wno-declaration-after-statement
didn't disable the warning in C90 -pedant
On Thu, Aug 07, 2014 at 05:10:43PM +, Joseph S. Myers wrote:
> On Thu, 31 Jul 2014, Marek Polacek wrote:
>
> > A few issues: currently we don't warn (in -std=c90 -pedantic mode)
> > about the usage of __func__ and _Pragma (possible others - va_copy?).
> > I'm hoping this is not that important
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
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
How about the patch below?
Looks good, with two details:
+template
+ class uniform_on_sphere_helper<2, _RealType>
+ {
+ typedef typename uniform_on_sphere_distribution<2, _RealType>::
+ result_type result_type;
+
+ pu
On 08/09/2014 11:33 AM, Marc Glisse wrote:
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
If you are going to specialize for dim 2, I imagine you won't be
computing
normal distributions, you will only generate a point uniformy in a
square
and reject it if it is not in the ball? (interestingly enoug
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 level.
I've als
Excuse me, when I try the testsuite for a new patch which I will send,
I realize I should make sure some related information. So I consult for
them, please help check, thanks.
On 8/1/14 6:36, Jeff Law wrote:
>
> make
> make check
It is OK (I finish the 2 steps under Mac book).
>
Excuse me,
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
If you are going to specialize for dim 2, I imagine you won't be computing
normal distributions, you will only generate a point uniformy in a square
and reject it if it is not in the ball? (interestingly enough this is used
as a subroutine by the impleme
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
> -Original Message-
> From: Steve Ellcey [mailto:sell...@mips.com]
> Sent: Friday, August 08, 2014 3:42 PM
> To: Moore, Catherine; matthew.fort...@imgtec.com; echri...@gmail.com;
>
> 2014-08-08 Steve Ellcey
>
> * config/mips/mips.h (ASM_SPEC): Pass float options to assembler.
> -Original Message-
> From: Steve Ellcey [mailto:sell...@mips.com]
> Subject: [PATCH mips] Do not compile mips16.S in soft-float mode
>
> This libgcc patch is the second of two patches needed to build GCC soft-float
> multilibs when using the latest binutils. It skips assembling any of
Hi, Vlad
Thanks for the explanation.
The patch is okay.
Thanks, David
On Fri, Aug 8, 2014 at 5:26 PM, Vladimir Makarov wrote:
> On 2014-08-08, 2:53 PM, David Edelsohn wrote:
>>
>> Hi, Vlad
>>
>> Why does rs6000_emit_move need special support for SDmode with LRA and
>> not with reload?
>
>
>
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
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 the
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
Tescase was generating warning: assuming signed overflow does not occur
when simplifying conditional to constant [-Wstrict-overflow] due to VRP
missing the value range.
This seems to have been fixed and the PR is now closed. However, as
requ
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.
Richard Henderson writes:
> On 08/03/2014 03:39 AM, Richard Sandiford wrote:
>> +struct rtx_subrtx_bound_info {
>> + unsigned char start;
>> + unsigned char count;
>> +};
>
> Given this structure is only two bytes...
>
>> + /* The bounds to use for iterating over subrtxes. */
>> + const rtx_s
Jeff Law writes:
> On 08/03/14 08:32, Richard Sandiford wrote:
>> The old for_each_inc_dec callback had a for_each_rtx-like return value,
>> with >0 being returned directly, 0 meaning "continue" and <0 meaning
>> "skip subrtxes". But there's no reason to distinguish the latter two
>> cases since
> With just C++ code, Sven can help little. He has no knowledge about graphite
> internals.
I want to ask him about correctness of ISL ASTs generated from
mentioned isl_codegens.
> Do you now have a setup where you can just compile one of the attached files
> with graphite and everything else wit
Hi,
On 08/09/2014 03:33 AM, Jason Merrill wrote:
On 08/08/2014 07:26 PM, Paolo Carlini wrote:
Ok (that seems a latent buglet...). By the way, since I wondered briefly
about SFINAE wrt the existing documentation, does what we do in the
*non* constant case really matter for SFINAE?
Yes; in unev
On 09/08/2014 09:42, Roman Gareev wrote:
Is this segmentation fault at compile time or at run-time? I believe it was
a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
Possibly. Can you split the .cpp files such that yo
> Is this segmentation fault at compile time or at run-time? I believe it was
> a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
> Possibly. Can you split the .cpp files such that you only compile a single
> function with
On Fri, 8 Aug 2014, Ulrich Drepper wrote:
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
vectors with
30 matches
Mail list logo
