Bad .prg generation (code stripped by the optimizer?). about llvm-mos-sdk

[mysterymath]

The only constraints that the C standard places on a compilers output are:

• That all I/O occurs in the proper order, and
• That all volatile accesses occur in the proper order.

Writing to an arbitrary memory location is neither, so the compiler freely removes it. Accordingly, such accesses must be marked volatile to be preserved for their own sake; otherwise the compiler will remove them if they can be proven never to affect IO or volatile accesses.

[mysterymath]

Oh, and since this is C++, infinite loops are undefined behavior. So the compiler can assume that main is unreachable, that is, that the program can never be run ;)

[AGPX]

Well, but at least the return 0 must be emitted, otherwise the program crash. If you try a program like that in any x86 compiler, it doesn't crash. That's for sure a compiler bug.

[mysterymath]

The program could never reach a return 0, why should one be emitted. In fact, it's legal to assume the program can never reach the infinite loop.

[lgblgblgb]

Well, but at least the return 0 must be emitted, otherwise the program crash. If you try a program like that in any x86 compiler, it doesn't crash. That's for sure a compiler bug.

That's called "dead-code elimination" (DCE, for short) optimization. The compiler here does not need to emit "return 0" as that code is "dead", since it cannot be ever reached.

[SupernaviX]

This happens upstream as well, and it's a "known issue". I think it's unlikely that llvm will treat this output as a bug unless/until the language semantics change.

[lgblgblgb]

This happens upstream as well, and it's a "known issue". I think it's unlikely that llvm will treat this output as a bug unless/until the language semantics change.

But if you change line

*((unsigned char *)0xd020) = 7;

to

*((volatile unsigned char *)0xd020) = 7;

the situation is different. I guess, the problem here, that the compiler does not know it's an I/O register, and since the pointed value is never used otherwise in the code, it looks like a no-op: storing a value which will be never used. Thus the volatile can help in such a cases. Well, at least, as far as I can see ...

With that volatile the asm output changes to:

main:                                   # @main
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
    mov     byte ptr [53280], 7
    jmp     .LBB0_1

Surely, the return 0; still hasn't been emitted, but that's normal, since it's dead-code: because of the infinite loop before, that won't be ever reached, so no point to emit it.