3 ms·

These seem very reasonable, the workarounds used are natural, and overall the article is not at all congruous with the conclusion in the (clickbait?) title? Co

These seem very reasonable, the workarounds used are natural, and overall the article is not at all congruous with the conclusion in the (clickbait?) title? Compilers literally made your project possible!

zeratax 4mo ago
> Clang relies on address layout for ordering things I would consider that a bug tbh
- StilesCrisis 4mo ago
  If reproducible builds is a stated goal for Clang? I'm not sure that it is. If so, absolutely a bug.
  - ammar2 4mo ago
    Not sure if it's a stated goal somewhere official but there's been plenty of fixes of the years moving stuff to be deterministic, e.g https://github.com/llvm/llvm-project/commit/cdbde3aacc1260a72d49b9aa7271b4bbec694e83 https://github.com/llvm/llvm-project/commit/cdbde3aacc1260a7... The internal programming guide also says which collections to use for deterministic iteration order: https://llvm.org/docs/ProgrammersManual.html#llvm-adt-setvector-h https://llvm.org/docs/ProgrammersManual.html#llvm-adt-setvec... So definitely a bug here.
- j2kun 4mo ago
  What is kind of annoying is that the author jumps to "I hate compilers" instead of "I will report/help fix this bug upstream."
  - chiyc 4mo ago
    I don't get the sense they hate compilers at all. The writing describes work they seem to love doing. It's just clickbait. And it may not have crossed their mind that the clang behavior is a bug after finding a workaround. I'd also assume compilers do things "no mere mortal can fully comprehend on their own".
    - xena 4mo ago
      This might be the first time in my career I have genuinely found a compiler bug. I've been operating under the axiom of "don't assume it's a compiler bug, assume you're fucking it up somehow". When you get to the point that disabling ASLR makes it consistent intra-host I think I've won the right to at least suspect a compiler bug is at play. I'll go file it upstream after work today.
      - ammar2 4mo ago
        If you feel like increasing your power as per your post, this is a somewhat decent first LLVM issue, take a look at WebAssemblyCFGStackify.cpp :) llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll and friends are existing tests that you can kinda mangle if you want to get a good reproducer. Also take a look at https://discourse.llvm.org/t/reverse-iteration-bots/72224 https://discourse.llvm.org/t/reverse-iteration-bots/72224 Otherwise, happy to put my reproducer/patch on the bug after you file it!
        xena 4mo ago
        I'm gonna have to file the bug without a minimal reproduction case. The issue seems to be those try_table blocks getting nondeterministically reordered at link time (is it using machine pointers for iteration order?). Sadly I'm observing this with a local checkout of binaryen, so it may take a while for you to find the minimal reproduction case.
        xena 4mo ago
        I filed the bug: https://github.com/llvm/llvm-project/issues/204883 https://github.com/llvm/llvm-project/issues/204883

zeratax 4mo ago

> Clang relies on address layout for ordering things I would consider that a bug tbh

StilesCrisis 4mo ago
If reproducible builds is a stated goal for Clang? I'm not sure that it is. If so, absolutely a bug.
- ammar2 4mo ago
  Not sure if it's a stated goal somewhere official but there's been plenty of fixes of the years moving stuff to be deterministic, e.g https://github.com/llvm/llvm-project/commit/cdbde3aacc1260a72d49b9aa7271b4bbec694e83 https://github.com/llvm/llvm-project/commit/cdbde3aacc1260a7... The internal programming guide also says which collections to use for deterministic iteration order: https://llvm.org/docs/ProgrammersManual.html#llvm-adt-setvector-h https://llvm.org/docs/ProgrammersManual.html#llvm-adt-setvec... So definitely a bug here.
j2kun 4mo ago
What is kind of annoying is that the author jumps to "I hate compilers" instead of "I will report/help fix this bug upstream."
- chiyc 4mo ago
  I don't get the sense they hate compilers at all. The writing describes work they seem to love doing. It's just clickbait. And it may not have crossed their mind that the clang behavior is a bug after finding a workaround. I'd also assume compilers do things "no mere mortal can fully comprehend on their own".
  - xena 4mo ago
    This might be the first time in my career I have genuinely found a compiler bug. I've been operating under the axiom of "don't assume it's a compiler bug, assume you're fucking it up somehow". When you get to the point that disabling ASLR makes it consistent intra-host I think I've won the right to at least suspect a compiler bug is at play. I'll go file it upstream after work today.
    - ammar2 4mo ago
      If you feel like increasing your power as per your post, this is a somewhat decent first LLVM issue, take a look at WebAssemblyCFGStackify.cpp :) llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll and friends are existing tests that you can kinda mangle if you want to get a good reproducer. Also take a look at https://discourse.llvm.org/t/reverse-iteration-bots/72224 https://discourse.llvm.org/t/reverse-iteration-bots/72224 Otherwise, happy to put my reproducer/patch on the bug after you file it!
      - xena 4mo ago
        I'm gonna have to file the bug without a minimal reproduction case. The issue seems to be those try_table blocks getting nondeterministically reordered at link time (is it using machine pointers for iteration order?). Sadly I'm observing this with a local checkout of binaryen, so it may take a while for you to find the minimal reproduction case.
        xena 4mo ago
        I filed the bug: https://github.com/llvm/llvm-project/issues/204883 https://github.com/llvm/llvm-project/issues/204883