2015-03-25 11:16 GMT+03:00 Jakub Jelinek <ja...@redhat.com>: > On Wed, Mar 25, 2015 at 11:05:17AM +0300, Ilya Enkovich wrote: >> > The question is what you want to do in the LTO case for the different >> > cases, >> > in particular a TU compiled with -fcheck-pointer-bounds and LTO link >> > without >> > that, or TU compiled without -fcheck-pointer-bounds and LTO link with it. >> > It could be handled as LTO incompatible option, where lto1 would error out >> > if you try to mix -fcheck-pointer-bounds with -fno-check-pointer-bounds >> > code, or e.g. similar to var-tracking, you could consider adjusting the IL >> > upon LTO reading if if some TU has been built with -fcheck-pointer-bounds >> > and the LTO link is -fno-check-pointer-bounds. Dunno what will happen >> > with -fno-check-pointer-bounds TUs LTO linked with -fcheck-pointer-bounds. >> > Or another possibility is to or in -fcheck-pointer-bounds from all TUs. >> >> Mixing instrumented and not instrumented TUs is allowed. All >> instrumentation passes happen before LTO link. The only code >> generation problem if instrumented code is linked with no >> -fcheck-pointer-bounds is disabled chkp_finish_file call which >> generates static constructors. I think I just should set >> flag_check_pointer_bounds if see any instrumented symbol on LTO read. >> It would cause chkp_finish_file call when required and would be >> available as guard for chkp related codes. > > Thus perhaps oring the flag_check_pointer_bounds option from all the TUs is > the desirable behavior for LTO? > I think Richard or Honza would know where would be the best spot to do that. > > Jakub
Is such oring used for some other flags to have an example? Thanks, Ilya
