> From: "Joseph S. Myers"
> Date: Tue, 15 May 2012 22:06:03 +0200
> Unless your signal.h does
>
> typedef __SIG_ATOMIC_TYPE__ sig_atomic_t;
I just assumed that was the case, what with other ___xxx_TYPE__
being used throughout the test-suite. My bad.
> this should only affect the testcases gcc
On Tue, 15 May 2012, Hans-Peter Nilsson wrote:
> How do I accomplish setting SIG_ATOMIC_TYPE as above?
GCC only needs to know this type for the purposes of defining limits for
stdint.h. Unless your signal.h does
typedef __SIG_ATOMIC_TYPE__ sig_atomic_t;
this should only affect the testcases g
I'm considering changing SIG_ATOMIC_TYPE for CRIS (*-elf and
*-linux-gnu) to the effect of
#define SIG_ATOMIC_TYPE "int __attribute__((__aligned__(4)))"
but that by itself doesn't work. It causes a SEGV on the 4.7
branch and no doubt also on trunk; the code is the same. From a
gdb session it app
"William J. Schmidt" writes:
> I'm investigating another build failure for Fedora 17 (based on 4.7).
> The failing compile from the build log is as follows:
>
> /bin/sh ./libtool --tag=CC
> --mode=compile
> /builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/xgcc
> -B/builddi
On May 14, 2012, at 5:47 PM, Joern Rennecke wrote:
> Quoting paul_kon...@dell.com:
>
>> I'm running into an ICE due to what looks like wrong register allocation,
>> and I'm trying to figure out where the problem lies. It shows up with
>> today's GCC (trunk). I haven't yet tried to narrow i
On Tue, May 15, 2012 at 9:07 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 14 May 2012, H.J. Lu wrote:
>
>> > As a minor nitpick, I have always used x32 with a lower case x. The
>> > capital X32 looks odd to me.
>> >
>>
>> I used X32 together with LP64. I can use ILP32 instead of X32 when LP64
>> is
Hi,
On Mon, 14 May 2012, H.J. Lu wrote:
> > As a minor nitpick, I have always used x32 with a lower case x. The
> > capital X32 looks odd to me.
> >
>
> I used X32 together with LP64. I can use ILP32 instead of X32 when LP64
> is mentioned at the same time.
I'd prefer that. x32 is a nice s
On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak wrote:
> Hi,
>
>> > > > Why can't we replace function force_expr_to_var_cost directly with
>> function
>> > > > computation_cost in tree-ssa-loop-ivopt.c?
>> > > >
>> > > > Actually I think it is inaccurate for the current recursive algorithm
>> in
>>
Hi,
> > > > Why can't we replace function force_expr_to_var_cost directly with
> function
> > > > computation_cost in tree-ssa-loop-ivopt.c?
> > > >
> > > > Actually I think it is inaccurate for the current recursive algorithm
> in
> > > > force_expr_to_var_cost to estimate expr cost. Instead
> co
Hi,
I am looking at a missed optimization and I think this is something that
could be added to compare-elim, if it's not already done somewhere else.
I have a double word comparison to zero, so in C it's:
int le(long a) { return a <= 0; }
My expand uses the following transformation (in my cur
Hello All,
I need some help regarding implementation of one of the SPE instructions.
I am planning to implement 'evsl' instrinsic.
d = __ev_sl (a,b) : The value in parameter 'a' is shifted left by no.
of bit positions specified in parameter 'b', filling vacated bit
positions with zeros, and the
Hi,
> > Why can't we replace function force_expr_to_var_cost directly with function
> > computation_cost in tree-ssa-loop-ivopt.c?
> >
> > Actually I think it is inaccurate for the current recursive algorithm in
> > force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
> > cou
On Tue, May 15, 2012 at 7:05 AM, Jiangning Liu wrote:
> Hi,
>
> Why can't we replace function force_expr_to_var_cost directly with function
> computation_cost in tree-ssa-loop-ivopt.c?
>
> Actually I think it is inaccurate for the current recursive algorithm in
> force_expr_to_var_cost to estimate
привет зай..!)))
если скучно и хош зазнакомиться ПoлинaБeлoвa_ndivhfj.land.ru имя моё там.
14 matches
Mail list logo
