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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84239
igor.v.tsimbalist at intel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
--
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.
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
>
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
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
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:
>
>
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.
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
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-in
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
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: jgreen
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
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
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
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
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
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109
igor.v.tsimbalist at intel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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.
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 acc
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
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
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
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 kee
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
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.
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.
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
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
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
: 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
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%.
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
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 on
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
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
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
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
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
44 matches
Mail list logo
