Amusing C, amusing compiler

[Ark]

A function
int foo(struct T *x)
{
return (x+1)-x;
}
should always return a 1, no matter how T is defined. (And int could be
replaced with ptrdiff_t for you pedants.)

For one thing, it was amusing to watch how my compiler (the famed IAR
EWARM for ARM) jumps through hoops to arrive at this answer.
[ For sizeof(struct T)==6,
00000000 061080E2 ADD R1,R0,#+6
00000004 18209FE5 LDR R2,??foo_0 ;; 0xaaaaaaab
00000008 92318CE0 UMULL R3,R12,R2,R1
0000000C 2CC1A0E1 LSR R12,R12,#+2
00000010 0210A0E1 MOV R1,R2
00000014 912083E0 UMULL R2,R3,R1,R0
00000018 2331A0E1 LSR R3,R3,#+2
0000001C 03004CE0 SUB R0,R12,R3
00000020 0EF0A0E1 MOV PC,LR ;; return
??foo_0:
00000024 ABAAAAAA DC32 0xaaaaaaab
]

How does your compiler fare?
[MSVC gets it right:
mov eax, 1
ret 0
]

Another thing is that, logically, since the actual type doesn't matter,
it could be an incomplete type. However, if I just say
struct T;
before the foo's body, compilation fails. Is it good and/or justified?

- Ark

[jacob navia]

Ark wrote:

A function
int foo(struct T *x)
{
return (x+1)-x;
}
should always return a 1, no matter how T is defined. (And int could be
replaced with ptrdiff_t for you pedants.)

For one thing, it was amusing to watch how my compiler (the famed IAR
EWARM for ARM) jumps through hoops to arrive at this answer.
[ For sizeof(struct T)==6,
00000000 061080E2 ADD R1,R0,#+6
00000004 18209FE5 LDR R2,??foo_0 ;; 0xaaaaaaab
00000008 92318CE0 UMULL R3,R12,R2,R1
0000000C 2CC1A0E1 LSR R12,R12,#+2
00000010 0210A0E1 MOV R1,R2
00000014 912083E0 UMULL R2,R3,R1,R0
00000018 2331A0E1 LSR R3,R3,#+2
0000001C 03004CE0 SUB R0,R12,R3
00000020 0EF0A0E1 MOV PC,LR ;; return
??foo_0:
00000024 ABAAAAAA DC32 0xaaaaaaab
]

How does your compiler fare?
[MSVC gets it right:
mov eax, 1
ret 0
]

Another thing is that, logically, since the actual type doesn't matter,
it could be an incomplete type. However, if I just say
struct T;
before the foo's body, compilation fails. Is it good and/or justified?

- Ark

It is amusing how stupid machines are.
You know? You forget a semi colon and they get all screwed up.

Stupid isn't it?

1) If x is double. If x is a NAN or INFinity,
the result is not one but NAN.
2) For x == INTMAX, x+1-x depends on how the operations are
ordered by the compiler. If it makes (x-1)+x then is 1,
otherwise it overflows and there is undefined behavior.
If INTMAX+1 wraps around to negative the result is not one
either

3) If x is unsigned and equal to UINT_MAX, the the result is -x.

4) There is an infinite number of this kind of optimizations
x+1-x
x+2-x
x+3-x
x+4-x+2*x-x-x
x+5-x + 3*x-x-x-x + 5765*x-5000*x-765*x

For that last expression that should be 5 Microsoft generates:
mov eax, DWORD PTR _x$[ebp]
add eax, 5
sub eax, DWORD PTR _x$[ebp]
mov ecx, DWORD PTR _x$[ebp]
imul ecx, 3
add eax, ecx
sub eax, DWORD PTR _x$[ebp]
sub eax, DWORD PTR _x$[ebp]
sub eax, DWORD PTR _x$[ebp]
mov edx, DWORD PTR _x$[ebp]
imul edx, 5765
add eax, edx
mov ecx, DWORD PTR _x$[ebp]
imul ecx, 5000
sub eax, ecx
mov edx, DWORD PTR _x$[ebp]
imul edx, 765
sub eax, edx

Stupid isn't it???
What is not so clever is to expect from machines that they
understand anything.

A machine doesn't grasp anything, nor it understands anything.
It is we that give the understanding to the machines, and we
have to do it mostly by enumeration. There is no way for
a machine to make an abstraction, I suspect that is because
THEY DO NOT THINK!!!!

Happy for us programmers, they are not there yet, not will be there
for a long while.

Brains THINK, you see? Machines have no brains and can't generalize
vcan't build from experience, can't do anything. All they have is
a fake of "intelligen ce" in the form of complex enumerations
of facts and algorithms that humans program into them.

Brains THINK, machines execute. That's why machines never do any
mistake. Only WE can do mistakes. It is because only WE have
intent. They do not have any.

jacob

[Ian Collins]

jacob navia wrote:

Ark wrote:

>A function
int foo(struct T *x)
{
return (x+1)-x;
}
should always return a 1, no matter how T is defined. (And int could
be replaced with ptrdiff_t for you pedants.)

It is amusing how stupid machines are.
You know? You forget a semi colon and they get all screwed up.

Stupid isn't it?

1) If x is double. If x is a NAN or INFinity,
the result is not one but NAN.

But the example is only doing pointer arithmetic..

--
Ian Collins.

[Ian Collins]

Ark wrote:

>
Another thing is that, logically, since the actual type doesn't matter,
it could be an incomplete type. However, if I just say
struct T;
before the foo's body, compilation fails. Is it good and/or justified?

The expression still has to be parsed before it is optimised, so the
size of T has to be know in order to attempt the pointer arithmetic.

--
Ian Collins.

[pete]

Ark wrote:

>
A function
int foo(struct T *x)
{
return (x+1)-x;
}
should always return a 1, no matter how T is defined.
(And int could be
replaced with ptrdiff_t for you pedants.)

Another thing is that, logically,
since the actual type doesn't matter,
it could be an incomplete type. However, if I just say
struct T;
before the foo's body, compilation fails. Is it good and/or justified?

It is good and/or justified.

If x is a pointer to an incomplete type, then (x + 1) is undefined.

You can't do pointer arithmetic on pointers to incomplete types.

--
pete

[straywithsmile]

In visual studio 2005, if the struct T haven't defined( NOT declared),
the compiler will give an error message, if it has been defined, and
you just give a pointer that is not initialed, e.g
struct T* ptr;
foo(ptr);
the visual studio 2005, also give an run-time error message, said ptr
is not initialed, but on GCC it is right, and will return one; my
compiler DJGPP's assemble tell me that, the foo is optimized by the
compiler, and return 1 directly.

[Walter Roberson]

In article <45***********@ mindspring.com> ,
pete <pf*****@mindsp ring.comwrote:

>You can't do pointer arithmetic on pointers to incomplete types.

Especially if it is void*
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[Keith Thompson]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <45***********@ mindspring.com> ,
pete <pf*****@mindsp ring.comwrote:

>>You can't do pointer arithmetic on pointers to incomplete types.

Especially if it is void*

Why "especially "?

<OT>gcc allows arithmitec on void* as an extension; it doesn't allow
arithmitec on pointers to other incomplete types.</OT>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[websnarf]

Ian Collins wrote:

jacob navia wrote:

Ark wrote:

A function
int foo(struct T *x)
{
return (x+1)-x;
}
should always return a 1, no matter how T is defined. (And int could
be replaced with ptrdiff_t for you pedants.)

It is amusing how stupid machines are.
You know? You forget a semi colon and they get all screwed up.

Stupid isn't it?

1) If x is double. If x is a NAN or INFinity,
the result is not one but NAN.

But the example is only doing pointer arithmetic..

Setting a pointer beyond its boundaries apparently leads to undefined
behavior. This suggests that on at least some theoretical platforms it
might be worth while to not do this simplification. If I am not
mistaken, unsigned integers is the only data type where the standard
guarantees the applicability of that simplification.

Another more pressing point -- what is the use of such a nonsensical
simplification? Who is subtracting two pointers where the base pointer
type is clearly the same, rather than doing the simplification by hand?
Maybe some macro shenanigans, but to be honest I have never found
myself doing that and *not* simplifying it by hand. Personally, I
judge the compiler optimizer for its ability to generate good code
where human intevention is either impossible (jump tables) or difficult
(software-based register renaming.) This is why WATCOM C/C++ is still
in my arsenal of compilers.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Ark]

we******@gmail. com wrote:
<snip>

Setting a pointer beyond its boundaries apparently leads to undefined
behavior.

No. I can address (but not dereference) one beyond
This suggests that on at least some theoretical platforms it

might be worth while to not do this simplification. If I am not
mistaken, unsigned integers is the only data type where the standard
guarantees the applicability of that simplification.

Another more pressing point -- what is the use of such a nonsensical
simplification? Who is subtracting two pointers where the base pointer
type is clearly the same, rather than doing the simplification by hand?
Maybe some macro shenanigans, but to be honest I have never found
myself doing that and *not* simplifying it by hand.

Oh. It's a boiled down example from real life. The origin is indeed from
a macro.
Personally, I

judge the compiler optimizer for its ability to generate good code
where human intevention is either impossible (jump tables) or difficult
(software-based register renaming.)

Also consider how they optimize constant expressions and eliminate
common subexpressions. The latter may not be yours but of the compiler's
own production. Add instruction scheduling, data rearrangement. function
inlining, function prologue/epilogue optimization etc.
- Ark