[Bug libgcc/85388] config/i386/morestack.S is incompatible with CET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85388 --- Comment #2 from igor.v.tsimbalist at intel dot com --- You are fixing 64bit part. There is similar place for 32bit movl-8(%ebp),%eax # Restore the last register. call*-12(%ebp) # Call our caller! What do we call here? Is it returning back to a function that causes more stack allocation? Is it possible for the compiler to insert ENDBR there based on some knowledge of morestack was called?
[Bug target/85388] Missing ENDBR after __morestack call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85388 --- Comment #5 from igor.v.tsimbalist at intel dot com --- I think it's the right place.
[Bug target/81842] -fcf-protection -mcet is incompatible with makecontext family functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81842 --- Comment #14 from igor.v.tsimbalist at intel dot com --- The new option is needed to support two cases: 1. Compilation of ucontext functions inside glibc. To have glibc itself be CET compatible all files comprises the library has to be CET compatible. That meansthe module with ucontext functions from glibc has to be forced to be CET compatible. 2. Compilation of a user application with ucontext functions. In this case the error has to be issued, so no usage of a ucontext functions. Having just __SHSTK__ macro it's impossible to handle both cases. The case #1 will report an error during glibc compilation. A new macro is introduced to use in a source file to handle these cases. To control the value of the new macro a new option is introduced. Glibc sources will be compiled with -no-mcheck-shstk-compat.
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #1 from igor.v.tsimbalist at intel dot com --- The reason of this ICE is not in CET implementation itself, it's an induced error. The actual reason is in keeping isa bits. There are two different flags to keep ISA bits (for i386): x86_isa_flags and x86_isa_flags2. When introducing a new builtin definition with BDESC () ISA bits are given to tell when a usage of the builtin is valid. At this point there could be combination of ISA bits from different isa_flags set. That's exactly the case with rdssp builtin: it has bits OPTION_MASK_ISA_SHSTK | OPTION_MASK_ISA_64BIT specified. Later def_builtin or def_buildin2 is called that assume the 'mask' argument belong to one isa set flag. In this case def_buildin2 is called and it turned out OPTION_MASK_ISA_64BIT from x86_isa_flags maps to OPTION_MASK_ISA_AVX5124VNNIW from x86_isa_flags2. I assume it could be a potential error for other intrinsics. The best solution is to revisit a mechanism of processing and keeping ISA bits. The workaround is to remove OPTION_MASK_ISA_64BIT. All test are working, the correct intrinsic is selected (I think due to different intrinsic's name). Patch is attached. The patch has a fix for wrong setting of OPTION_MASK_ISA_AVX512F_SET for -mavx512vnni option, which has also effect on CET.
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #2 from igor.v.tsimbalist at intel dot com --- Created attachment 42930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42930&action=edit patch
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #6 from igor.v.tsimbalist at intel dot com --- I haven't look into all the cases but I think there are similar cases with OPTION_MASK_ISA_AVX512F and OPTION_MASK_ISA_AVX512VL.
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #10 from igor.v.tsimbalist at intel dot com --- The bit OPTION_MASK_ISA_AVX512VNNI may have OPTION_MASK_ISA_AVX512VL bit set also. But these bits are from different isa flags.
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #14 from igor.v.tsimbalist at intel dot com --- ok, maybe I was wrong. But my point is OPTION_MASK_ISA_AVX512VL may be used with new/future instructions likely. This bit is in isa_flags set, which is full now, so it will require reordering isa_flags and isa_flags2 each time when such combinations might appear in future.
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #15 from igor.v.tsimbalist at intel dot com --- (In reply to Jakub Jelinek from comment #13) > And, if we run out of easy move ideas, we could make a copy of the ISA_64BIT > so that we'd have it in both flag sets (and keep it synced) and move all > AVX512 related stuff to isa_flags2 and everything else to isa_flags. Good idea!
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #18 from igor.v.tsimbalist at intel dot com --- Added a patch for m512vnni, which is done similarly to 512vbmi2. It looks like most of avx512* bits have to be included in OPTION_MASK_ISA_AVX512F_UNSET. I leave it to a separate revision of mask bits. Doing building and testing.
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #19 from igor.v.tsimbalist at intel dot com --- Created attachment 42947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42947&action=edit 512VNNI patch
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #21 from igor.v.tsimbalist at intel dot com --- Maybe I did more than expected :). Actually 512VNNI has VL bit according to recently published extension. Please see https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf I can go with my initial patch where I correct just OPTION_MASK_ISA_AVX512F_SET and leave everything else to an owner of 512vnni implementation. Ok with that?
[Bug target/83488] [8 Regression] ICE on a CET test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83488 --- Comment #24 from igor.v.tsimbalist at intel dot com --- (In reply to Jakub Jelinek from comment #23) > (In reply to igor.v.tsimbalist from comment #21) > > Maybe I did more than expected :). Actually 512VNNI has VL bit according to > > recently published extension. Please see > > > > https://software.intel.com/sites/default/files/managed/c5/15/architecture- > > instruction-set-extensions-programming-reference.pdf > > Looking at the same paper, AVX512VPOPCNTDQ is also mixed with AVX512VL, > though the 128-bit and 256-bit intrinsics and builtins aren't in GCC yet, > but for > VNNI there already is avx512vnnivlintrin.h and thus > __builtin_ia32_vpdpbusd_v8si etc. can use | OPTION_MASK_ISA_AVX512VL after > your patch immediately. Agree. Specifying OPTION_MASK_ISA_AVX512VL has to be revised as well as extension of OPTION_MASK_ISA_AVX512F_UNSET.
[Bug target/83109] [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 --- Comment #1 from igor.v.tsimbalist at intel dot com --- It's fixed in revision r255164, http://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00881.html. The svn log is missing PR 83109 that's why the bug was not updated automatically.
[Bug target/83109] [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 igor.v.tsimbalist at intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from igor.v.tsimbalist at intel dot com --- Mark it as fixed.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 83109, which changed state. Bug 83109 Summary: [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/84066] Wrong shadow stack register size is saved for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066 --- Comment #1 from igor.v.tsimbalist at intel dot com --- Created attachment 43274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43274&action=edit x32 patch
[Bug target/84066] Wrong shadow stack register size is saved for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066 --- Comment #2 from igor.v.tsimbalist at intel dot com --- updated __builtin_setjmp and __builtin_longjmp to use 64bit instructions and registers. The patch is attached.
[Bug target/84066] Wrong shadow stack register size is saved for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066 --- Comment #4 from igor.v.tsimbalist at intel dot com --- Created attachment 43280 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43280&action=edit updated patch
[Bug target/84066] Wrong shadow stack register size is saved for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066 --- Comment #6 from igor.v.tsimbalist at intel dot com --- (In reply to H.J. Lu from comment #5) > (In reply to igor.v.tsimbalist from comment #4) > > Created attachment 43280 [details] > > updated patch > > - mem = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0], > -3 * GET_MODE_SIZE (Pmode))); > - reg_ssp = gen_reg_rtx (Pmode); > + mem = gen_rtx_MEM (word_mode, plus_constant (Pmode, operands[0], > + 3 * GET_MODE_SIZE (Pmode))); > > The first 3 fields are SP, FP and IP, which are in ptr_mode, not Pmode. ok. >/* Compute the numebr of frames to adjust. */ > + reg_adj = gen_rtx_SUBREG (Pmode, reg_ssp, 0); > > reg_ssp must be in word_mode, not in Pmode. reg_ssp is word_mode. It's reg_adj that is Pmode (it's increment to shadow stack). > Please show the assembly outputs of __builtin_setjmp and __builtin_longjmp > with the updated patch. A snippet for __builtin_longjmp for -mx32 movl$0, %eax rdsspq %rax subqbuf+12(%rip), %rax je .L2 negl%eax shrl$2, %eax cmpl$255, %eax jbe .L3 .L4: incsspq %rax subl$255, %eax cmpl$255, %eax ja .L4 .L3: incsspq %rax .L2: Snippet for __builtin_setjmp for -mx32 movl%eax, buf(%rip) movl$.L8, buf+4(%rip) movl%esp, buf+8(%rip) movl$0, %eax rdsspq %rax movq%rax, buf+12(%rip)
[Bug target/84145] New: Wrong CET options processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145
Bug ID: 84145
Summary: Wrong CET options processing
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: igor.v.tsimbalist at intel dot com
Target Milestone: ---
The gcc error message for not passing -mibt/-mshstk with -fcf-protection seems
confusing. It looks like it just checks that one of the options is present and
doesn’t check that it’s the option that is required by the protection
requested. So it's possible to do -fcf-protection=branch -mshstk and not get an
error, but not get any protection either.
Here is this part:
if (!(TARGET_IBT_P (opts->x_ix86_isa_flags2)
|| TARGET_SHSTK_P (opts->x_ix86_isa_flags)))
{
if (flag_cf_protection == CF_FULL)
{
error ("%<-fcf-protection=full%> requires CET support "
"on this target. Use -mcet or one of -mibt, "
"-mshstk options to enable CET");
}
else if (flag_cf_protection == CF_BRANCH)
{
error ("%<-fcf-protection=branch%> requires CET support "
"on this target. Use -mcet or one of -mibt, "
"-mshstk options to enable CET");
}
else if (flag_cf_protection == CF_RETURN)
{
error ("%<-fcf-protection=return%> requires CET support "
"on this target. Use -mcet or one of -mibt, "
"-mshstk options to enable CET");
}
flag_cf_protection = CF_NONE;
return false;
}
[Bug target/84145] Wrong CET options processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145 --- Comment #2 from igor.v.tsimbalist at intel dot com --- Created attachment 43343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43343&action=edit proposed patch
[Bug target/84239] New: Reimplement rdssp[d|q] and incssp[d|q] CET intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84239 Bug ID: 84239 Summary: Reimplement rdssp[d|q] and incssp[d|q] CET intrinsics Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: igor.v.tsimbalist at intel dot com Target Milestone: --- There was an online discussion related to syncing CET intrinsic names between 3 compilers, gcc, llvm and icc. The intrinsics in question were rdssp[d|q] and incssp[d|q]. It was agreed that: * new utility intrinsics should be introduced: #ifdef _x86_64_ __int64 _get_ssp(void); #else __int32 _get_ssp(void); #endif void _inc_ssp(unsigned int); * it's up to a compiler to provide the initial intrinsics, which maps 1:1 to the instruction. * GCC compiler is going to provide utility intrinsics only. The current intrinsic implementation for rdssp[d|q] and incssp[d|q] has to updated to reflect the decision.
[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243 --- Comment #1 from igor.v.tsimbalist at intel dot com --- Hi, I do not have 'none-linux' platform at hand. Could you please show the output for the failing tests? Thanks, Igor > -Original Message- > From: jgreenhalgh at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] > Sent: Tuesday, February 6, 2018 5:58 PM > To: itsim...@gcc.gnu.org > Subject: [Bug testsuite/84243] New: [8 Regression] gcc.target/i386/cet-intrin- > 4.c at r257414 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243 > > Bug ID: 84243 >Summary: [8 Regression] gcc.target/i386/cet-intrin-4.c at > r257414 >Product: gcc >Version: 8.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: testsuite > Assignee: unassigned at gcc dot gnu.org > Reporter: jgreenhalgh at gcc dot gnu.org > CC: itsimbal at gcc dot gnu.org > Target Milestone: --- > Target: x86-64-none-linux-gnu, aarch64-none-linux-gnu > > Hi, our bisect robot spotted a failure in gcc.target/i386/cet-intrin-3.c, > gcc.target/i386/cet-intrin-4.c, after revision r257414 on > x86-64-none-linux-gnu, and c-c++-common/fcf-protection-6.c and > c-c++-common/fcf-protection-7.c on aarch64-none-linux.gnu. Would you > mind > taking a look? > > Your new tests will always FAIL on non-x86 targets (for example > aarch64-none-linux-gnu). Is dg-error really the right directive, that is a > guaranteed FAIL, I would expect a skip. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243 igor.v.tsimbalist at intel dot com changed: What|Removed |Added CC||igor.v.tsimbalist at intel dot com --- Comment #7 from igor.v.tsimbalist at intel dot com --- (In reply to Rainer Orth from comment #6) > Patch for the fcf-protection-[67].c failures posted: > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00285.html > > Btw., I'm seeing the cet-intrin-[34].c ICEs too on i386-pc-solaris2.11. The > two > failures are completely different, probably belong into a different PR. Is the ICE you see the same as specified in Comment 2? If yes then this is covered by 84248. Patch for this issue has been posted.
[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243 --- Comment #10 from igor.v.tsimbalist at intel dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > > --- Comment #7 from igor.v.tsimbalist at intel dot com --- > [...] > >> Btw., I'm seeing the cet-intrin-[34].c ICEs too on i386-pc-solaris2.11. > >> The > >> two > >> failures are completely different, probably belong into a different PR. > > > > Is the ICE you see the same as specified in Comment 2? If yes then this is > > covered by 84248. Patch for this issue has been posted. > > It is indeed. Sorry for overlooking this: to many failures cooking at > once ;-) > > With my patch above, this leaves us with the cet-intrin-4.c failure: > just replace -mshstk with -mcet? No. Your patch should not have effect on cet-intrin-[34].c fails. Fail in these tests has different reason (PR 84248).
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #4 from igor.v.tsimbalist at intel dot com --- Created attachment 43400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43400&action=edit patch
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #5 from igor.v.tsimbalist at intel dot com --- Beside the patch configure files have to be regenerated.
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #7 from igor.v.tsimbalist at intel dot com --- (In reply to H.J. Lu from comment #6) > (In reply to igor.v.tsimbalist from comment #4) > > Created attachment 43400 [details] > > patch > > 2 questions: > > 1. Should 32-bit multilib target libraries compiled on 64-bit host > enable CET? > 2. Should 64-bit multilib target libraries compiled with 32-bit compiler > enable CET? Is there a configuration variable holding an indication of bit-ness for which the compilation of a library is done? I see there is some code in configure.ac in libgcc evaluating the host_address (32 or 64 bits) # Check 32bit or 64bit. In the case of MIPS, this really determines the # word size rather than the address size. cat > conftest.c <
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148
--- Comment #9 from igor.v.tsimbalist at intel dot com ---
How can I check the fixes w/o old HW? I tried specifying --target=pentium to
configure but the build has failed with the message
*** Configuration i586-pc-none not supported
make[1]: *** [configure-gcc] Error 1
make[1]: Leaving directory `/export/users/itsimbal/gcc_ws/build.cet'
make: *** [all] Error 2
Igor
> -Original Message-
> From: hjl.tools at gmail dot com [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: Tuesday, February 13, 2018 2:12 PM
> To: Tsimbalist, Igor V
> Subject: [Bug target/84148] CET shouldn't be enabled in 32-bit run-time
> libraries by default
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148
>
> --- Comment #8 from H.J. Lu ---
> (In reply to igor.v.tsimbalist from comment #7)
> > (In reply to H.J. Lu from comment #6)
> > > (In reply to igor.v.tsimbalist from comment #4)
> > > > Created attachment 43400 [details]
> > > > patch
> > >
> > > 2 questions:
> > >
> > > 1. Should 32-bit multilib target libraries compiled on 64-bit host
> > > enable CET?
> > > 2. Should 64-bit multilib target libraries compiled with 32-bit compiler
> > > enable CET?
> >
> > Is there a configuration variable holding an indication of bit-ness for
> > which the compilation of a library is done? I see there is some code in
> > configure.ac in libgcc evaluating the host_address (32 or 64 bits)
> >
> > # Check 32bit or 64bit. In the case of MIPS, this really determines the
> > # word size rather than the address size.
> > cat > conftest.c < > #if defined(__x86_64__) || (!defined(__i386__) && defined(__LP64__)) \
> > || defined(__mips64)
> > host_address=64
> > #else
> > host_address=32
> > #endif
> > EOF
> > eval `${CC-cc} -E conftest.c | grep host_address=`
> > rm -f conftest.c
> >
> > If I use the 'host_address' in cet.m4 I got the expected results for libgcc:
> > by default 64-bit library is CET enabled, 32-bit library is not.
>
> That would be wrong for x32. We need to enable CET for x86-64
> by default, regardless address size. To enable CET, we only
> need to check if __SSE2__ is defined since all SSE2 processors
> support multi-byte NOPs.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #11 from igor.v.tsimbalist at intel dot com --- Created attachment 43408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43408&action=edit patch #2
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #12 from igor.v.tsimbalist at intel dot com --- (In reply to H.J. Lu from comment #10) > (In reply to igor.v.tsimbalist from comment #9) > > How can I check the fixes w/o old HW? I tried specifying --target=pentium to > > configure but the build has failed with the message > > > > *** Configuration i586-pc-none not supported > > make[1]: *** [configure-gcc] Error 1 > > make[1]: Leaving directory `/export/users/itsimbal/gcc_ws/build.cet' > > make: *** [all] Error 2 > > To specify the default -march= for 32-bit target libraries, for 32-bit > GCC, use --with-arch=cpu, for 64-bit GCC, use --with-arch_32=cpu to > configure GCC. Thanks! This works as expected. New patch is attached.
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #14 from igor.v.tsimbalist at intel dot com --- Created attachment 43410 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43410&action=edit patch #3 The simplified patch.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 84239, which changed state. Bug 84239 Summary: Reimplement rdssp[d|q] and incssp[d|q] CET intrinsics https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84239 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/84239] Reimplement rdssp[d|q] and incssp[d|q] CET intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84239 igor.v.tsimbalist at intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from igor.v.tsimbalist at intel dot com --- Fixed.
[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 --- Comment #5 from igor.v.tsimbalist at intel dot com --- Created attachment 42658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42658&action=edit patch
[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 --- Comment #6 from igor.v.tsimbalist at intel dot com --- Andreas has sent this issue as a reply to my commit. I proposed a fix and asked for approval. Here is my reply https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01647.html I have attached the patch also.
[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 --- Comment #9 from igor.v.tsimbalist at intel dot com --- I do not have an ia64 system at hand to reproduce. Could you please send me the log file or at least the part with error? Is the error still the same or is it different error? Or could you please update the bug with how it fails now? Igor > -Original Message- > From: sch...@linux-m68k.org [mailto:gcc-bugzi...@gcc.gnu.org] > Sent: Tuesday, November 21, 2017 10:24 AM > To: Tsimbalist, Igor V > Subject: [Bug bootstrap/83015] [8 regression] bootstrap comparison failure > on ia64 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 > > Andreas Schwab changed: > >What|Removed |Added > > Status|WAITING |NEW > > --- Comment #8 from Andreas Schwab --- > Still broken. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087 igor.v.tsimbalist at intel dot com changed: What|Removed |Added CC||igor.v.tsimbalist at intel dot com --- Comment #2 from igor.v.tsimbalist at intel dot com --- It's controlled by --enable-cet configuration flag.
[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087 --- Comment #4 from igor.v.tsimbalist at intel dot com --- Yes, that's true. It was done deliberately so the libraries get ready for Intel CET, it was reflected in commit message and changelog. The binaries compiled with CET will continue to work on HW without CET support. Why it should not be enabled by default?
[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087 --- Comment #7 from igor.v.tsimbalist at intel dot com --- (In reply to Jakub Jelinek from comment #5) > My understanding has been that the CET stuff is essentially ABI incompatible > (CET enabled libraries/binaries vs. non-CET enabled ones) on CET HW, so it > should be better treated like a multilib. > So, unless everything on the system is CET enabled, putting the CET support > in is just waste of I-cache. It's completely ABI compatible. ABI has not changed. You can mix object files. But it's true that an app is CET enabled if all object files and libraries linked in the app are CET enabled. Code size should increased insignificantly, I do not have numbers right away. I can collect it for the target libraries and post it here.
[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087 --- Comment #9 from igor.v.tsimbalist at intel dot com --- Yes, there is "magic" and HJ is implementing this interface. Please see his answer for the similar question: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00693.html
[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087 --- Comment #11 from igor.v.tsimbalist at intel dot com --- So the increase compared to object file size is negligible. Increase of a text segment is ~1.4%.
[Bug target/83109] New: [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 Bug ID: 83109 Summary: [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: igor.v.tsimbalist at intel dot com Target Milestone: --- As inssp instruction adust the shadow stack pointer (ssp) only by value in the range of [0..255] there should be a loop generated to adjust ssp if the value greater then 255. Currently builtin_longjmp does one time adjustment with incssp.
