https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #14 from Aleksey <rndfax at yandex dot ru> --- (In reply to Segher Boessenkool from comment #13) > (In reply to Aleksey from comment #12) > > But adding these two flags "-fno-reorder-blocks-and-partition > > -fno-reorder-blocks" > > If you say that basic blocks should not be reordered, then they > are not. All behaving perfectly as expected. > > These options will cause exactly the same kind of "problems" > everywhere else as well. > > > Is it possible to fix that? > > Yes, don't use compilers options that degrade performance, if > you want good performance? Performance is not the case here, so don't bother with it. Strict order of labels and using everywhere "jmp reg" instead of "jmp rel + jmp reg" - this is what is important. Documentation (https://gcc.gnu.org/onlinedocs/gccint/Edges.html#Edges) says "During the earlier stages of the compilation process, GCC tries to avoid such dense flow graphs by factoring computed jumps". Then it states that "the computed jumps are un-factored in the later passes of the compiler (in the pass called pass_duplicate_computed_gotos)". It would be helpful if you give the explanation how these options affect "un-factoring".
