2013/8/8 Joseph S. Myers <jos...@codesourcery.com>: > On Thu, 8 Aug 2013, Ilya Enkovich wrote: > >> > That is not a big issue to rename generic names. But I'm just still >> > trying to choose proper names. I looked into -fbounds-check but its >> > description already mention C/C++ and its semantics differs from what >> > new instrumentation does. I consider using -fcheck=pointer (currently >> > valid for Fortran) and 'chkp' instead of 'mpx' for generic things. >> > Does it look OK? >> I just realized that usage of option which is already defined for >> other languages may be problematic when this option is passed to >> MULTILIB_OPTIONS. So, probably, new common option -fcheck-pointers? > > Seems reasonable to me. > >> > I made an attempt to use multilibs instead. I tried to add mpx variant >> > to target libraries build but got fail for libgfortran build. Does >> > multilib support partial library rebuild? Actually I do not need >> > libgfortran library (an many other libraries) to be in mpx version. Is >> > it possible to get some libs from one place and some libs from another >> > place? > > I'm not sure why the libgfortran build would have failed ... maybe some > libraries don't in fact do anything with pointers for which the checks > would help, but if so then I'd expect the option simply not to have any > effect on the code generated for those libraries. Multilibs are expected > to be the same for all libraries (but packagers could no doubt optimize > things in their packages, if in fact some libraries are identical when > built both with and without MPX).
The reason for libgfortran build was trivial - -fmpx usage combined with -Werror. This is easily fixed and seems the only problem now is to allow legacy library usage with MPX binary (see http://gcc.gnu.org/ml/gcc/2013-08/msg00114.html). Thanks, Ilya > > -- > Joseph S. Myers > jos...@codesourcery.com
