[9fans] arm compiler bug

[9fans] arm compiler bug

[cinap_lenrek]

0 < -0x80000000 == 1 with 5c.

the problem is caused by this:

		if(a == ACMP && f1->op == OCONST && p->from.offset < 0) {
			p->as = ACMN;
			p->from.offset = -p->from.offset;
		}

because 0x80000000 == -0x80000000

adding the following check to that if expression fixes it:

&& p->from.offset != -p->from.offset

silly python code.

--
cinap

Re: [9fans] arm compiler bug

[Richard Miller]

Good catch.

2's complement integers are generally useful but it's easy to
forget that they don't quite obey normal algebraic rules.
The assumption that
	(a < 0) => (-a > 0)
is the cause of many easily-missed bugs.

Re: [9fans] arm compiler bug

[erik quanstrom]

On Wed Jan  2 04:07:28 EST 2013, cinap_lenrek@gmx.de wrote:
> 0 < -0x80000000 == 1 with 5c.

i get the same results for all compilers:
	0 < -0x80000000......yes
	1 == -0x80000000......no
	0 < -0x80000000 == 1......yes

for [568]c.  the last one is correct since the order of operations are
	(0 < -0x80000000) == 1
which is clearly true.

- erik

#include <u.h>
#include <libc.h>

void
yesno(char *s, int bool)
{
	print("%s...", s);
	if(bool)
		print("yes\n");
	else
		print("no\n");
}
void
main(void)
{
	yesno("0 < -0x80000000...", 0 < -0x80000000);
	yesno("1 == -0x80000000...", 1 == -0x80000000);
	yesno("0 < -0x80000000 == 1...", 0 < -0x80000000 == 1);
	exits("");
}

Re: [9fans] arm compiler bug

[Charles Forsyth]

those are being done at compile time.

On 2 January 2013 15:07, erik quanstrom <quanstro@quanstro.net> wrote:
> i get the same results for all compilers:

Re: [9fans] arm compiler bug

[Charles Forsyth]

and 0x80000000 is thereby unsigned int, which changes the nature of
the comparison.

On 2 January 2013 15:53, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> those are being done at compile time.
>
> On 2 January 2013 15:07, erik quanstrom <quanstro@quanstro.net> wrote:
>> i get the same results for all compilers:

Re: [9fans] arm compiler bug

[Matthew Veety]

Is this related to the bug I found in python on arm?

On Jan 2, 2013, at 4:05, cinap_lenrek@gmx.de wrote:

> 0 < -0x80000000 == 1 with 5c.
>
> the problem is caused by this:
>
>        if(a == ACMP && f1->op == OCONST && p->from.offset < 0) {
>            p->as = ACMN;
>            p->from.offset = -p->from.offset;
>        }
>
> because 0x80000000 == -0x80000000
>
> adding the following check to that if expression fixes it:
>
> && p->from.offset != -p->from.offset
>
> silly python code.
>
> --
> cinap
>

Re: [9fans] arm compiler bug

[erik quanstrom]

On Wed Jan  2 13:32:30 EST 2013, mveety@gmail.com wrote:
> Is this related to the bug I found in python on arm?
>

it would be much more helpful if "the bug" and "python code"
were replaced with specific references.

- erik

Re: [9fans] arm compiler bug

[cinap_lenrek]

yes.

--
cinap

Re: [9fans] arm compiler bug

[cinap_lenrek]

the offending line that triggered it is in Python/getargs.c
in the convertsimple() function (the ival < INT_MIN comparsion):

	case 'i': {/* signed int */
		int *p = va_arg(*p_va, int *);
		long ival;
		if (float_argument_error(arg))
			return converterr("integer<i>", arg, msgbuf, bufsize);
		ival = PyInt_AsLong(arg);
		if (ival == -1 && PyErr_Occurred())
			return converterr("integer<i>", arg, msgbuf, bufsize);
		else if (ival > INT_MAX) {
			PyErr_SetString(PyExc_OverflowError,
				"signed integer is greater than maximum");
			return converterr("integer<i>", arg, msgbuf, bufsize);
		}
		else if (ival < INT_MIN) {
			PyErr_SetString(PyExc_OverflowError,
				"signed integer is less than minimum");
			return converterr("integer<i>", arg, msgbuf, bufsize);
		}
		else
			*p = ival;
		break;
	}

aijus 5e userspace arm emulator was a great help for reproducing
this as i dint have a raspi.

--
cinap