2013/8/8 Ilya Enkovich <enkovich....@gmail.com>: > 2013/8/8 Joseph S. Myers <jos...@codesourcery.com>: >> On Fri, 2 Aug 2013, Ilya Enkovich wrote: >> >>> Hi All, >>> >>> I've updated MPX Wiki page >>> (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler). >>> I added instrumentation description, programming model description, >>> differences with other checkers, implementation details. >> >> Thanks. As noted, there should be a clean separation between what's >> generic and what's architecture-specific - the generic command-line >> options, hooks etc. shouldn't mention "MPX" in their names. > > 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?
Thanks, Ilya > >> >> I'm unclear on the references to *_nobnd and *_nochk functions - are there >> corresponding library (glibc etc.) changes to add additional function >> variants? Are all built-in functions that use pointers modified so that >> GCC will insert the required checks when expanding inline? > The idea was to add new versions of some functions into glibc and > replace normal versions call with special versions call when possible > (e.g. when we know memcpy call does not copy pointers). Currently in > MPX mode expanding is allowed for _nochk_nobnd variant which is equal > to regular call. I cannot be sure new version will be added into > glibc. If not, we would probably create additional library in GCC. > >> >> I'm also unclear on how much --enable-mpx does - in general, it's >> desirable for a single compiler to be able to generate binaries both with >> and without the checks, and so quite possibly to build libgcc, libstdc++ >> etc. as multilibs both with and without MPX, rather than needing to make a >> static decision when GCC is built (so, any configure option should >> preferably be about building *extra* library variants, for example, rather >> than changing the options with which existing variants are built). > Currently (in public mpx branch) --enable-mpx just adds compilation > options to some libraries. > > 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? > > Thanks, > Ilya > >> >> -- >> Joseph S. Myers >> jos...@codesourcery.com