My very old, highly modified Matz Ruby 1.87 interpreter stopped working
when Debian switched from GCC-9 to GCC-10
The Ruby interpreter binary output from GCC-10 segfaults.
However, if I reduce optimization from -O2 to -O1, the resulting
binaries work fine.
I'd like to find which specific -O2 optimization is causing the failure
when run through gcc-10.
But, when I specified -O1 followed by options explicitly enabling all
the specific optimizations that are supposed to be enabled by -O2,
the resulting binary works fine. Conversely, when I specify -O2,
followed by explicit options to *disable* all those options, the
resulting binary fails.
Does anyone know what -O2 enables aside from the options documented on:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Optimize-Options.html#Optimize-Options
Here's an example of a gcc invocation with -O2 followed by disabling all
the -O2 specific optimizations:
gcc -O2 -g -Wclobbered -fno-stack-protector -fno-align-functions
-fno-align-jumps -fno-align-labels -fno-align-loops -fno-caller-saves
-fno-code-hoisting -fno-crossjumping -fno-cse-follow-jumps
-fno-cse-skip-blocks -fno-delete-null-pointer-checks -fno-devirtualize
-fno-devirtualize-speculatively -fno-expensive-optimizations
-fno-finite-loops -fno-gcse -fno-gcse-lm -fno-hoist-adjacent-loads
-fno-inline-functions -fno-inline-small-functions
-fno-indirect-inlining -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-icf
-fno-ipa-ra -fno-ipa-sra -fno-ipa-vrp
-fno-isolate-erroneous-paths-dereference -fno-lra-remat
-fno-optimize-sibling-calls -fno-optimize-strlen -fno-partial-inlining
-fno-peephole2 -fno-reorder-blocks-and-partition -fno-reorder-functions
-fno-rerun-cse-after-loop -fno-schedule-insns -fno-schedule-insns2
-fno-sched-interblock -fno-sched-spec -fno-store-merging
-fno-strict-aliasing -fno-thread-jumps -fno-tree-builtin-call-dce
-fno-tree-pre -fno-tree-switch-conversion -fno-tree-tail-merge
-fno-tree-vrp -DRUBY_EXPORT -D_GNU_SOURCE=1 -I. -I. -c main.c
Thanks!
--
Brent Roman MBARI
Software Engineer Tel: (831) 775-1808
mailto:brent@xxxxxxxxx http://www.mbari.org/~brent
