Hi!
On 02/11/13 19:22, Mischa Baars wrote:
On 11/02/2013 08:17 PM, Jonathan Wakely wrote:
On 2 November 2013 18:57, Mischa Baars wrote:
*I understand, however it seems more logical to use the destination
type to **
**determine the type of the first and second operand. *
No. No it does not.
Sat, Nov 02, 2013, Mischa Baars:
> On 11/02/2013 11:19 PM, Jonathan Wakely wrote:
> >On 2 November 2013 22:12, Mischa Baars wrote:
> >
> >And 1.1 is not representable as long double.
> >
> >If you are willing to stop being so arrogant for a few minutes and
> >learn something try running this progra
On 2 November 2013 22:40, Mischa Baars wrote:
>
> There's no converting to any string in your example. You only convert source
> code strings into their corresponding doubles.
Right. I never claimed my example converts to string, I said your example does.
> What I'm trying to point out is that th
On 11/02/2013 11:19 PM, Jonathan Wakely wrote:
On 2 November 2013 22:12, Mischa Baars wrote:
On 11/02/2013 11:06 PM, Jonathan Wakely wrote:
On 2 November 2013 21:52, Mischa Baars wrote:
You are mistaken :)
Indeed some rational numbers can only be represented up to a certain
number
of bits, li
On 2 November 2013 22:12, Mischa Baars wrote:
> On 11/02/2013 11:06 PM, Jonathan Wakely wrote:
>>
>> On 2 November 2013 21:52, Mischa Baars wrote:
>>>
>>> You are mistaken :)
>>>
>>> Indeed some rational numbers can only be represented up to a certain
>>> number
>>> of bits, like 1 / 3. Others can
On 11/02/2013 11:06 PM, Jonathan Wakely wrote:
On 2 November 2013 21:52, Mischa Baars wrote:
You are mistaken :)
Indeed some rational numbers can only be represented up to a certain number
of bits, like 1 / 3. Others can be exactly represented, like 1 / 8.
All real numbers, and therefore all r
On 2 November 2013 21:52, Mischa Baars wrote:
> You are mistaken :)
>
> Indeed some rational numbers can only be represented up to a certain number
> of bits, like 1 / 3. Others can be exactly represented, like 1 / 8.
>
> All real numbers, and therefore all rational numbers, can be represented up
>
On 11/02/2013 09:11 PM, David Given wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/13 19:48, Mischa Baars wrote:
[...]
I have written a couple of new trigonometric functions for use in
the library, and actually I need this to function properly.
The point is that 1.1 simply canno
On Sat, 2 Nov 2013, Jakub Jelinek wrote:
On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote:
OK, thanks. I should have realised this earlier, but we have:
/* Return 1 if EXPR is the integer constant one or the corresponding
complex constant. */
int
integer_onep (const_tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/13 19:48, Mischa Baars wrote:
[...]
> I have written a couple of new trigonometric functions for use in
> the library, and actually I need this to function properly.
The point is that 1.1 simply cannot be represented precisely as a IEEE
float
On 11/02/2013 08:28 PM, Jonathan Wakely wrote:
On 2 November 2013 18:59, Mischa Baars wrote:
On 11/02/2013 07:57 PM, Ian Lance Taylor wrote:
On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars
wrote:
Here's the examples again, now each bug in a separate file. Hope it
helps...
Just compile with 'ma
On 11/02/2013 08:28 PM, Jonathan Wakely wrote:
On 2 November 2013 18:59, Mischa Baars wrote:
On 11/02/2013 07:57 PM, Ian Lance Taylor wrote:
On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars
wrote:
Here's the examples again, now each bug in a separate file. Hope it
helps...
Just compile with 'ma
On 2 November 2013 18:59, Mischa Baars wrote:
> On 11/02/2013 07:57 PM, Ian Lance Taylor wrote:
>>
>> On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars
>> wrote:
>>>
>>> Here's the examples again, now each bug in a separate file. Hope it
>>> helps...
>>>
>>> Just compile with 'make' and run the execut
On 11/02/2013 08:17 PM, Jonathan Wakely wrote:
On 2 November 2013 18:57, Mischa Baars wrote:
I understand, however it seems more logical to use the destination type to
determine the type of the first and second operand.
Are you completely sure this is the desired behaviour?
It's the behaviour
On 2 November 2013 18:57, Mischa Baars wrote:
>
> I understand, however it seems more logical to use the destination type to
> determine the type of the first and second operand.
>
> Are you completely sure this is the desired behaviour?
It's the behaviour required by the C standard, so yes, it is
On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote:
> OK, thanks. I should have realised this earlier, but we have:
>
> /* Return 1 if EXPR is the integer constant one or the corresponding
>complex constant. */
>
> int
> integer_onep (const_tree expr)
> ...
> /* Return 1 if E
On 11/02/2013 07:57 PM, Ian Lance Taylor wrote:
On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote:
Here's the examples again, now each bug in a separate file. Hope it helps...
Just compile with 'make' and run the executable. The source code is
documented, so any questions you might have will
On 11/02/2013 07:52 PM, Ian Lance Taylor wrote:
On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote:
Here's the examples again, now each bug in a separate file. Hope it helps...
Just compile with 'make' and run the executable. The source code is
documented, so any questions you might have will
On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote:
>
> Here's the examples again, now each bug in a separate file. Hope it helps...
>
> Just compile with 'make' and run the executable. The source code is
> documented, so any questions you might have will probably be answered by
> reading the com
On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote:
>
> Here's the examples again, now each bug in a separate file. Hope it helps...
>
> Just compile with 'make' and run the executable. The source code is
> documented, so any questions you might have will probably be answered by
> reading the com
Hi,
Here's the examples again, now each bug in a separate file. Hope it helps...
Just compile with 'make' and run the executable. The source code is
documented, so any questions you might have will probably be answered by
reading the comments.
Regards,
Mischa.
On 11/02/2013 07:10 PM, Dan Ke
Hi,
Here's the examples again, now each bug in a separate file. Hope it helps...
Just compile with 'make' and run the executable. The source code is
documented, so any questions you might have will probably be answered by
reading the comments.
Regards,
Mischa.
On 11/02/2013 07:10 PM, Dan Ke
Please don't crosspost.
It would probably also help if you posted just one bug per message,
and included the commandline, source, and error message
for your smallest test case inline, and used a more descriptive
subject line.
On Sat, Nov 2, 2013 at 10:26 AM, Mischa Baars wrote:
> Hi,
>
> I found
Jakub Jelinek writes:
> On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote:
>> What should integer_onep mean if we have a signed 1-bit bitfield in
>> which the bit is set? Seen as a 1-bit value it's "obviously" 1,
>> but seen as a value extended to infinite precision it's -1.
>>
>
Hi,
I found these two small bugs in the gnu software. Anyone who would like
to try to fix these?
Regards,
Mischa.
2013101700 - gnu software bugs.tar.bz2
Description: application/bzip
On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote:
> What should integer_onep mean if we have a signed 1-bit bitfield in
> which the bit is set? Seen as a 1-bit value it's "obviously" 1,
> but seen as a value extended to infinite precision it's -1.
>
> Current mainline returns fal
What should integer_onep mean if we have a signed 1-bit bitfield in
which the bit is set? Seen as a 1-bit value it's "obviously" 1,
but seen as a value extended to infinite precision it's -1.
Current mainline returns false while wide-int returns true.
This came up in gcc.c-torture/execute/930718
27 matches
Mail list logo
