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
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
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
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 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
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
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 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
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 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 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 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: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 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 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 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
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 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
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 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 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_
> >
> >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
> -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
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.
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
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@
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
[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
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
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
31 matches
Mail list logo
