The Problem with Friendly C

Re:The Problem with Friendly C by jws on Wednesday December 23, 2015 @09:50PM (#10786817)

Apparently a (uint32_t) shifted by 32 is license to become completely insane.

  int main(int argc, char **argv) {
    uint32_t x = (uint32_t)0x12345678<<(uint32_t)32;
    printf("x<<32 = %x\n", x );
  }

    (Almost all compilers make a warning about the shift size)
  gcc 4.9.2 on Debian x86:      0x0
  gcc 4.9.2 on Debian x86, -O3: 0x0
  clang 3.6 on Debian x86:      0x0
  clang 3.7 on Debian x86:      0x0
  gcc 4.9.2 on Raspbian ARM:    0x0
  tcc 0.9.27 on Raspbian ARM:   0x0                NO WARNING
  tcc 0.9.27 on Debian x86:     Segmentation fault NO WARNING
  clang on El Capitan:          0x5a788cb0
  clang on El Capitan, -O3:     0x54049be8

[ Parent | on HN ]

Re:The Problem with Friendly C by pcwalton on Wednesday December 23, 2015 @11:04PM (#10787064)

> Apparently a (uint32_t) shifted by 32 is license to become completely insane.

That's easy to explain. The optimizer replaced the instruction with an undef [1], which has no live range. So it printed the value of some random register, which happened to be 0, 0x5a788cb0, or 0x54049be8.

[1]: http://llvm.org/docs/LangRef.html#undefined-values

[ Parent | on HN ]

Re:The Problem with Friendly C by to3m on Wednesday December 23, 2015 @09:57PM (#10786843)

I am almost LOLing at the segmentation fault. Where the fuck does a segmentation fault come from? It's shifting a value. Utterly mystifying.

[ Parent | on HN ]

Re:The Problem with Friendly C by userbinator on Wednesday December 23, 2015 @10:22PM (#10786937)

Looking at the generated instructions might give a clue, but I'm just as mystified. Given the size of the program, I doubt there's much of it to inspect anyway.

[ Parent | on HN ]

Re:The Problem with Friendly C by ars on Wednesday December 23, 2015 @10:13PM (#10786898)

Maybe it's a hardware trap and not a regular null reference segmentation fault?

[ Parent | on HN ]

Re:The Problem with Friendly C by pcwalton on Wednesday December 23, 2015 @11:08PM (#10787070)

Well, shl doesn't trap on x86 for out of range values; it just masks the second operand by 0x1f [1]. But it could be some other kind of trap.

Complete guess in the dark: tcc misencoded an instruction causing an illegal instruction trap, maybe in some sort of misguided attempt to optimize the shift to a lea.

[1]: http://x86.renejeschke.de/html/file_module_x86_id_285.html

[ Parent | on HN ]

Re:The Problem with Friendly C by Filligree on Thursday December 24, 2015 @07:23AM (#10787939)

Wouldn't that normally produce SIGILL, not SIGSEGV?

[ Parent | on HN ]