On 01/16/2013 07:23 PM, David Paterson wrote:
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Mischa Baars
Sent: 16 January 2013 12:53
To: Robert Dewar; gcc@gcc.gnu.org
Subject: Re: not-a-number's
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On
On 01/16/2013 02:53 PM, Richard Biener wrote:
On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars wrote:
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compile
[cc list trimmed]
On Wed, Jan 16, 2013 at 5:44 PM, Wei Mi wrote:
> Hi,
>
> For x86, shift insn will automatically mask the count to 5 bits in 32
> bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
> buf_ << (-end & 63) could be optimized to buf_ << -end. But for trunk
> compi
Hi,
For x86, shift insn will automatically mask the count to 5 bits in 32
bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
buf_ << (-end & 63) could be optimized to buf_ << -end. But for trunk
compiler, some place in the testcase is not optimized.
typedef unsigned long long u
Hi All,
From testing, I found out that the whole width of a MIPS
integer/floating-point register
is saved and restored around a call. This may hurt the performance.
Ex:
fu@debian6:/disk/fu/dev/test$ cat add2.c
void test2(float);
float test(float a, float b)
{
test2(a*b);
return a;
}
fu@
Mike Stump wrote:
>Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
>ftp://gcc.gnu.org/pub/gcc/infrastructure. I'd hoping this was in error
>and the files can be restored. If there is some compelling reason, I
>am interested.
I removed them in favor of the now documented as recomm
Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
ftp://gcc.gnu.org/pub/gcc/infrastructure. I'd hoping this was in error and the
files can be restored. If there is some compelling reason, I am interested.
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Mischa Baars
> Sent: 16 January 2013 12:53
> To: Robert Dewar; gcc@gcc.gnu.org
> Subject: Re: not-a-number's
>
> On 01/16/2013 01:28 PM, Robert Dewar wrote:
> > On 1/16/2013 7:10 AM, Mischa Baar
> >
> >Basic blocks 8/9/10 are identical and live until pass jump2, which is
> >after register allocation.
> >I think these duplicated BBs do not contain additional information and
> >should be better to be removed ASAP, because they might interfere with
> >other passes like ifcvt.
> >
> >So should
On 01/16/2013 02:28 AM, Bin.Cheng wrote:
Hi,
For below simple function from newlib:
static int
is_option (char *argv_element, int only)
{
return ((argv_element == 0)
|| (argv_element[0] == '-') || (only && argv_element[0] == '+'));
}
The expanded rtl is like:
9: NOTE_INSN_BASIC_
On 2013-01-16 14:53:42 +0100, Richard Biener wrote:
> You can enable FP exceptions via fpsetexceptflag and friends (it's
> disabled in the FPU by default) and if you then make sure to compile
> with -fsignalling-nans (that's not the default) you will get the
> desired behavior (program termination
On Wed, Jan 16, 2013 at 4:52 AM, Mischa Baars wrote:
>
> Let me explain again for you. Every 'if' statement in C is translated into a
> 'fucom' or similar instruction, which sets a number of conditions flags in
> the co-processor. Some instructions need you to load these into the eflags
> register
On 2013-01-16 12:47:46 +0100, Mischa Baars wrote:
> On 01/16/2013 12:07 PM, Andrew Haley wrote:
> >Comparisons with NaN don't terminate a statement, and they don't
> >return a NaN. They return a boolean.
> They shouldn't return anything, the comparison should be terminated.
This depends on the co
Richard Biener writes:
> You can enable FP exceptions via fpsetexceptflag and friends (it's disabled
> in the FPU by default) and if you then make sure to compile with
> -fsignalling-nans (that's not the default) you will get the desired behavior
> (program termination via an exception).
That wi
On 1/16/2013 5:00 AM, Andrew Haley wrote:
On 01/16/2013 11:54 AM, Mischa Baars wrote:
Here's what Standard C, F.8.3 Relational operators, says:
x != x → false The statement x != x is true if x is a NaN.
x == x → true The statement x == x is false if x is a
On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars wrote:
> On 01/16/2013 01:28 PM, Robert Dewar wrote:
>>
>> On 1/16/2013 7:10 AM, Mischa Baars wrote:
>>
>>> And as I have said before: if you are satisfied with the answer '2',
>>> then so be it and you keep the compiler the way it is, personally I'm a
On 01/16/2013 11:54 AM, Mischa Baars wrote:
>> Here's what Standard C, F.8.3 Relational operators, says:
>> >
>> > x != x → false The statement x != x is true if x is a NaN.
>> >
>> > x == x → true The statement x == x is false if x is a NaN.
>
> And indeed apparently
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.
The fact that y
On 01/16/2013 01:04 PM, Robert Dewar wrote:
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C specification seems perfectly reasonable to
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first
On 01/16/2013 09:27 AM, Mischa Baars wrote:
> On 01/16/2013 10:06 AM, Andreas Schwab wrote:
>> Mischa Baars writes:
>>
>>> This means that the first 'if' statement should have been terminated when
>> There is no such thing as a "terminated statement". The first condition
>> evaluates to true.
> W
Hi,
For below simple function from newlib:
static int
is_option (char *argv_element, int only)
{
return ((argv_element == 0)
|| (argv_element[0] == '-') || (only && argv_element[0] == '+'));
}
The expanded rtl is like:
9: NOTE_INSN_BASIC_BLOCK 2
2: r113:SI=r0:SI
3: r114:SI=r1
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first condition
evaluates to true.
Whatever you want, although personally I think it is very un
On 16 January 2013 08:59, Mischa Baars wrote:
> On 01/16/2013 08:57 AM, Eric Botcazou wrote:
>>>
>>> Well, I have an Intel manual here that states that any operation on a
>>> QNaN should return a QNaN, which means that also the compare should
>>> return a QNaN when one or both of the arguments is a
Mischa Baars writes:
> This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first condition
evaluates to true.
> Furthermore, the manual states that any operation on a QNaN should return
> a QNaN.
That is only true f
On 01/16/2013 08:57 AM, Eric Botcazou wrote:
Well, I have an Intel manual here that states that any operation on a
QNaN should return a QNaN, which means that also the compare should
return a QNaN when one or both of the arguments is a QNaN.
No, that isn't how comparisons work. The correct resu
On 01/16/2013 09:14 AM, Andreas Schwab wrote:
Mischa Baars writes:
Furthermore, since 'fxam' will return a 'non-comparable' during the first
compare, I suppose the function should then enter the first 'else' and
return a '4'.
Non-comparable means that NaN != NaN is always true.
Andreas.
So
Mischa Baars writes:
> Furthermore, since 'fxam' will return a 'non-comparable' during the first
> compare, I suppose the function should then enter the first 'else' and
> return a '4'.
Non-comparable means that NaN != NaN is always true.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
31 matches
Mail list logo
