[PATCH, i386, MPX 1/X] Support of Intel MPX ISA

[Ilya Enkovich]

2013/8/8 Joseph S. Myers <joseph@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
> joseph@codesourcery.com