Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

Ilya,

Thanks for fixing the reference to BNDmode.

However, the patch causes another problem that breaks bootstrap on
AIX.  All of the builtins are emitted as an enum in debug information
and the CHKP enums now cause an overflow in the debug data on AIX.
AIX continues to use stabstrings debugging and does not permit stabs
continuation lines.

This also is failing while building stage1 GCC -- all currently
deployed GCC compilers will fail when building GCC trunk.  No change
to the debugging information produced by GCC trunk will fix this.

Over half of the enum list now contains CHKP.

the first _CHKP builtin is 1156
END_CHKP_BUILTINS is 2381
END_BUILTINS is 2388

All of the normal builtins now appear to be duplicated with CHKP versions.

This is a huge amount of bloat in the common parts of GCC for a
feature that only is available on Intel.  Can you please disable the
feature that creates duplicate CHKP versions of builtins on non-Intel
architectures or at least on AIX (_AIX macro defined)?

Thanks for your earlier fixes, but can we please adjust the
implementation so that it does not break other platforms?

Thanks, David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/17/14 11:22, David Edelsohn wrote:
> However, the patch causes another problem that breaks bootstrap on
> AIX.  All of the builtins are emitted as an enum in debug information
> and the CHKP enums now cause an overflow in the debug data on AIX.
> AIX continues to use stabstrings debugging and does not permit stabs
> continuation lines.
>
> This also is failing while building stage1 GCC -- all currently
> deployed GCC compilers will fail when building GCC trunk.  No change
> to the debugging information produced by GCC trunk will fix this.
>
> Over half of the enum list now contains CHKP.
>
> the first _CHKP builtin is 1156
> END_CHKP_BUILTINS is 2381
> END_BUILTINS is 2388
>
> All of the normal builtins now appear to be duplicated with CHKP versions.
>
> This is a huge amount of bloat in the common parts of GCC for a
> feature that only is available on Intel.  Can you please disable the
> feature that creates duplicate CHKP versions of builtins on non-Intel
> architectures or at least on AIX (_AIX macro defined)?
Note all the initialization and such for these builtins is done 
on-demand.  The only bloat is in the enum list, which is obviously 
causing AIX problems.

It's unfortunately AIX continues to use stabs rather than an embedded 
dwarf format.  Sigh.


>
> Thanks for your earlier fixes, but can we please adjust the
> implementation so that it does not break other platforms?
FWIW, that implementation was largely done to keep things clean 
throughout the gimple phases and keep the maintenance burden down to 
something reasonable.

Ilya, can we create a tag on the builtins we want to have a _chkp 
duplicate, then build a map from the original builtin enum to the _chkp 
variant so that we don't have to duplicate the entire table, but so that 
we still get the cleaner design of the version that was approved?

jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

On Mon, Nov 17, 2014 at 1:41 PM, Jeff Law <law@redhat.com> wrote:
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX.  All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug data on AIX.
>> AIX continues to use stabstrings debugging and does not permit stabs
>> continuation lines.
>>
>> This also is failing while building stage1 GCC -- all currently
>> deployed GCC compilers will fail when building GCC trunk.  No change
>> to the debugging information produced by GCC trunk will fix this.
>>
>> Over half of the enum list now contains CHKP.
>>
>> the first _CHKP builtin is 1156
>> END_CHKP_BUILTINS is 2381
>> END_BUILTINS is 2388
>>
>> All of the normal builtins now appear to be duplicated with CHKP versions.
>>
>> This is a huge amount of bloat in the common parts of GCC for a
>> feature that only is available on Intel.  Can you please disable the
>> feature that creates duplicate CHKP versions of builtins on non-Intel
>> architectures or at least on AIX (_AIX macro defined)?
>
> Note all the initialization and such for these builtins is done on-demand.
> The only bloat is in the enum list, which is obviously causing AIX problems.
>
> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
> format.  Sigh.

Recent versions of AIX now have support for DWARF.  I don't know if it
has arbitrary length limits like this as well.  Adacore has an
implementation and I hope that they will contribute the patch
eventually.

The other complexity is IBM backported the feature to earlier versions
of AIX, but there is no major or minor AIX version number that
definitely has the support.  It's in service packs.  AIX support for
ELF-like visibility is the same.  This means that there is no easy way
to distribute pre-built binaries of GCC for AIX that end users easily
can know if they have the correct prerequisites.  And also means that
one may not be able to share object files and libraries across all AIX
systems at a particular version number.  Sigh^2.

>> Thanks for your earlier fixes, but can we please adjust the
>> implementation so that it does not break other platforms?
>
> FWIW, that implementation was largely done to keep things clean throughout
> the gimple phases and keep the maintenance burden down to something
> reasonable.
>
> Ilya, can we create a tag on the builtins we want to have a _chkp duplicate,
> then build a map from the original builtin enum to the _chkp variant so that
> we don't have to duplicate the entire table, but so that we still get the
> cleaner design of the version that was approved?

That is a fine solution, but is it really necessary to provide this
feature on all targets, even if they don't support CHKP?  Why not nop
chkp_versioning for non-Intel targets?

Thanks, David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Mike Stump]

On Nov 17, 2014, at 10:55 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> 
>> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
>> format.  Sigh.

> The other complexity is IBM backported the feature to earlier versions
> of AIX, but there is no major or minor AIX version number that
> definitely has the support.  It's in service packs.

At Apple, we faced interesting problems that were similar, and we punted for expediency and insisted that people used the higher minor number (which did have a feature or bug fix).  The idea was that we could, if things went wrong, do a point release with just a critical fix or two, and pretend like the original feature was always present or that a bug was never present.  Not ideal, but capable of solving most hard problems.

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich]

2014-11-17 21:22 GMT+03:00 David Edelsohn <dje.gcc@gmail.com>:
> Ilya,
>
> Thanks for fixing the reference to BNDmode.
>
> However, the patch causes another problem that breaks bootstrap on
> AIX.  All of the builtins are emitted as an enum in debug information
> and the CHKP enums now cause an overflow in the debug data on AIX.
> AIX continues to use stabstrings debugging and does not permit stabs
> continuation lines.
>
> This also is failing while building stage1 GCC -- all currently
> deployed GCC compilers will fail when building GCC trunk.  No change
> to the debugging information produced by GCC trunk will fix this.
>
> Over half of the enum list now contains CHKP.
>
> the first _CHKP builtin is 1156
> END_CHKP_BUILTINS is 2381
> END_BUILTINS is 2388
>
> All of the normal builtins now appear to be duplicated with CHKP versions.
>
> This is a huge amount of bloat in the common parts of GCC for a
> feature that only is available on Intel.  Can you please disable the
> feature that creates duplicate CHKP versions of builtins on non-Intel
> architectures or at least on AIX (_AIX macro defined)?
>
> Thanks for your earlier fixes, but can we please adjust the
> implementation so that it does not break other platforms?
>
> Thanks, David

Hello David,

How comes you emit debug info for functions that do not exist and thus
are never used?  Is problem caused by builtins going after
END_CHKP_BUILTINS? Or some info generated for all builtins ignoring
its existence?

Thanks,
Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/17/14 11:55, David Edelsohn wrote:
>
> Recent versions of AIX now have support for DWARF.  I don't know if it
> has arbitrary length limits like this as well.  Adacore has an
> implementation and I hope that they will contribute the patch
> eventually.
Ah.  Good.  Though we probably shouldn't depend on having these bits in 
place.

>
> The other complexity is IBM backported the feature to earlier versions
> of AIX, but there is no major or minor AIX version number that
> definitely has the support.  It's in service packs.  AIX support for
> ELF-like visibility is the same.  This means that there is no easy way
> to distribute pre-built binaries of GCC for AIX that end users easily
> can know if they have the correct prerequisites.  And also means that
> one may not be able to share object files and libraries across all AIX
> systems at a particular version number.  Sigh^2.
Yow :(

>>
>> Ilya, can we create a tag on the builtins we want to have a _chkp duplicate,
>> then build a map from the original builtin enum to the _chkp variant so that
>> we don't have to duplicate the entire table, but so that we still get the
>> cleaner design of the version that was approved?
>
> That is a fine solution, but is it really necessary to provide this
> feature on all targets, even if they don't support CHKP?  Why not nop
> chkp_versioning for non-Intel targets?
Well, the idea is the infrastructure could be used both for a pure 
software implementation as well as a hardware assisted implementation 
and that the hardware assist wasn't tied directly to the MPX implementation.

So as a result we have a ton of stuff that many targets won't 
necessarily use unless someone was to implement the pure software approach.

So while most of the bits are a NOP in terms of how GCC works on targets 
without MPX or a software implementation, we still have the 
infrastructure in place and its that infrastructure that's causing AIX 
to choke.

Jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich]

2014-11-17 21:41 GMT+03:00 Jeff Law <law@redhat.com>:
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX.  All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug data on AIX.
>> AIX continues to use stabstrings debugging and does not permit stabs
>> continuation lines.
>>
>> This also is failing while building stage1 GCC -- all currently
>> deployed GCC compilers will fail when building GCC trunk.  No change
>> to the debugging information produced by GCC trunk will fix this.
>>
>> Over half of the enum list now contains CHKP.
>>
>> the first _CHKP builtin is 1156
>> END_CHKP_BUILTINS is 2381
>> END_BUILTINS is 2388
>>
>> All of the normal builtins now appear to be duplicated with CHKP versions.
>>
>> This is a huge amount of bloat in the common parts of GCC for a
>> feature that only is available on Intel.  Can you please disable the
>> feature that creates duplicate CHKP versions of builtins on non-Intel
>> architectures or at least on AIX (_AIX macro defined)?
>
> Note all the initialization and such for these builtins is done on-demand.
> The only bloat is in the enum list, which is obviously causing AIX problems.
>
> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
> format.  Sigh.
>
>
>>
>> Thanks for your earlier fixes, but can we please adjust the
>> implementation so that it does not break other platforms?
>
> FWIW, that implementation was largely done to keep things clean throughout
> the gimple phases and keep the maintenance burden down to something
> reasonable.
>
> Ilya, can we create a tag on the builtins we want to have a _chkp duplicate,
> then build a map from the original builtin enum to the _chkp variant so that
> we don't have to duplicate the entire table, but so that we still get the
> cleaner design of the version that was approved?
>
> jeff

Taking into account current number of builtins actually instrumented,
it can be done even manually :)  I like current approach because it
allows us to switch to 'instrument everything' mode easily.  Selective
enum codes generation would mean we can never mark all of them as
instrumentable.

I don't fully understand how this problem appears.  Is it fully AIX
specific and doesn't affect any other target?  May we put all _CHKP
codes to the end of enum and ignore them by AIX? Limiting number of
codes in enum due to restrictions of specific debug info format seems
weird.  If something cannot be encoded for debug info then it should
be ignored.  I really hoped that creation of functions by demand would
allow to avoid such kind of problems :(

I'll try to make a patch reducing amound of builtin codes to a
required minimum in case it appears to be the best option we have.

Thanks,
Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Joseph Myers]

On Mon, 17 Nov 2014, Ilya Enkovich wrote:

> I don't fully understand how this problem appears.  Is it fully AIX
> specific and doesn't affect any other target?  May we put all _CHKP
> codes to the end of enum and ignore them by AIX? Limiting number of

It sounds to me like this is actually an AIX *host* issue (and a cross 
compiler for AIX host, x86 target should clearly support MPX just like any 
compiler from any host to that x86 target).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

On Mon, Nov 17, 2014 at 3:43 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2014-11-17 21:41 GMT+03:00 Jeff Law <law@redhat.com>:
>> On 11/17/14 11:22, David Edelsohn wrote:
>>>
>>> However, the patch causes another problem that breaks bootstrap on
>>> AIX.  All of the builtins are emitted as an enum in debug information
>>> and the CHKP enums now cause an overflow in the debug data on AIX.
>>> AIX continues to use stabstrings debugging and does not permit stabs
>>> continuation lines.
>>>
>>> This also is failing while building stage1 GCC -- all currently
>>> deployed GCC compilers will fail when building GCC trunk.  No change
>>> to the debugging information produced by GCC trunk will fix this.
>>>
>>> Over half of the enum list now contains CHKP.
>>>
>>> the first _CHKP builtin is 1156
>>> END_CHKP_BUILTINS is 2381
>>> END_BUILTINS is 2388
>>>
>>> All of the normal builtins now appear to be duplicated with CHKP versions.
>>>
>>> This is a huge amount of bloat in the common parts of GCC for a
>>> feature that only is available on Intel.  Can you please disable the
>>> feature that creates duplicate CHKP versions of builtins on non-Intel
>>> architectures or at least on AIX (_AIX macro defined)?
>>
>> Note all the initialization and such for these builtins is done on-demand.
>> The only bloat is in the enum list, which is obviously causing AIX problems.
>>
>> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
>> format.  Sigh.
>>
>>
>>>
>>> Thanks for your earlier fixes, but can we please adjust the
>>> implementation so that it does not break other platforms?
>>
>> FWIW, that implementation was largely done to keep things clean throughout
>> the gimple phases and keep the maintenance burden down to something
>> reasonable.
>>
>> Ilya, can we create a tag on the builtins we want to have a _chkp duplicate,
>> then build a map from the original builtin enum to the _chkp variant so that
>> we don't have to duplicate the entire table, but so that we still get the
>> cleaner design of the version that was approved?
>>
>> jeff
>
> Taking into account current number of builtins actually instrumented,
> it can be done even manually :)  I like current approach because it
> allows us to switch to 'instrument everything' mode easily.  Selective
> enum codes generation would mean we can never mark all of them as
> instrumentable.
>
> I don't fully understand how this problem appears.  Is it fully AIX
> specific and doesn't affect any other target?  May we put all _CHKP
> codes to the end of enum and ignore them by AIX? Limiting number of
> codes in enum due to restrictions of specific debug info format seems
> weird.  If something cannot be encoded for debug info then it should
> be ignored.  I really hoped that creation of functions by demand would
> allow to avoid such kind of problems :(
>
> I'll try to make a patch reducing amound of builtin codes to a
> required minimum in case it appears to be the best option we have.

I am not a stabstring expert, but the output that I am seeing in
almost every assembler file and the output that is overflowing the
file is:

.stabx  "built_in_function:t1527=eBUILT_IN_NONE:0,BUILT_IN_ACOS:1,BUILT_IN_ACOSF:2,BUILT_IN_ACOSH:3,BUILT_IN_ACOSHF:4,BUILT_IN_ACOSHL:5,BUILT_IN_ACOSL:6,BUILT_IN_ALIGNED_ALLOC:7,BUILT_IN_ASIN:8,BUILT_IN_ASINF:9,BUILT_IN_ASINH:10,BUILT_IN_ASINHF:11,BUILT_IN_ASINHL:12,BUILT_IN_ASINL:13,BUILT_IN_ATAN:14,BUILT_IN_ATAN2:15,BUILT_IN_ATAN2F:16,BUILT_IN_ATAN2L:17,BUILT_IN_ATANF:18,BUILT_IN_ATANH:19,BUILT_IN_ATANHF:20,BUILT_IN_ATANHL:21,BUILT_IN_ATANL:22,BUILT_IN_CBRT:23,BUILT_IN_CBRTF:24,BUILT_IN_CBRTL:25,BUILT_IN_CEIL:26,BUILT_IN_CEILF:27,BUILT_IN_CEILL:28,BUILT_IN_COPYSIGN:29,BUILT_IN_COPYSIGNF:30,BUILT_IN_COPYSIGNL:31,BUILT_IN_COS:32,BUILT_IN_COSF:33,BUILT_IN_COSH:34,BUILT_IN_COSHF:35,BUILT_IN_COSHL:36,BUILT_IN_COSL:37,BUILT_IN_DREM:38,BUILT_IN_DREMF:39,BUILT_IN_DREML:40,BUILT_IN_ERF:41,BUILT_IN_ERFC:42,BUILT_IN_ERFCF:43,BUILT_IN_ERFCL:44,BUILT_IN_ERFF:45,BUILT_IN_ERFL:46,BUILT_IN_EXP:47,BUILT_IN_EXP10:48,BUILT_IN_EXP10F:49,BUILT_IN_EXP10L:50,BUILT_IN_EXP2:51,BUILT_IN_EXP2F:52,BUILT_IN_EXP2L:53,BUILT_IN_EXPF:54,BUILT_IN_EXPL:55,BUILT_IN_EXPM1:56,BUILT_IN_EXPM1F:57,BUILT_IN_EXPM1L:58,BUILT_IN_FABS:59,BUILT_IN_FABSF:60,BUILT_IN_FABSL:61,BUILT_IN_FABSD32:62,BUILT_IN_FABSD64:63,
...
BUILT_IN_CHKP_INTERSECT:1156,BUILT_IN_CHKP_SIZEOF:1157,BUILT_IN_CHKP_NARROW:1158,B
UILT_IN_CHKP_BNDCL:1159,BUILT_IN_CHKP_BNDCU:1160,BUILT_IN_CHKP_BNDSTX:1161,BUILT
_IN_CHKP_BNDLDX:1162,BUILT_IN_CHKP_BNDRET:1163,BUILT_IN_CHKP_BNDMK:1164,BUILT_IN
_CHKP_EXTRACT_LOWER:1165,BUILT_IN_CHKP_EXTRACT_UPPER:1166,BUILT_IN_CHKP_SET_PTR_
BOUNDS:1167,BUILT_IN_CHKP_INIT_PTR_BOUNDS:1168,BUILT_IN_CHKP_NULL_PTR_BOUNDS:116
9,BUILT_IN_CHKP_COPY_PTR_BOUNDS:1170,BUILT_IN_CHKP_NARROW_PTR_BOUNDS:1171,BUILT_
IN_CHKP_STORE_PTR_BOUNDS:1172,BUILT_IN_CHKP_CHECK_PTR_LBOUNDS:1173,BUILT_IN_CHKP
_CHECK_PTR_UBOUNDS:1174,BUILT_IN_CHKP_CHECK_PTR_BOUNDS:1175,BUILT_IN_CHKP_GET_PT
R_LBOUND:1176,BUILT_IN_CHKP_GET_PTR_UBOUND:1177,BUILT_IN_CHKP_MEMCPY_NOBND:1178,
BUILT_IN_CHKP_MEMCPY_NOCHK:1179,BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK:1180,BUILT_IN_C
HKP_MEMMOVE_NOBND:1181,BUILT_IN_CHKP_MEMMOVE_NOCHK:1182,BUILT_IN_CHKP_MEMMOVE_NO
BND_NOCHK:1183,BUILT_IN_CHKP_MEMPCPY_NOBND:1184,BUILT_IN_CHKP_MEMPCPY_NOCHK:1185
,BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK:1186,BUILT_IN_CHKP_MEMSET_NOBND:1187,BUILT_IN
_CHKP_MEMSET_NOCHK:1188,BUILT_IN_CHKP_MEMSET_NOBND_NOCHK:1189,BEGIN_CHKP_BUILTIN
S:1190,BUILT_IN_NONE_CHKP:1191,BUILT_IN_ACOS_CHKP:1192,BUILT_IN_ACOSF_CHKP:1193,
BUILT_IN_ACOSH_CHKP:1194,BUILT_IN_ACOSHF_CHKP:1195,BUILT_IN_ACOSHL_CHKP:1196,BUI
LT_IN_ACOSL_CHKP:1197,BUILT_IN_ALIGNED_ALLOC_CHKP:1198,BUILT_IN_ASIN_CHKP:1199,B
UILT_IN_ASINF_CHKP:1200,BUILT_IN_ASINH_CHKP:1201,BUILT_IN_ASINHF_CHKP:1202,BUILT
_IN_ASINHL_CHKP:1203,BUILT_IN_ASINL_CHKP:1204,BUILT_IN_ATAN_CHKP:1205,BUILT_IN_A
TAN2_CHKP:1206,BUILT_IN_ATAN2F_CHKP:1207,BUILT_IN_ATAN2L_CHKP:1208
...
BUILT_IN_CHKP_MEMSET_NOBND_NOCHK_CHKP:2380,END_CHKP_BUILTINS:2381,BUILT_IN_COMPLEX_MUL_MIN:2382,BUILT_IN_COMPLEX_MUL_MAX:2384,BUILT_IN_COMPLEX_DIV_MIN:2385,BUILT_IN_COMPLEX_DIV_MAX:2387,END_BUILTINS:2388,;",0,140,0

See tree-core.h

/* Codes that identify the various built in functions
   so that expand_call can identify them quickly.  */
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM,
enum built_in_function {
#include "builtins.def"

  BEGIN_CHKP_BUILTINS,

#undef DEF_BUILTIN
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM##_CHKP,
#include "builtins.def"

  END_CHKP_BUILTINS,

The header now includes builtins.def twice, including defining every
builtin a second time with _CHKP appended, even when
-fcheck-pointer-bounds is not enabled.  That is what is causing the
failure on AIX.

Eventually something else will overflow the list of builtins and GCC
should not generate broken assembly debug information.  Obviously no
one expected GCC to generate a type or enum larger than 64K.

Thanks, David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

The following patch seems to allow me to at least build stage1 GCC.
We'll see how far it get through bootstrap and testing.  Hopefully it
is a work-around until we find a complete solution.

Thanks, David

Index: tree-core.h
===================================================================
--- tree-core.h (revision 217658)
+++ tree-core.h (working copy)
@@ -170,10 +170,38 @@

   BEGIN_CHKP_BUILTINS,

-#undef DEF_BUILTIN
-#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM##_CHKP,
-#include "builtins.def"
+  BUILT_IN_MEMCPY_CHKP,
+  BUILT_IN_MEMPCPY_CHKP,
+  BUILT_IN_MEMMOVE_CHKP,
+  BUILT_IN_MEMSET_CHKP,
+  BUILT_IN_CHKP_MEMCPY_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMPCPY_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMMOVE_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMSET_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMCPY_NOBND_CHKP,
+  BUILT_IN_CHKP_MEMPCPY_NOBND_CHKP,
+  BUILT_IN_CHKP_MEMMOVE_NOBND_CHKP,
+  BUILT_IN_CHKP_MEMSET_NOBND_CHKP,
+  BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMMOVE_NOBND_NOCHK_CHKP,
+  BUILT_IN_CHKP_MEMSET_NOBND_NOCHK_CHKP,
+  BUILT_IN_MEMCPY_CHK_CHKP,
+  BUILT_IN_MEMPCPY_CHK_CHKP,

+  BUILT_IN_STPCPY_CHKP,
+  BUILT_IN_STRCAT_CHKP,
+  BUILT_IN_STRCHR_CHKP,
+  BUILT_IN_STRCPY_CHKP,
+  BUILT_IN_STRPCPY_CHKP,
+  BUILT_IN_STRLEN_CHKP,
+  BUILT_IN_STPCPY_CHK_CHKP,
+  BUILT_IN_STRCAT_CHK_CHKP,
+  BUILT_IN_STRCHR_CHK_CHKP,
+  BUILT_IN_STRCPY_CHK_CHKP,
+  BUILT_IN_STRPCPY_CHK_CHKP,
+  BUILT_IN_STRLEN_CHK_CHKP,
+
   END_CHKP_BUILTINS,

   /* Complex division routines in libgcc.  These are done via builtins

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/17/14 19:06, David Edelsohn wrote:
> The following patch seems to allow me to at least build stage1 GCC.
> We'll see how far it get through bootstrap and testing.  Hopefully it
> is a work-around until we find a complete solution.
>
> Thanks, David
>
> Index: tree-core.h
> ===================================================================
> --- tree-core.h (revision 217658)
> +++ tree-core.h (working copy)
> @@ -170,10 +170,38 @@
>
>     BEGIN_CHKP_BUILTINS,
>
> -#undef DEF_BUILTIN
> -#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM##_CHKP,
> -#include "builtins.def"
> +  BUILT_IN_MEMCPY_CHKP,
> +  BUILT_IN_MEMPCPY_CHKP,
> +  BUILT_IN_MEMMOVE_CHKP,
> +  BUILT_IN_MEMSET_CHKP,
> +  BUILT_IN_CHKP_MEMCPY_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMPCPY_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMMOVE_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMSET_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMCPY_NOBND_CHKP,
> +  BUILT_IN_CHKP_MEMPCPY_NOBND_CHKP,
> +  BUILT_IN_CHKP_MEMMOVE_NOBND_CHKP,
> +  BUILT_IN_CHKP_MEMSET_NOBND_CHKP,
> +  BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMMOVE_NOBND_NOCHK_CHKP,
> +  BUILT_IN_CHKP_MEMSET_NOBND_NOCHK_CHKP,
> +  BUILT_IN_MEMCPY_CHK_CHKP,
> +  BUILT_IN_MEMPCPY_CHK_CHKP,
>
> +  BUILT_IN_STPCPY_CHKP,
> +  BUILT_IN_STRCAT_CHKP,
> +  BUILT_IN_STRCHR_CHKP,
> +  BUILT_IN_STRCPY_CHKP,
> +  BUILT_IN_STRPCPY_CHKP,
> +  BUILT_IN_STRLEN_CHKP,
> +  BUILT_IN_STPCPY_CHK_CHKP,
> +  BUILT_IN_STRCAT_CHK_CHKP,
> +  BUILT_IN_STRCHR_CHK_CHKP,
> +  BUILT_IN_STRCPY_CHK_CHKP,
> +  BUILT_IN_STRPCPY_CHK_CHKP,
> +  BUILT_IN_STRLEN_CHK_CHKP,
I think this will break all the code though since there's no mapping 
from the original enumeration value for the builtin to the new one for 
the checker.


jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/17/14 18:18, David Edelsohn wrote:

>> I'll try to make a patch reducing amound of builtin codes to a
>> required minimum in case it appears to be the best option we have.
>
> I am not a stabstring expert, but the output that I am seeing in
> almost every assembler file and the output that is overflowing the
> file is:
Seeing this reminded me that, IIRC, we had some hacks to deal with 
insanely long stab strings in the past...   And a bit of reading 
dbxout.c reminds me it was DBX_CONTIN_LENGTH.

Presumably some of the xcoff bits aren't honoring DBX_CONTIN_LENGTH or 
maybe it just needs to be defined...

Jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/17/14 13:43, Ilya Enkovich wrote:

>
> I don't fully understand how this problem appears.  Is it fully AIX
> specific and doesn't affect any other target?  May we put all _CHKP
> codes to the end of enum and ignore them by AIX? Limiting number of
> codes in enum due to restrictions of specific debug info format seems
> weird.  If something cannot be encoded for debug info then it should
> be ignored.  I really hoped that creation of functions by demand would
> allow to avoid such kind of problems :(
>
> I'll try to make a patch reducing amound of builtin codes to a
> required minimum in case it appears to be the best option we have.
It's a problem with the AIX native tools.  Presumably they don't like 
really long lines -- it was a relatively common issue in the past with 
vendor tools.

I think we should proceed on two fronts.  First if David could 
investigate the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can 
be used to resolve the issue.  Second if you could look at now 
duplicating every builtin in the enumeration since it's a combination of 
the number of enums and the length of the debug strings to represent 
them that's causing AIX heartburn.



jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/17/14 13:05, Ilya Enkovich wrote:

>
> How comes you emit debug info for functions that do not exist and thus
> are never used?  Is problem caused by builtins going after
> END_CHKP_BUILTINS? Or some info generated for all builtins ignoring
> its existence?
IIRC, stabs aren't pruned based on whether or not they're used.  So 
every file that includes tree-core.h is going to have every name/value 
pair for the enum.  Hence the major heartburn for AIX.

jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Richard Biener]

On Tue, Nov 18, 2014 at 3:59 AM, Jeff Law <law@redhat.com> wrote:
> On 11/17/14 13:05, Ilya Enkovich wrote:
>
>>
>> How comes you emit debug info for functions that do not exist and thus
>> are never used?  Is problem caused by builtins going after
>> END_CHKP_BUILTINS? Or some info generated for all builtins ignoring
>> its existence?
>
> IIRC, stabs aren't pruned based on whether or not they're used.  So every
> file that includes tree-core.h is going to have every name/value pair for
> the enum.  Hence the major heartburn for AIX.

I wonder how AIX deals with the ever increasing number of target builtins
then.

Well.  Why can't we just drop enum values that exceed the stabs format?
At least I don't understand why we cannot "fix" this in the stabs output.
After all what happens to non-GCC code with such large enums?

Richard.

> jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich]

2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
> On 11/17/14 13:43, Ilya Enkovich wrote:
>
>>
>> I don't fully understand how this problem appears.  Is it fully AIX
>> specific and doesn't affect any other target?  May we put all _CHKP
>> codes to the end of enum and ignore them by AIX? Limiting number of
>> codes in enum due to restrictions of specific debug info format seems
>> weird.  If something cannot be encoded for debug info then it should
>> be ignored.  I really hoped that creation of functions by demand would
>> allow to avoid such kind of problems :(
>>
>> I'll try to make a patch reducing amound of builtin codes to a
>> required minimum in case it appears to be the best option we have.
>
> It's a problem with the AIX native tools.  Presumably they don't like really
> long lines -- it was a relatively common issue in the past with vendor
> tools.
>
> I think we should proceed on two fronts.  First if David could investigate
> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
> resolve the issue.  Second if you could look at now duplicating every
> builtin in the enumeration since it's a combination of the number of enums
> and the length of the debug strings to represent them that's causing AIX
> heartburn.
>
>
>
> jeff

I see.  I can reduce the number of _CHKP builtin codes. Experimental
patch shows resulting END_BUILTINS = 1242.  But we should expect
similar problem for i386 target builds hosted on AIX (here
http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
Current IX86_BUILTIN_MAX is 2467 which is greater than current
END_BUILTINS.

Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Richard Biener]

On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>
>>>
>>> I don't fully understand how this problem appears.  Is it fully AIX
>>> specific and doesn't affect any other target?  May we put all _CHKP
>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>> codes in enum due to restrictions of specific debug info format seems
>>> weird.  If something cannot be encoded for debug info then it should
>>> be ignored.  I really hoped that creation of functions by demand would
>>> allow to avoid such kind of problems :(
>>>
>>> I'll try to make a patch reducing amound of builtin codes to a
>>> required minimum in case it appears to be the best option we have.
>>
>> It's a problem with the AIX native tools.  Presumably they don't like really
>> long lines -- it was a relatively common issue in the past with vendor
>> tools.
>>
>> I think we should proceed on two fronts.  First if David could investigate
>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>> resolve the issue.  Second if you could look at now duplicating every
>> builtin in the enumeration since it's a combination of the number of enums
>> and the length of the debug strings to represent them that's causing AIX
>> heartburn.
>>
>>
>>
>> jeff
>
> I see.  I can reduce the number of _CHKP builtin codes. Experimental
> patch shows resulting END_BUILTINS = 1242.  But we should expect
> similar problem for i386 target builds hosted on AIX (here
> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
> Current IX86_BUILTIN_MAX is 2467 which is greater than current
> END_BUILTINS.

I think it's better to fix dbxout.c to do something sensible with
too long lines for enum types.  It should be easy to cook up a
testcase that is not GCC.

enum { entry1, entry2, entry3.... };

not sure how exactly the issue breaks AIX bootstrap though.  I suppose
the assembler complains?

Richard.

> Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich]

2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>>
>>>>
>>>> I don't fully understand how this problem appears.  Is it fully AIX
>>>> specific and doesn't affect any other target?  May we put all _CHKP
>>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>>> codes in enum due to restrictions of specific debug info format seems
>>>> weird.  If something cannot be encoded for debug info then it should
>>>> be ignored.  I really hoped that creation of functions by demand would
>>>> allow to avoid such kind of problems :(
>>>>
>>>> I'll try to make a patch reducing amound of builtin codes to a
>>>> required minimum in case it appears to be the best option we have.
>>>
>>> It's a problem with the AIX native tools.  Presumably they don't like really
>>> long lines -- it was a relatively common issue in the past with vendor
>>> tools.
>>>
>>> I think we should proceed on two fronts.  First if David could investigate
>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>>> resolve the issue.  Second if you could look at now duplicating every
>>> builtin in the enumeration since it's a combination of the number of enums
>>> and the length of the debug strings to represent them that's causing AIX
>>> heartburn.
>>>
>>>
>>>
>>> jeff
>>
>> I see.  I can reduce the number of _CHKP builtin codes. Experimental
>> patch shows resulting END_BUILTINS = 1242.  But we should expect
>> similar problem for i386 target builds hosted on AIX (here
>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
>> Current IX86_BUILTIN_MAX is 2467 which is greater than current
>> END_BUILTINS.
>
> I think it's better to fix dbxout.c to do something sensible with
> too long lines for enum types.  It should be easy to cook up a
> testcase that is not GCC.
>
> enum { entry1, entry2, entry3.... };
>

As I understand the main problem is that fixing dbxout in trunk won't
help to build stage1 compiler.

> not sure how exactly the issue breaks AIX bootstrap though.  I suppose
> the assembler complains?

It is linker how complaints. Here is a build log example:
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=3073584

Ilya

>
> Richard.
>
>> Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Richard Biener]

On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>>>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>>>
>>>>>
>>>>> I don't fully understand how this problem appears.  Is it fully AIX
>>>>> specific and doesn't affect any other target?  May we put all _CHKP
>>>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>>>> codes in enum due to restrictions of specific debug info format seems
>>>>> weird.  If something cannot be encoded for debug info then it should
>>>>> be ignored.  I really hoped that creation of functions by demand would
>>>>> allow to avoid such kind of problems :(
>>>>>
>>>>> I'll try to make a patch reducing amound of builtin codes to a
>>>>> required minimum in case it appears to be the best option we have.
>>>>
>>>> It's a problem with the AIX native tools.  Presumably they don't like really
>>>> long lines -- it was a relatively common issue in the past with vendor
>>>> tools.
>>>>
>>>> I think we should proceed on two fronts.  First if David could investigate
>>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>>>> resolve the issue.  Second if you could look at now duplicating every
>>>> builtin in the enumeration since it's a combination of the number of enums
>>>> and the length of the debug strings to represent them that's causing AIX
>>>> heartburn.
>>>>
>>>>
>>>>
>>>> jeff
>>>
>>> I see.  I can reduce the number of _CHKP builtin codes. Experimental
>>> patch shows resulting END_BUILTINS = 1242.  But we should expect
>>> similar problem for i386 target builds hosted on AIX (here
>>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
>>> Current IX86_BUILTIN_MAX is 2467 which is greater than current
>>> END_BUILTINS.
>>
>> I think it's better to fix dbxout.c to do something sensible with
>> too long lines for enum types.  It should be easy to cook up a
>> testcase that is not GCC.
>>
>> enum { entry1, entry2, entry3.... };
>>
>
> As I understand the main problem is that fixing dbxout in trunk won't
> help to build stage1 compiler.

Simply build stage1 without debug info on AIX then.

Btw, you have to start fixing the bug at some point ... (we can
backport to 4.8 and 4.9).  Of course dbxout.c is in kind of
deep-freeze unmaintained state.

I don't think we ever encouraged work-arounds for broken host compilers
if that requires substantial work.

>> not sure how exactly the issue breaks AIX bootstrap though.  I suppose
>> the assembler complains?
>
> It is linker how complaints. Here is a build log example:
> http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=3073584

I see.

Thanks,
Richard.

> Ilya
>
>>
>> Richard.
>>
>>> Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich]

2014-11-18 15:18 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>> 2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>>>>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>>>>
>>>>>>
>>>>>> I don't fully understand how this problem appears.  Is it fully AIX
>>>>>> specific and doesn't affect any other target?  May we put all _CHKP
>>>>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>>>>> codes in enum due to restrictions of specific debug info format seems
>>>>>> weird.  If something cannot be encoded for debug info then it should
>>>>>> be ignored.  I really hoped that creation of functions by demand would
>>>>>> allow to avoid such kind of problems :(
>>>>>>
>>>>>> I'll try to make a patch reducing amound of builtin codes to a
>>>>>> required minimum in case it appears to be the best option we have.
>>>>>
>>>>> It's a problem with the AIX native tools.  Presumably they don't like really
>>>>> long lines -- it was a relatively common issue in the past with vendor
>>>>> tools.
>>>>>
>>>>> I think we should proceed on two fronts.  First if David could investigate
>>>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>>>>> resolve the issue.  Second if you could look at now duplicating every
>>>>> builtin in the enumeration since it's a combination of the number of enums
>>>>> and the length of the debug strings to represent them that's causing AIX
>>>>> heartburn.
>>>>>
>>>>>
>>>>>
>>>>> jeff
>>>>
>>>> I see.  I can reduce the number of _CHKP builtin codes. Experimental
>>>> patch shows resulting END_BUILTINS = 1242.  But we should expect
>>>> similar problem for i386 target builds hosted on AIX (here
>>>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
>>>> Current IX86_BUILTIN_MAX is 2467 which is greater than current
>>>> END_BUILTINS.
>>>
>>> I think it's better to fix dbxout.c to do something sensible with
>>> too long lines for enum types.  It should be easy to cook up a
>>> testcase that is not GCC.
>>>
>>> enum { entry1, entry2, entry3.... };
>>>
>>
>> As I understand the main problem is that fixing dbxout in trunk won't
>> help to build stage1 compiler.
>
> Simply build stage1 without debug info on AIX then.
>
> Btw, you have to start fixing the bug at some point ... (we can
> backport to 4.8 and 4.9).  Of course dbxout.c is in kind of
> deep-freeze unmaintained state.

Seems with no continuation lines support there is no easy way to limit
stabstring length.  But it should be easy to fix this particular
problem (too long stabstring due to many enum values) by discarding
the rest of values when some string length threshold is hit.  Possible
patch:

diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index aa15a39..9b0b82d 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -168,6 +168,10 @@ along with GCC; see the file COPYING3.  If not see
 #define DBX_CONTIN_CHAR '\\'
 #endif

+#ifndef DBX_MAX_LENGTH
+#define DBX_MAX_LENGTH 0
+#endif
+
 enum typestatus {TYPE_UNSEEN, TYPE_XREF, TYPE_DEFINED};

 /* Structure recording information about a C data type.
@@ -2270,6 +2274,12 @@ dbxout_type (tree type, int full)
          stabstr_C (',');
          if (TREE_CHAIN (tem) != 0)
            CONTIN;
+
+         /* Prevent too long strings rejected by linker.  */
+         if (DBX_CONTIN_LENGTH == 0
+             && DBX_MAX_LENGTH != 0
+             && obstack_object_size (&stabstr_ob) > DBX_MAX_LENGTH)
+           break;
        }

       stabstr_C (';');

With this we should be able to set limit in target config files.
Tried on linux with a small test with limit set to 20:

>cat test.c
enum e1 {
  val1, val2, val3
};
>gcc test.c -S -gstabs
>grep e1 test.s
        .stabs  "e1:T(0,21)=eval1:0,val2:1,;",128,0,0,0


The last enum value was discarded.

I don't know which target should set this limit and what limit values
should be used.

Thanks,
Ilya

>
> I don't think we ever encouraged work-arounds for broken host compilers
> if that requires substantial work.
>
>>> not sure how exactly the issue breaks AIX bootstrap though.  I suppose
>>> the assembler complains?
>>
>> It is linker how complaints. Here is a build log example:
>> http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=3073584
>
> I see.
>
> Thanks,
> Richard.
>
>> Ilya
>>
>>>
>>> Richard.
>>>
>>>> Ilya

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2014-11-18 15:18 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>> 2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>>> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>>>>>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>>>>>
>>>>>>>
>>>>>>> I don't fully understand how this problem appears.  Is it fully AIX
>>>>>>> specific and doesn't affect any other target?  May we put all _CHKP
>>>>>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>>>>>> codes in enum due to restrictions of specific debug info format seems
>>>>>>> weird.  If something cannot be encoded for debug info then it should
>>>>>>> be ignored.  I really hoped that creation of functions by demand would
>>>>>>> allow to avoid such kind of problems :(
>>>>>>>
>>>>>>> I'll try to make a patch reducing amound of builtin codes to a
>>>>>>> required minimum in case it appears to be the best option we have.
>>>>>>
>>>>>> It's a problem with the AIX native tools.  Presumably they don't like really
>>>>>> long lines -- it was a relatively common issue in the past with vendor
>>>>>> tools.
>>>>>>
>>>>>> I think we should proceed on two fronts.  First if David could investigate
>>>>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>>>>>> resolve the issue.  Second if you could look at now duplicating every
>>>>>> builtin in the enumeration since it's a combination of the number of enums
>>>>>> and the length of the debug strings to represent them that's causing AIX
>>>>>> heartburn.
>>>>>>
>>>>>>
>>>>>>
>>>>>> jeff
>>>>>
>>>>> I see.  I can reduce the number of _CHKP builtin codes. Experimental
>>>>> patch shows resulting END_BUILTINS = 1242.  But we should expect
>>>>> similar problem for i386 target builds hosted on AIX (here
>>>>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
>>>>> Current IX86_BUILTIN_MAX is 2467 which is greater than current
>>>>> END_BUILTINS.
>>>>
>>>> I think it's better to fix dbxout.c to do something sensible with
>>>> too long lines for enum types.  It should be easy to cook up a
>>>> testcase that is not GCC.
>>>>
>>>> enum { entry1, entry2, entry3.... };
>>>>
>>>
>>> As I understand the main problem is that fixing dbxout in trunk won't
>>> help to build stage1 compiler.
>>
>> Simply build stage1 without debug info on AIX then.
>>
>> Btw, you have to start fixing the bug at some point ... (we can
>> backport to 4.8 and 4.9).  Of course dbxout.c is in kind of
>> deep-freeze unmaintained state.
>
> Seems with no continuation lines support there is no easy way to limit
> stabstring length.  But it should be easy to fix this particular
> problem (too long stabstring due to many enum values) by discarding
> the rest of values when some string length threshold is hit.  Possible
> patch:
>
> diff --git a/gcc/dbxout.c b/gcc/dbxout.c
> index aa15a39..9b0b82d 100644
> --- a/gcc/dbxout.c
> +++ b/gcc/dbxout.c
> @@ -168,6 +168,10 @@ along with GCC; see the file COPYING3.  If not see
>  #define DBX_CONTIN_CHAR '\\'
>  #endif
>
> +#ifndef DBX_MAX_LENGTH
> +#define DBX_MAX_LENGTH 0
> +#endif
> +
>  enum typestatus {TYPE_UNSEEN, TYPE_XREF, TYPE_DEFINED};
>
>  /* Structure recording information about a C data type.
> @@ -2270,6 +2274,12 @@ dbxout_type (tree type, int full)
>           stabstr_C (',');
>           if (TREE_CHAIN (tem) != 0)
>             CONTIN;
> +
> +         /* Prevent too long strings rejected by linker.  */
> +         if (DBX_CONTIN_LENGTH == 0
> +             && DBX_MAX_LENGTH != 0
> +             && obstack_object_size (&stabstr_ob) > DBX_MAX_LENGTH)
> +           break;
>         }
>
>        stabstr_C (';');
>
> With this we should be able to set limit in target config files.
> Tried on linux with a small test with limit set to 20:
>
>>cat test.c
> enum e1 {
>   val1, val2, val3
> };
>>gcc test.c -S -gstabs
>>grep e1 test.s
>         .stabs  "e1:T(0,21)=eval1:0,val2:1,;",128,0,0,0
>
>
> The last enum value was discarded.
>
> I don't know which target should set this limit and what limit values
> should be used.

Hi, Ilya

Thanks for the preliminary patch to dbxout.c.  I was planning to work
on something similar today.

Continuations would have been a nice solution, but, as I wrote
earlier, AIX assembler does not honor stabstring continuations.  It's
one line, period. As much as can fit on one line.  I believe that AIX
allows up to 64K.

My work-around was not meant as a solution.  I was trying to allow GCC
to build on AIX while we work on a solution and trying to help
everyone understand the source of the problem.

We definitely need a fix for dbxout in GCC and backport it to GCC 4.8
and GCC 4.9 branches.

I still think that it is rather unfortunate that the infrastructure
for CHKP introduces so much bloat into GCC on every target and every
architecture even when it is not enabled and cannot function.

Thanks, David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Richard Biener]

On Tue, Nov 18, 2014 at 2:44 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>> 2014-11-18 15:18 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>> 2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>>>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>>>> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>>>>>>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I don't fully understand how this problem appears.  Is it fully AIX
>>>>>>>> specific and doesn't affect any other target?  May we put all _CHKP
>>>>>>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>>>>>>> codes in enum due to restrictions of specific debug info format seems
>>>>>>>> weird.  If something cannot be encoded for debug info then it should
>>>>>>>> be ignored.  I really hoped that creation of functions by demand would
>>>>>>>> allow to avoid such kind of problems :(
>>>>>>>>
>>>>>>>> I'll try to make a patch reducing amound of builtin codes to a
>>>>>>>> required minimum in case it appears to be the best option we have.
>>>>>>>
>>>>>>> It's a problem with the AIX native tools.  Presumably they don't like really
>>>>>>> long lines -- it was a relatively common issue in the past with vendor
>>>>>>> tools.
>>>>>>>
>>>>>>> I think we should proceed on two fronts.  First if David could investigate
>>>>>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>>>>>>> resolve the issue.  Second if you could look at now duplicating every
>>>>>>> builtin in the enumeration since it's a combination of the number of enums
>>>>>>> and the length of the debug strings to represent them that's causing AIX
>>>>>>> heartburn.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> jeff
>>>>>>
>>>>>> I see.  I can reduce the number of _CHKP builtin codes. Experimental
>>>>>> patch shows resulting END_BUILTINS = 1242.  But we should expect
>>>>>> similar problem for i386 target builds hosted on AIX (here
>>>>>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
>>>>>> Current IX86_BUILTIN_MAX is 2467 which is greater than current
>>>>>> END_BUILTINS.
>>>>>
>>>>> I think it's better to fix dbxout.c to do something sensible with
>>>>> too long lines for enum types.  It should be easy to cook up a
>>>>> testcase that is not GCC.
>>>>>
>>>>> enum { entry1, entry2, entry3.... };
>>>>>
>>>>
>>>> As I understand the main problem is that fixing dbxout in trunk won't
>>>> help to build stage1 compiler.
>>>
>>> Simply build stage1 without debug info on AIX then.
>>>
>>> Btw, you have to start fixing the bug at some point ... (we can
>>> backport to 4.8 and 4.9).  Of course dbxout.c is in kind of
>>> deep-freeze unmaintained state.
>>
>> Seems with no continuation lines support there is no easy way to limit
>> stabstring length.  But it should be easy to fix this particular
>> problem (too long stabstring due to many enum values) by discarding
>> the rest of values when some string length threshold is hit.  Possible
>> patch:
>>
>> diff --git a/gcc/dbxout.c b/gcc/dbxout.c
>> index aa15a39..9b0b82d 100644
>> --- a/gcc/dbxout.c
>> +++ b/gcc/dbxout.c
>> @@ -168,6 +168,10 @@ along with GCC; see the file COPYING3.  If not see
>>  #define DBX_CONTIN_CHAR '\\'
>>  #endif
>>
>> +#ifndef DBX_MAX_LENGTH
>> +#define DBX_MAX_LENGTH 0
>> +#endif
>> +
>>  enum typestatus {TYPE_UNSEEN, TYPE_XREF, TYPE_DEFINED};
>>
>>  /* Structure recording information about a C data type.
>> @@ -2270,6 +2274,12 @@ dbxout_type (tree type, int full)
>>           stabstr_C (',');
>>           if (TREE_CHAIN (tem) != 0)
>>             CONTIN;
>> +
>> +         /* Prevent too long strings rejected by linker.  */
>> +         if (DBX_CONTIN_LENGTH == 0
>> +             && DBX_MAX_LENGTH != 0
>> +             && obstack_object_size (&stabstr_ob) > DBX_MAX_LENGTH)
>> +           break;
>>         }
>>
>>        stabstr_C (';');
>>
>> With this we should be able to set limit in target config files.
>> Tried on linux with a small test with limit set to 20:
>>
>>>cat test.c
>> enum e1 {
>>   val1, val2, val3
>> };
>>>gcc test.c -S -gstabs
>>>grep e1 test.s
>>         .stabs  "e1:T(0,21)=eval1:0,val2:1,;",128,0,0,0
>>
>>
>> The last enum value was discarded.
>>
>> I don't know which target should set this limit and what limit values
>> should be used.
>
> Hi, Ilya
>
> Thanks for the preliminary patch to dbxout.c.  I was planning to work
> on something similar today.
>
> Continuations would have been a nice solution, but, as I wrote
> earlier, AIX assembler does not honor stabstring continuations.

Can we emit this particular STABS piece in "raw" form then?  Thus
does it work to have sth like

   .stabs ...
   .string "..."
   .stabs ...

or whatever way to emit assembled data there?

>  It's
> one line, period. As much as can fit on one line.  I believe that AIX
> allows up to 64K.

Can we get the assembler fixed? (sorry to ask this stupid question
again ...)

> My work-around was not meant as a solution.  I was trying to allow GCC
> to build on AIX while we work on a solution and trying to help
> everyone understand the source of the problem.
>
> We definitely need a fix for dbxout in GCC and backport it to GCC 4.8
> and GCC 4.9 branches.
>
> I still think that it is rather unfortunate that the infrastructure
> for CHKP introduces so much bloat into GCC on every target and every
> architecture even when it is not enabled and cannot function.

True, but as said if you try to build a cross to x86_64 on AIX you'd
have hit the issue much earlier.

Richard.

> Thanks, David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

On Tue, Nov 18, 2014 at 9:07 AM, Richard Biener
<richard.guenther@gmail.com> wrote:

> Can we emit this particular STABS piece in "raw" form then?  Thus
> does it work to have sth like
>
>    .stabs ...
>    .string "..."
>    .stabs ...
>
> or whatever way to emit assembled data there?

The stabstring debug information is saved as a length and a string.
For 32 bit AIX, the length is an unsigned short.  Longer entries
apparently can be stored in multiple symbol table entries, but it's
not clear how to emit assembly to produce that effect.  For 64 bit
AIX, the length is an unsigned int 32 bits, so one may be able to work
around this problem by compiling GCC on AIX in 64 bit mode.  A
conversion to default 64 bit build will take a lot of work.

Thanks, David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/18/14 02:55, Richard Biener wrote:
> On Tue, Nov 18, 2014 at 3:59 AM, Jeff Law <law@redhat.com> wrote:
>> On 11/17/14 13:05, Ilya Enkovich wrote:
>>
>>>
>>> How comes you emit debug info for functions that do not exist and thus
>>> are never used?  Is problem caused by builtins going after
>>> END_CHKP_BUILTINS? Or some info generated for all builtins ignoring
>>> its existence?
>>
>> IIRC, stabs aren't pruned based on whether or not they're used.  So every
>> file that includes tree-core.h is going to have every name/value pair for
>> the enum.  Hence the major heartburn for AIX.
>
> I wonder how AIX deals with the ever increasing number of target builtins
> then.
>
> Well.  Why can't we just drop enum values that exceed the stabs format?
> At least I don't understand why we cannot "fix" this in the stabs output.
> After all what happens to non-GCC code with such large enums?
I can live with that -- I don't expect we'll have the need to be looking 
at those enum values on AIX often :-)

jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/18/14 05:18, Richard Biener wrote:

>>
>> As I understand the main problem is that fixing dbxout in trunk won't
>> help to build stage1 compiler.
>
> Simply build stage1 without debug info on AIX then.
>
> Btw, you have to start fixing the bug at some point ... (we can
> backport to 4.8 and 4.9).  Of course dbxout.c is in kind of
> deep-freeze unmaintained state.
>
> I don't think we ever encouraged work-arounds for broken host compilers
> if that requires substantial work.
It's always depended on the amount of work involved.  We have to do far 
less catering to broken host compilers these days.

I wouldn't lose any sleep if we just truncated as these stab strings get 
really big.  I don't think we want to much too much effort into dbxout.c :-)


Jeff

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[David Edelsohn]

On Tue, Nov 18, 2014 at 1:44 PM, Jeff Law <law@redhat.com> wrote:
> On 11/18/14 05:18, Richard Biener wrote:
>
>>>
>>> As I understand the main problem is that fixing dbxout in trunk won't
>>> help to build stage1 compiler.
>>
>>
>> Simply build stage1 without debug info on AIX then.
>>
>> Btw, you have to start fixing the bug at some point ... (we can
>> backport to 4.8 and 4.9).  Of course dbxout.c is in kind of
>> deep-freeze unmaintained state.
>>
>> I don't think we ever encouraged work-arounds for broken host compilers
>> if that requires substantial work.
>
> It's always depended on the amount of work involved.  We have to do far less
> catering to broken host compilers these days.
>
> I wouldn't lose any sleep if we just truncated as these stab strings get
> really big.  I don't think we want to much too much effort into dbxout.c :-)

AIX assembler does not support continuation lines, but apparently one
may be able to emit multiple, adjacent .stabx pseudo-ops if the string
is broken at a grammatically correct location.  In other words,
"continuations" with a complicated string of characters to end one
.stabx and start another.

- David

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Jeff Law]

On 11/06/14 05:24, Ilya Enkovich wrote:
> Hi,
>
> This patch adds support of instrumented builtin calls in expand.  Calls are mostly expanded as calls.  But some of them reuse existing string function calls expand functions (memcpy expand was slightly refactored for that).
>
> This is the last enabling patch in this series.  Remaining two patches are performance ones.
>
> Thanks,
> Ilya
> --
> 2014-11-06  Ilya Enkovich  <ilya.enkovich@intel.com>
>
> 	* builtins.c (expand_builtin_memcpy_args): New.
> 	(expand_builtin_memcpy): Call expand_builtin_memcpy_args.
> 	(expand_builtin_memcpy_with_bounds): New.
> 	(expand_builtin_mempcpy_with_bounds): New.
> 	(expand_builtin_mempcpy_args): Add orig_exp arg. Support
> 	BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK
> 	(expand_builtin_memset_with_bounds): New.
> 	(expand_builtin_memset_args): Support BUILT_IN_CHKP_MEMSET_NOBND_NOCHK.
> 	(expand_builtin_with_bounds): New.
> 	* builtins.h (expand_builtin_with_bounds): New.
> 	* expr.c (expand_expr_real_1): Support instrumented builtin calls.
>
>
OK if/when rest of series is approved.

jeff

[PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich]

Hi,

This patch adds support of instrumented builtin calls in expand.  Calls are mostly expanded as calls.  But some of them reuse existing string function calls expand functions (memcpy expand was slightly refactored for that).

This is the last enabling patch in this series.  Remaining two patches are performance ones.

Thanks,
Ilya
--
2014-11-06  Ilya Enkovich  <ilya.enkovich@intel.com>

	* builtins.c (expand_builtin_memcpy_args): New.
	(expand_builtin_memcpy): Call expand_builtin_memcpy_args.
	(expand_builtin_memcpy_with_bounds): New.
	(expand_builtin_mempcpy_with_bounds): New.
	(expand_builtin_mempcpy_args): Add orig_exp arg. Support
	BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK
	(expand_builtin_memset_with_bounds): New.
	(expand_builtin_memset_args): Support BUILT_IN_CHKP_MEMSET_NOBND_NOCHK.
	(expand_builtin_with_bounds): New.
	* builtins.h (expand_builtin_with_bounds): New.
	* expr.c (expand_expr_real_1): Support instrumented builtin calls.


diff --git a/gcc/builtins.c b/gcc/builtins.c
index 71fbf09..b34f855 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -133,15 +133,19 @@ static rtx expand_builtin_strcmp (tree, rtx);
 static rtx expand_builtin_strncmp (tree, rtx, machine_mode);
 static rtx builtin_memcpy_read_str (void *, HOST_WIDE_INT, machine_mode);
 static rtx expand_builtin_memcpy (tree, rtx);
+static rtx expand_builtin_memcpy_with_bounds (tree, rtx);
+static rtx expand_builtin_memcpy_args (tree, tree, tree, rtx, tree);
 static rtx expand_builtin_mempcpy (tree, rtx, machine_mode);
+static rtx expand_builtin_mempcpy_with_bounds (tree, rtx, machine_mode);
 static rtx expand_builtin_mempcpy_args (tree, tree, tree, rtx,
-					machine_mode, int);
+					machine_mode, int, tree);
 static rtx expand_builtin_strcpy (tree, rtx);
 static rtx expand_builtin_strcpy_args (tree, tree, rtx);
 static rtx expand_builtin_stpcpy (tree, rtx, machine_mode);
 static rtx expand_builtin_strncpy (tree, rtx);
 static rtx builtin_memset_gen_str (void *, HOST_WIDE_INT, machine_mode);
 static rtx expand_builtin_memset (tree, rtx, machine_mode);
+static rtx expand_builtin_memset_with_bounds (tree, rtx, machine_mode);
 static rtx expand_builtin_memset_args (tree, tree, tree, rtx, machine_mode, tree);
 static rtx expand_builtin_bzero (tree);
 static rtx expand_builtin_strlen (tree, rtx, machine_mode);
@@ -3176,6 +3180,81 @@ determine_block_size (tree len, rtx len_rtx,
 			  GET_MODE_MASK (GET_MODE (len_rtx)));
 }
 
+/* Helper function to do the actual work for expand_builtin_memcpy.  */
+
+static rtx
+expand_builtin_memcpy_args (tree dest, tree src, tree len, rtx target, tree exp)
+{
+  const char *src_str;
+  unsigned int src_align = get_pointer_alignment (src);
+  unsigned int dest_align = get_pointer_alignment (dest);
+  rtx dest_mem, src_mem, dest_addr, len_rtx;
+  HOST_WIDE_INT expected_size = -1;
+  unsigned int expected_align = 0;
+  unsigned HOST_WIDE_INT min_size;
+  unsigned HOST_WIDE_INT max_size;
+  unsigned HOST_WIDE_INT probable_max_size;
+
+  /* If DEST is not a pointer type, call the normal function.  */
+  if (dest_align == 0)
+    return NULL_RTX;
+
+  /* If either SRC is not a pointer type, don't do this
+     operation in-line.  */
+  if (src_align == 0)
+    return NULL_RTX;
+
+  if (currently_expanding_gimple_stmt)
+    stringop_block_profile (currently_expanding_gimple_stmt,
+			    &expected_align, &expected_size);
+
+  if (expected_align < dest_align)
+    expected_align = dest_align;
+  dest_mem = get_memory_rtx (dest, len);
+  set_mem_align (dest_mem, dest_align);
+  len_rtx = expand_normal (len);
+  determine_block_size (len, len_rtx, &min_size, &max_size,
+			&probable_max_size);
+  src_str = c_getstr (src);
+
+  /* If SRC is a string constant and block move would be done
+     by pieces, we can avoid loading the string from memory
+     and only stored the computed constants.  */
+  if (src_str
+      && CONST_INT_P (len_rtx)
+      && (unsigned HOST_WIDE_INT) INTVAL (len_rtx) <= strlen (src_str) + 1
+      && can_store_by_pieces (INTVAL (len_rtx), builtin_memcpy_read_str,
+			      CONST_CAST (char *, src_str),
+			      dest_align, false))
+    {
+      dest_mem = store_by_pieces (dest_mem, INTVAL (len_rtx),
+				  builtin_memcpy_read_str,
+				  CONST_CAST (char *, src_str),
+				  dest_align, false, 0);
+      dest_mem = force_operand (XEXP (dest_mem, 0), target);
+      dest_mem = convert_memory_address (ptr_mode, dest_mem);
+      return dest_mem;
+    }
+
+  src_mem = get_memory_rtx (src, len);
+  set_mem_align (src_mem, src_align);
+
+  /* Copy word part most expediently.  */
+  dest_addr = emit_block_move_hints (dest_mem, src_mem, len_rtx,
+				     CALL_EXPR_TAILCALL (exp)
+				     ? BLOCK_OP_TAILCALL : BLOCK_OP_NORMAL,
+				     expected_align, expected_size,
+				     min_size, max_size, probable_max_size);
+
+  if (dest_addr == 0)
+    {
+      dest_addr = force_operand (XEXP (dest_mem, 0), target);
+      dest_addr = convert_memory_address (ptr_mode, dest_addr);
+    }
+
+  return dest_addr;
+}
+
 /* Expand a call EXP to the memcpy builtin.
    Return NULL_RTX if we failed, the caller should emit a normal call,
    otherwise try to get the result in TARGET, if convenient (and in
@@ -3192,73 +3271,38 @@ expand_builtin_memcpy (tree exp, rtx target)
       tree dest = CALL_EXPR_ARG (exp, 0);
       tree src = CALL_EXPR_ARG (exp, 1);
       tree len = CALL_EXPR_ARG (exp, 2);
-      const char *src_str;
-      unsigned int src_align = get_pointer_alignment (src);
-      unsigned int dest_align = get_pointer_alignment (dest);
-      rtx dest_mem, src_mem, dest_addr, len_rtx;
-      HOST_WIDE_INT expected_size = -1;
-      unsigned int expected_align = 0;
-      unsigned HOST_WIDE_INT min_size;
-      unsigned HOST_WIDE_INT max_size;
-      unsigned HOST_WIDE_INT probable_max_size;
-
-      /* If DEST is not a pointer type, call the normal function.  */
-      if (dest_align == 0)
-	return NULL_RTX;
-
-      /* If either SRC is not a pointer type, don't do this
-	 operation in-line.  */
-      if (src_align == 0)
-	return NULL_RTX;
-
-      if (currently_expanding_gimple_stmt)
-        stringop_block_profile (currently_expanding_gimple_stmt,
-				&expected_align, &expected_size);
-
-      if (expected_align < dest_align)
-	expected_align = dest_align;
-      dest_mem = get_memory_rtx (dest, len);
-      set_mem_align (dest_mem, dest_align);
-      len_rtx = expand_normal (len);
-      determine_block_size (len, len_rtx, &min_size, &max_size,
-			    &probable_max_size);
-      src_str = c_getstr (src);
-
-      /* If SRC is a string constant and block move would be done
-	 by pieces, we can avoid loading the string from memory
-	 and only stored the computed constants.  */
-      if (src_str
-	  && CONST_INT_P (len_rtx)
-	  && (unsigned HOST_WIDE_INT) INTVAL (len_rtx) <= strlen (src_str) + 1
-	  && can_store_by_pieces (INTVAL (len_rtx), builtin_memcpy_read_str,
-				  CONST_CAST (char *, src_str),
-				  dest_align, false))
-	{
-	  dest_mem = store_by_pieces (dest_mem, INTVAL (len_rtx),
-				      builtin_memcpy_read_str,
-				      CONST_CAST (char *, src_str),
-				      dest_align, false, 0);
-	  dest_mem = force_operand (XEXP (dest_mem, 0), target);
-	  dest_mem = convert_memory_address (ptr_mode, dest_mem);
-	  return dest_mem;
-	}
+      return expand_builtin_memcpy_args (dest, src, len, target, exp);
+    }
+}
 
-      src_mem = get_memory_rtx (src, len);
-      set_mem_align (src_mem, src_align);
+/* Expand an instrumented call EXP to the memcpy builtin.
+   Return NULL_RTX if we failed, the caller should emit a normal call,
+   otherwise try to get the result in TARGET, if convenient (and in
+   mode MODE if that's convenient).  */
 
-      /* Copy word part most expediently.  */
-      dest_addr = emit_block_move_hints (dest_mem, src_mem, len_rtx,
-				         CALL_EXPR_TAILCALL (exp)
-				         ? BLOCK_OP_TAILCALL : BLOCK_OP_NORMAL,
-					 expected_align, expected_size,
-					 min_size, max_size, probable_max_size);
+static rtx
+expand_builtin_memcpy_with_bounds (tree exp, rtx target)
+{
+  if (!validate_arglist (exp,
+			 POINTER_TYPE, POINTER_BOUNDS_TYPE,
+			 POINTER_TYPE, POINTER_BOUNDS_TYPE,
+			 INTEGER_TYPE, VOID_TYPE))
+    return NULL_RTX;
+  else
+    {
+      tree dest = CALL_EXPR_ARG (exp, 0);
+      tree src = CALL_EXPR_ARG (exp, 2);
+      tree len = CALL_EXPR_ARG (exp, 4);
+      rtx res = expand_builtin_memcpy_args (dest, src, len, target, exp);
 
-      if (dest_addr == 0)
+      /* Return src bounds with the result.  */
+      if (res)
 	{
-	  dest_addr = force_operand (XEXP (dest_mem, 0), target);
-	  dest_addr = convert_memory_address (ptr_mode, dest_addr);
+	  rtx bnd = force_reg (BNDmode,
+			       expand_normal (CALL_EXPR_ARG (exp, 1)));
+	  res = chkp_join_splitted_slot (res, bnd);
 	}
-      return dest_addr;
+      return res;
     }
 }
 
@@ -3282,7 +3326,40 @@ expand_builtin_mempcpy (tree exp, rtx target, machine_mode mode)
       tree src = CALL_EXPR_ARG (exp, 1);
       tree len = CALL_EXPR_ARG (exp, 2);
       return expand_builtin_mempcpy_args (dest, src, len,
-					  target, mode, /*endp=*/ 1);
+					  target, mode, /*endp=*/ 1,
+					  exp);
+    }
+}
+
+/* Expand an instrumented call EXP to the mempcpy builtin.
+   Return NULL_RTX if we failed, the caller should emit a normal call,
+   otherwise try to get the result in TARGET, if convenient (and in
+   mode MODE if that's convenient).  */
+
+static rtx
+expand_builtin_mempcpy_with_bounds (tree exp, rtx target, machine_mode mode)
+{
+  if (!validate_arglist (exp,
+			 POINTER_TYPE, POINTER_BOUNDS_TYPE,
+			 POINTER_TYPE, POINTER_BOUNDS_TYPE,
+			 INTEGER_TYPE, VOID_TYPE))
+    return NULL_RTX;
+  else
+    {
+      tree dest = CALL_EXPR_ARG (exp, 0);
+      tree src = CALL_EXPR_ARG (exp, 2);
+      tree len = CALL_EXPR_ARG (exp, 4);
+      rtx res = expand_builtin_mempcpy_args (dest, src, len, target,
+					     mode, 1, exp);
+
+      /* Return src bounds with the result.  */
+      if (res)
+	{
+	  rtx bnd = force_reg (BNDmode,
+			       expand_normal (CALL_EXPR_ARG (exp, 1)));
+	  res = chkp_join_splitted_slot (res, bnd);
+	}
+      return res;
     }
 }
 
@@ -3294,10 +3371,23 @@ expand_builtin_mempcpy (tree exp, rtx target, machine_mode mode)
 
 static rtx
 expand_builtin_mempcpy_args (tree dest, tree src, tree len,
-			     rtx target, machine_mode mode, int endp)
+			     rtx target, machine_mode mode, int endp,
+			     tree orig_exp)
 {
+  tree fndecl = get_callee_fndecl (orig_exp);
+
     /* If return value is ignored, transform mempcpy into memcpy.  */
-  if (target == const0_rtx && builtin_decl_implicit_p (BUILT_IN_MEMCPY))
+  if (target == const0_rtx
+      && DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK_CHKP
+      && builtin_decl_implicit_p (BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK_CHKP))
+    {
+      tree fn = builtin_decl_implicit (BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK_CHKP);
+      tree result = build_call_nofold_loc (UNKNOWN_LOCATION, fn, 3,
+					   dest, src, len);
+      return expand_expr (result, target, mode, EXPAND_NORMAL);
+    }
+  else if (target == const0_rtx
+	   && builtin_decl_implicit_p (BUILT_IN_MEMCPY))
     {
       tree fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
       tree result = build_call_nofold_loc (UNKNOWN_LOCATION, fn, 3,
@@ -3482,7 +3572,8 @@ expand_builtin_stpcpy (tree exp, rtx target, machine_mode mode)
 
       lenp1 = size_binop_loc (loc, PLUS_EXPR, len, ssize_int (1));
       ret = expand_builtin_mempcpy_args (dst, src, lenp1,
- 					 target, mode, /*endp=*/2);
+					 target, mode, /*endp=*/2,
+					 exp);
 
       if (ret)
 	return ret;
@@ -3648,6 +3739,36 @@ expand_builtin_memset (tree exp, rtx target, machine_mode mode)
     }
 }
 
+/* Expand expression EXP, which is an instrumented call to the memset builtin.
+   Return NULL_RTX if we failed the caller should emit a normal call, otherwise
+   try to get the result in TARGET, if convenient (and in mode MODE if that's
+   convenient).  */
+
+static rtx
+expand_builtin_memset_with_bounds (tree exp, rtx target, machine_mode mode)
+{
+  if (!validate_arglist (exp,
+			 POINTER_TYPE, POINTER_BOUNDS_TYPE,
+			 INTEGER_TYPE, INTEGER_TYPE, VOID_TYPE))
+    return NULL_RTX;
+  else
+    {
+      tree dest = CALL_EXPR_ARG (exp, 0);
+      tree val = CALL_EXPR_ARG (exp, 2);
+      tree len = CALL_EXPR_ARG (exp, 3);
+      rtx res = expand_builtin_memset_args (dest, val, len, target, mode, exp);
+
+      /* Return src bounds with the result.  */
+      if (res)
+	{
+	  rtx bnd = force_reg (BNDmode,
+			       expand_normal (CALL_EXPR_ARG (exp, 1)));
+	  res = chkp_join_splitted_slot (res, bnd);
+	}
+      return res;
+    }
+}
+
 /* Helper function to do the actual work for expand_builtin_memset.  The
    arguments to the builtin_memset call DEST, VAL, and LEN are broken out
    so that this can also be called without constructing an actual CALL_EXPR.
@@ -3776,7 +3897,8 @@ expand_builtin_memset_args (tree dest, tree val, tree len,
  do_libcall:
   fndecl = get_callee_fndecl (orig_exp);
   fcode = DECL_FUNCTION_CODE (fndecl);
-  if (fcode == BUILT_IN_MEMSET)
+  if (fcode == BUILT_IN_MEMSET
+      || fcode == BUILT_IN_CHKP_MEMSET_NOBND_NOCHK_CHKP)
     fn = build_call_nofold_loc (EXPR_LOCATION (orig_exp), fndecl, 3,
 				dest, val, len);
   else if (fcode == BUILT_IN_BZERO)
@@ -5849,6 +5971,8 @@ expand_builtin (tree exp, rtx target, rtx subtarget, machine_mode mode,
 	}
     }
 
+  /* expand_builtin_with_bounds is supposed to be used for
+     instrumented builtin calls.  */
   gcc_assert (!CALL_WITH_BOUNDS_P (exp));
 
   switch (fcode)
@@ -6909,6 +7033,53 @@ expand_builtin (tree exp, rtx target, rtx subtarget, machine_mode mode,
   return expand_call (exp, target, ignore);
 }
 
+/* Similar to expand_builtin but is used for instrumented calls.  */
+
+rtx
+expand_builtin_with_bounds (tree exp, rtx target,
+			    rtx subtarget ATTRIBUTE_UNUSED,
+			    machine_mode mode, int ignore)
+{
+  tree fndecl = get_callee_fndecl (exp);
+  enum built_in_function fcode = DECL_FUNCTION_CODE (fndecl);
+
+  gcc_assert (CALL_WITH_BOUNDS_P (exp));
+
+  if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD)
+    return targetm.expand_builtin (exp, target, subtarget, mode, ignore);
+
+  gcc_assert (fcode > BEGIN_CHKP_BUILTINS
+	      && fcode < END_CHKP_BUILTINS);
+
+  switch (fcode)
+    {
+    case BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK_CHKP:
+      target = expand_builtin_memcpy_with_bounds (exp, target);
+      if (target)
+	return target;
+      break;
+
+    case BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK_CHKP:
+      target = expand_builtin_mempcpy_with_bounds (exp, target, mode);
+      if (target)
+	return target;
+      break;
+
+    case BUILT_IN_CHKP_MEMSET_NOBND_NOCHK_CHKP:
+      target = expand_builtin_memset_with_bounds (exp, target, mode);
+      if (target)
+	return target;
+      break;
+
+    default:
+      break;
+    }
+
+  /* The switch statement above can drop through to cause the function
+     to be called normally.  */
+  return expand_call (exp, target, ignore);
+ }
+
 /* Determine whether a tree node represents a call to a built-in
    function.  If the tree T is a call to a built-in function with
    the right number of arguments of the appropriate types, return
diff --git a/gcc/builtins.h b/gcc/builtins.h
index 7960b01..44bc5df 100644
--- a/gcc/builtins.h
+++ b/gcc/builtins.h
@@ -69,6 +69,7 @@ extern tree std_canonical_va_list_type (tree);
 extern void std_expand_builtin_va_start (tree, rtx);
 extern void expand_builtin_trap (void);
 extern rtx expand_builtin (tree, rtx, rtx, machine_mode, int);
+extern rtx expand_builtin_with_bounds (tree, rtx, rtx, machine_mode, int);
 extern enum built_in_function builtin_mathfn_code (const_tree);
 extern tree fold_builtin_expect (location_t, tree, tree, tree);
 extern tree fold_fma (location_t, tree, tree, tree, tree);
diff --git a/gcc/expr.c b/gcc/expr.c
index f824cef..2868f8c 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -10443,7 +10443,11 @@ expand_expr_real_1 (tree exp, rtx target, machine_mode tmode,
 	if (fndecl && DECL_BUILT_IN (fndecl))
 	  {
 	    gcc_assert (DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_FRONTEND);
-	    return expand_builtin (exp, target, subtarget, tmode, ignore);
+	    if (CALL_WITH_BOUNDS_P (exp))
+	      return expand_builtin_with_bounds (exp, target, subtarget,
+						 tmode, ignore);
+	    else
+	      return expand_builtin (exp, target, subtarget, tmode, ignore);
 	  }
       }
       return expand_call (exp, target, ignore);