Notices by pinskia (pinskia@hachyderm.io), page 5

@regehr @dave_andersen Well this originally was DOS, so maybe int was 2 bytes (16bits). It has been a long time since I have looked into (non-32bit) DOS programming.

@regehr @dave_andersen Oh wait it is more complex, sizeof(long) != sizeof(float) and clang says the upper bits are undefined then ...

@regehr @dave_andersen Interesting that `-fno-strict-aliasing` does NOT fix it for clang ...

@mbr Note I also requested that clang adds __builtin_assoc_barrier for compatibility with GCC:

https://github.com/llvm/llvm-project/issues/91703

Rewriting add_scope_conflicts for the nth time. This time I am going to start with no cache and then add one to it. And since there is already a mapping from DECL to an pass specific id, that can be easily be used for the bitmap.

@navi Oh yes GTY, GCC's marker for garbage collector (GCC uses a simple mark and sweep one and was added to get some benifit for PCH). But function struct is defined in function.h :).

@navi check_earlier_gotos in c-decl.cc might be useful for that and c_finish_return in c-typeck.cc are places where gotos are checked and return expressions are created.

@navi as long as the side effects of the expression inside is supposed to be done before the defered statements than it will just work. The eh lowering pass (which is handled after the gimpilifier) will do the lowering too. this idea is used by -finstrument-functions option already by wrapping the whole function with a try-finally block which will then call the exit function.

@navi And create the TRY_FINALLY_EXPR in pop_scope (in c-decl.cc).

@navi It might be easier to wrap each scope in a TRY_FINALLY_EXPR and add the defered statements in the finally block.

@fclc @shac What I am trying to say tools are there to sell HW rather than to sell. In fact most are like compilers don't make a difference any more; lets do upstream first instead and then have a much smaller downstream changes for the product. This has been true for all GCC projects in the last 20+ years now.

@fclc @shac So the question comes which market are you looking for. Are you looking for selling software (nobody makes money directy on sw). Or you looking to sell HW (physical final products).
I have worked for HW selling companies my whole career on GCC (and related tools). Each one looked into trying to sell software SDK at one point or another (well Sony sells software via games but not the SDK). Only one was looking into selling now (I think they never did in the end).

@navi Looks like you can set index.initialBlacklist to "testsuite/" which should avoid the testsuite.

https://github.com/MaskRay/ccls/wiki/Customization#indexinitialBlacklist

@navi I wonder if it is trying to look into the testsuite directory. I found that when I do `git grep` I have to use either "*.cc" or "*.h" to avoid searching in the testsuite directory which slows down the search.

@navi Most of us gcc developers build in a seperate object directory (it is recommeneded even to do that). So just wiping out the objdir and rebuilding. I have done `make clean` in the gcc subdirectory just today and it worked. Now I have not done it from the toplevel.

Now GCC build system is not fully autotools either (well most of the target libraries use automake too). But the toplevel is just autoconf with a custom autogen template. GCC directory is just autoconf with a plain makefile.

@mirabilos @navi Looks like @uecker is helping out. Martin knows the C front-end more than I do too.

To all U.S.-based GenX and older #lgbtq folks, prepare to revert to 1995 settings.

Once you've got your wisdom from the bad old days locked in, start sharing it with the young 'uns. This is all new and terrifying to them, and they need our strength.

@chandlerc @regehr
Because GCC can figured out the range of ext_id based on that `index < 0`:
ext_id_10 : [irange] int32_t [-2097151, 2145386496]

That is based on the fact `index<0`, GCC can figure out the range of the undoing cast:
unsigned int [2147483648, +INF]

And then undoing the subtraction you get:
unsigned int [0, 2145386496][4292870145, +INF]

And then undoing the cast from signed to unsigned you get back:
int32_t [-2097151, 2145386496]

@sqx yes that is definitely much harder to warn about. I can't find the paper which is written up to change the standard. The paper is also requesting it be considered a defect against older versions of the standard. Really I wish this was not unspecified but since it is GCC tries to takes advantages of it. Newer C++ makes some things not unspecified but still leaves out some stuff like arguments evaluation.

@mbr @moonchild Yes it was just a documentation thing. I had noticed it originally when I was looking through LLVM bug and came across https://github.com/llvm/llvm-project/issues/91674 .