so I'm trying to work out what the exact flags cmake is setting for gcc for a debug build, and the docs just say "the usual ones", and my searches are saturated with stackoverflow posts that are topically adjacent but unfortunately irrelevant to my problem at hand because I'm trying to work out why my debug builds have horrible numeric issues or something but my release builds don't
and so I get the clever idea of looking at what cmake generated, and oh my god that is a lot of cmake
stepping into this mess with the debugger in a debug build is just too much "zero cost" abstraction to step through because I'm using GLM. So I put in some print statements. First step is transforming the point into the shape function's local space. The shape is at the world origin, so the transform is an identity matrix.
Applying that transform to point (0, 0, 1) somehow returns (0, 0, 0) !!!!!!!!!!
forcing my program to run single threaded doesn't help, so I think I can probably rule out spooky concurrency stuff at least.
IDK maybe there's just too much "zero cost" going on in glm and gcc fucks up the codegen when its not all optimized out? I certainly don't remember seeing MSVC have any problems with it.
@aeva you probably already thought about this but just in case: could there be missing initialization for some struct or variable and the undefined behavior kicks in differently for debug vs release. (Eg. Some field zeroed out vs not)
@agersant as far as I can tell it seems to be constructing fine. The contents of the matrix being multiplied is as expected:
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
@aeva okay. Here's a silly question. If you take that code and you put it in its own program. Apart from all the tangerine stuff. Do you see the same thing.
I'm wondering if something that appears unrelated could be in fact related (worst case scenario stack/heap corruption, which could be accidentally avoided in debug builds by different offsets). Or if there could be a step where data is transferred between stack frames in a way your post doesn't have rlomt k convey.
@mcc glm is fussy about the type mismatch but it does the same if i change it from Tmp.www to vec3(Tmp.w). I don't think it accepts somevec3 / somefloat.
@mcc ok good news I reverted the "what if I just remove the w divide" work around that I added confirmed and then promptly forgot about and it's broken again. gonna try the thing you suggested now
@mcc ok (1/Tmp.w)*Tmp.xyz results in an error message that is long enough that my terminal emulator craps out, but it looks like it's a template arg type deduction/substitution failure.
vec3 Tmp3 = float(1.0 / Tmp.w) * Tmp2;
prevents the error but now instead of occasionally getting some values right it gets all of them wrong and no verts are generated
sorry mismatched names of "tmp" between the example and this
@aeva I think @tess had the right of it, that the language magic involved in making the swizzles work may have been valid C++ but hit a GCC bug. It's possible the problem would have gone away if you'd upgraded your compiler.
I would recommend filing a bug on GLM, although that might be hard if your attempts to make a more minimal use case have not succeeded.
Also in both this and left multiply by rcp, it fixes only some of my models without an obvious pattern :| likely because there are more surprises like this elsewhere
@aeva@mcc yeah I guess I would probably play it safe and avoid using more than one swizzle per line of code? I dunno. Clearly between the library and the compiler there is something bad happening.
@tess@mcc
I just have whatever GCC version is packaged in Debian Testing, which I should hope is current. gcc -v says it's "gcc version 12.2.0 (Debian 12.2.0-14)"
@aeva@mcc honestly that might be the over alignment for simd thing... Also there is a separate variable and property to choose standard version, something like CXX_STANDARD_VERSION
@aeva@mcc I mean, it's also likely they have defined scalar operator/ in some equally absurd sort of way, so honestly I'd just go for it and let the compiler tell you know.
@aeva@mcc but based on 20+ years of dealing with gcc I would say that it is almost certainly some sort of cursed interaction of a macro referencing the same object several times in the middle of a return statement, interacting with local destructors in a way that's not technically incorrect under C++ rules but also extremely unintuitive*
by which I mean "wrong for any sensible definition of wrong created by a human being who has read the C++ spec, but not to the kinds of people who code gcc"
@aeva@mcc the fact that compiler optimization seems to eliminate the issue adds some strength my conviction on this; the ordering (or even execution) of destructors/memory cleanup would depend heavily on what kind of build configuration you were using.
@aeva@mcc I mean frankly, I'm also riding with andi on the "what the hell does dividing two vec3s do?" train; it really feels like you should be dividing by a scalar
@xgranade@aeva@mcc it's clear glm is from the OVERLOAD ALL THE OPERATORS EVEN IF IT MAKES NO SENSE era of C++, but the net result of that is that a lot of them end up just kind of being mystery operations
@tess@xgranade@aeva I mean I think probably it does whatever glsl does, which might not necessarily be a coherent linear algebra operation. But I do wish it were explicitly in in the documentation.
@xgranade@aeva@mcc I created a string library in middle school where unary + was "to upper case" and / was "remove all occurrences of the second operand from the first".
@tess On one hand, that's not much worse than << and >> being relabeled the "stream insertion" and "stream extraction" operators. Of course, I'm also the fool who overloaded & not to mean bitwise AND but tensor products.
@xgranade to be fair, << has the benefit of being lower precedence than all ref/deref and arithmetic operators, and more or less make sense in context.
They were also added way before variadic templates, which is how you do that sort of thing today (though in some ways they are more elegant).
The thing that was gross about my library wasn't so much the operators, but the ring buffer it used for intermediates, so you could overrun it with too complicated of an expression.
@ipd glm does some diabolical template metaprogramming magic to make glsl's semantics work in c++, and for some reason the component-wise divide between two vec3s produces the wrong output with controlled inputs so idk. I haven't dug into how it expands because it's quite verbose for being a debug build.
@ipd I solved it. The way GLM emulates GLSL's swizzle syntax and/or the SIMD stuff does the wrong thing in debug builds. Easily worked around, just annoying to track down.
@aeva The usual culprit here is initiialisation. Debug builds often init to magic numbers like 0xCDCDCDCD and release builds default to "what is your security clearance, citizen?"
@aeva Maybe there are some defines that mess with constructors or smth? I recall quaternions with WXYZ order (or maybe XYZW) being completely broken because it was turned on by a macro and half of the lib supported it and the other half didn't.
@aeva In my case it wasn't a coherence problem, all the code was in just one file. It's that half of the quaternion class implementation didn't support that macro at all :(
@gob I wasn't able to repro in an isolated test case either. I'm not on the latest GLM, so that might be part of it. Some people have commented that I'm probably hitting a GCC bug
I updated GLM since it was a few versions behind anyway, but the debug build behavior remains the same ._.
I was kind of hoping I could use optimization pragmas to selectively opt files or functions into -O3, but I wasn't able to get that working, and iterating on it is too tedious.
Maybe I should give up on GCC and switch to clang :/
@aeva GLM_FORCE_CTOR_INIT maybe? at some point they stopped initializing by default, if you wanted that behaviour, you gotta force it back on. this leads to garbage in memory?
@aeva@mcc by hand, usually. Unless you've got a very smart code editor.
Also there appear to be two different implementations of swizzle based on a #define value; you might try setting the other one in your makefile and see if that resolves your issues.
@tess@mcc I think that ended up being the thing. I got there from a different direction though. Switching to GLM_FORCE_PURE to use constexpr instead of intrinsics also seems to opt into the swizzle function variant. I had to hack up a polyglot glsl file to compile w/ it, but it seems to all work now.
ok! it turns out this was GLM's fault, probably. Experimenting with GLM_FORCE_PURE (replaces intrinsics w/ constexprs) also opted into the swizzle variant where swizzles are member functions. Some hax to update the polyglot glsl parts of the code base later, and now debug builds are doing the right thing.
@aeva ok, the mention of optimization near a computer desk just reminded me, as I've personally had that problem a bunch of times and it's annoying to debug.
Add comment