4 ms·

First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it. Second of all, if you are using alloca to allocate memo

by pkaler 15y ago

First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it. Second of all, if you are using alloca to allocate memory on the stack you are asking for trouble. There are so many filthy corner cases to deal with it is not worth it. Figure out another way to do what you are trying to accomplish. This has nothing to do with C or LLVM. This has to do with how a Von Neumann architecture works. http://stackoverflow.com/questions/1018853/why-is-alloca-not-considered-good-practice http://stackoverflow.com/questions/1018853/why-is-alloca-not... Third of all, alloca() is a compiler intrinsic. The compiler may choose to implement it in any way it wants to. http://en.wikipedia.org/wiki/Intrinsic_function http://en.wikipedia.org/wiki/Intrinsic_function Fourth of all, sending a system function with a size_t of zero is undefined behaviour. This is not a bug. Undefined behaviour means that the compiler may do anything. http://en.wikipedia.org/wiki/Undefined_behavior http://en.wikipedia.org/wiki/Undefined_behavior In general, LLVM does the most optimal thing when it hits undefined behaviour because it assumes that the Clang static analyzer will warn the programmer.

deleted 15y ago
[deleted]
FooBarWidget 15y ago
> First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it. This is a compiler we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it? > Figure out another way to do what you are trying to accomplish. This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it.
- jey 15y ago
  > This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it. Why does scanning the stack for pointers need to involve alloca(0)?
  - FooBarWidget 15y ago
    alloca(0) is used as a way to get the end of the stack. There's a bunch of fallback #ifdefs in the code: on platforms that don't have alloca, it detects the end of the stack by calling a forced-non-inline function which returns the address of its sole local variable, but that assumes that the compiler supports the 'noinline' keyword. In any case, all of versions depend on highly platform-specific behavior. See: https://github.com/FooBarWidget/rubyenterpriseedition187-330/blob/mbari/gc.c#L567-570 https://github.com/FooBarWidget/rubyenterpriseedition187-330... https://github.com/FooBarWidget/rubyenterpriseedition187-330/blob/mbari/rubysig.h#L210-269 https://github.com/FooBarWidget/rubyenterpriseedition187-330...
  - Someone 15y ago
    He isn't claiming it is the only way, he is claiming it is the best way he knows of to do what he needs/thinks he needs. I guess he wants the cleanest way to obtain the stack pointer. alloca(1) would work, too, but that runs the risk of producing a stack overflow.
- pilif 15y ago
  you could of course alloca(1) which would also give you the address of the end of the stack plus one byte, but this time using functionality that's inside the specification of alloca()
  - FooBarWidget 15y ago
    That's what I did, I replaced alloca(0) with alloca(sizeof(void *)). Unfortunately llvm-gcc still emitted wrong code in other parts of the program which caused Ruby to crash in strange ways. The post is not so much a complaint about alloca(0), it was just an example of where I thought llvm-gcc is broken.
    - kenferry 15y ago
      llvm-gcc is not going to be globally broken or not broken. Like all software, it has bugs, and the bugs may or may not affect you. An 'example' that is actually a bug in the program is not very convincing of generic broken-ness. Try again if you want to make that case. Do you want __builtin_frame_address, by the way? Still target specific, but explicit.
      - FooBarWidget 15y ago
        It is not just one example. Take a look at http://llvm.org/bugs/show_bug.cgi?id=9891 http://llvm.org/bugs/show_bug.cgi?id=9891 which is marked as WONTFIX. Shipping an unmaintained compiler certainly screams broken to me. __builtin_frame_address looks interesting, I'll take a look.
- pkaler 15y ago
  > This is a compiler we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it? It's not a bug. It's undefined behaviour for a compiler intrinsic. > This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it. Keep two heaps. A long life heap and short life heap that is essentially a stack. http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html http://engineering.twitter.com/2011/03/building-faster-ruby-... Lua uses a struct called lua_State for this. http://www.lua.org/source/5.2/lstate.h.html http://www.lua.org/source/5.2/lstate.h.html

by pkaler 15y ago

deleted 15y ago

[deleted]

FooBarWidget 15y ago

> First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it. This is a compiler we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it? > Figure out another way to do what you are trying to accomplish. This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it.

jey 15y ago
> This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it. Why does scanning the stack for pointers need to involve alloca(0)?
- FooBarWidget 15y ago
  alloca(0) is used as a way to get the end of the stack. There's a bunch of fallback #ifdefs in the code: on platforms that don't have alloca, it detects the end of the stack by calling a forced-non-inline function which returns the address of its sole local variable, but that assumes that the compiler supports the 'noinline' keyword. In any case, all of versions depend on highly platform-specific behavior. See: https://github.com/FooBarWidget/rubyenterpriseedition187-330/blob/mbari/gc.c#L567-570 https://github.com/FooBarWidget/rubyenterpriseedition187-330... https://github.com/FooBarWidget/rubyenterpriseedition187-330/blob/mbari/rubysig.h#L210-269 https://github.com/FooBarWidget/rubyenterpriseedition187-330...
- Someone 15y ago
  He isn't claiming it is the only way, he is claiming it is the best way he knows of to do what he needs/thinks he needs. I guess he wants the cleanest way to obtain the stack pointer. alloca(1) would work, too, but that runs the risk of producing a stack overflow.
pilif 15y ago
you could of course alloca(1) which would also give you the address of the end of the stack plus one byte, but this time using functionality that's inside the specification of alloca()
- FooBarWidget 15y ago
  That's what I did, I replaced alloca(0) with alloca(sizeof(void *)). Unfortunately llvm-gcc still emitted wrong code in other parts of the program which caused Ruby to crash in strange ways. The post is not so much a complaint about alloca(0), it was just an example of where I thought llvm-gcc is broken.
  - kenferry 15y ago
    llvm-gcc is not going to be globally broken or not broken. Like all software, it has bugs, and the bugs may or may not affect you. An 'example' that is actually a bug in the program is not very convincing of generic broken-ness. Try again if you want to make that case. Do you want __builtin_frame_address, by the way? Still target specific, but explicit.
    - FooBarWidget 15y ago
      It is not just one example. Take a look at http://llvm.org/bugs/show_bug.cgi?id=9891 http://llvm.org/bugs/show_bug.cgi?id=9891 which is marked as WONTFIX. Shipping an unmaintained compiler certainly screams broken to me. __builtin_frame_address looks interesting, I'll take a look.
pkaler 15y ago
> This is a compiler we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it? It's not a bug. It's undefined behaviour for a compiler intrinsic. > This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it. Keep two heaps. A long life heap and short life heap that is essentially a stack. http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html http://engineering.twitter.com/2011/03/building-faster-ruby-... Lua uses a struct called lua_State for this. http://www.lua.org/source/5.2/lstate.h.html http://www.lua.org/source/5.2/lstate.h.html