Hi Erik, while setting -O<x> and -O<y> (with x != y ) in one gcc/g++ command line call works , setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 in one command line call generates a warning , so I think we cannot do that .
Best regards, Matthias > Hello Matthias, > > On 2019-05-08 06:27, Baesken, Matthias wrote: > > Hello, I looked a bit more into it . > > It seems to me , that when -ffp-contract=off is available which is > > the > case with current gcc versions , we want to optimize the 2 special files ( > sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ). > > see the following comments : > > > > jdk/make/hotspot/lib/JvmOverrideFiles.gmk > > > > 47# If the FDLIBM_CFLAGS variable is non-empty we know > > 48# that the fdlibm-fork in hotspot can get optimized > > 49# by using -ffp-contract=off on GCC/Clang platforms. > > ...... > > 58 BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH > $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > > 59 BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH > $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > > 60 > Will this not just resolve itself if you also add -D_FORTIFY_SOURCE=0 to > C_O_FLAG_NONE (and all the other optimization flag variables that have > the value "-O0")? > > But still, setting both -O3 and -O2 in one compile call looks not nice to > > me . > This may not look nice, but is how we have to do things. The last flag > on a compiler command line takes precedence. We rely on this to override > general flags with more specific ones (typically a general flag for the > whole library with specific ones for certain compilation units). This > technique is quite common. > > > > In case of ancient gcc ***without*** -ffp-contract=off , we might > > still > run into issues for these 2 special files when _FORTIFY_SOURCE is set . > > Don't know if this is still relevant . > > In case we want to be on the very safe side , we might need to filter > > out > -D_FORTIFY_SOURCE=2 for these 2 compilation units . > > We don't want to filter out flags. It creates very brittle code that is > likely to break in the future. > > For the patch, I think it would make sense to introduce a variable for > the value -D_FORTIFY_SOURCE=2 (and > -D_FORTIFY_SOURCE=0/-U_FORTIFY_SOURCE) to avoid repeating it. > > /Erik
