This patch set adds CET host support to libcc1 by enabling CET host
support in gcc, libcpp, libdecnumber and libbacktrace.
OK for master?
H.J. Lu (5):
libcc1: Enable Intel CET on Intel CET enabled host
gcc: Enable Intel CET on Intel CET enabled host for jit
libcpp: Enable Intel CET on
On Fri, May 8, 2020 at 2:50 PM Iain Buclaw wrote:
>
> On 08/05/2020 22:10, H.J. Lu wrote:
> > This patch set adds CET support to libphobos. Since libphobos uses zlib
> > target library, CET is also enabled in zlib.
> >
> > OK for master?
> >
>
> I have no problem with the libphobos parts.
>
When --enable-cet is used to configure GCC, enable Intel CET in libphobos.
* Makefile.am (AM_MAKEFLAGS): Add $(CET_FLAGS) to GCC FLAGS.
* configure.ac (CET_FLAGS): Add GCC_CET_FLAGS and AC_SUBST.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
*
This patch set adds CET support to libphobos. Since libphobos uses zlib
target library, CET is also enabled in zlib.
OK for master?
Thanks.
H.J. Lu (3):
zlib: Add --enable-cet to configure
libphobos: Add --enable-cet to configure
switchcontext.S: Include and use _CET_ENDBR
When --enable-cet is used to configure GCC, enable Intel CET in target
zlib.
* Makefile.am (AM_CFLAGS): New.
* configure.ac (CET_FLAGS): Add GCC_CET_FLAGS and AC_SUBST.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure.ac: Likewise.
---
When __CET__ is defined, should be included to add Intel CET
marker to object file and _CET_ENDBR should be placed at function entry
to indicate indirect branch target.
* libdruntime/config/x86/switchcontext.S: Include if
__CET__ is defined.
(_CET_ENDBR): New. Define if
Since libgccjit.so is linked into jit tests, skip jit tests for targets
that don't support -lgccjit.
OK for master?
H.J.
---
PR jit/94778
* jit.dg/jit.exp: Skip jit tests for targets that don't support
-lgccjit.
* lib/target-supports.exp
CET has been added since GCC 8. This patch defaults CET run-time support
to auto. It enables CET run-time support if asssembler supports CET
instructions and multi-byte NOPs are enabled via SSE2.
OK for master?
Thanks.
H.J.
---
config/
* cet.m4 (GCC_CET_FLAGS): Change default to
Don't perform CET run-time check for host when cross compiling. Instead,
enable CET in cross compiler if possible so that it will run on both CET
and non-CET hosts.
config/
PR bootstrap/94998
* cet.m4 (GCC_CET_HOST_FLAGS): Enable CET in cross compiler if
possible.
On Wed, May 6, 2020 at 6:26 AM Richard Biener wrote:
>
> On Tue, 5 May 2020, Richard Biener wrote:
>
> >
> > This rewrites store-motion to process candidates where we can
> > ensure order preserving separately and with no need to disambiguate
> > against all stores. Those candidates we cannot
On Wed, May 6, 2020 at 2:39 AM Jonathan Wakely via Gcc-patches
wrote:
>
> On 06/05/20 10:15 +0100, Jonathan Wakely wrote:
> >On 06/05/20 11:09 +0200, Jakub Jelinek via Libstdc++ wrote:
> >>On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> >>>I just remembered that the libstdc++ ABI
On Tue, May 5, 2020 at 12:27 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The popcount* testcases show yet another creative way to write popcount,
> but rather than adjusting the popcount matcher to deal with it, I think
> we just should canonicalize those (X + (X << C) to X * (1 + (1 <<
On Mon, May 4, 2020 at 12:48 PM Kees Cook wrote:
>
> On Mon, May 04, 2020 at 12:02:45PM -0700, H.J. Lu wrote:
> > On Mon, May 4, 2020 at 11:21 AM Kees Cook wrote:
> > >
> > > On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote:
> > > > Hi,
> > > >
> > > > This is a PING for this patch for
On Mon, May 4, 2020 at 11:21 AM Kees Cook wrote:
>
> On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote:
> > Hi,
> >
> > This is a PING for this patch for gcc11 stage 1.
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html
> >
my_exception_matcher must return int. Otherwise, this test fails.
PR testsuite/84324
* objc/execute/exceptions/matcher-1.m (my_exception_matcher):
Change return type to int.
---
gcc/testsuite/objc/execute/exceptions/matcher-1.m | 2 +-
1 file changed, 1 insertion(+), 1
---
gcc/testsuite/gcc.target/i386/ret-thunk-22.c | 2 +-
gcc/testsuite/gcc.target/i386/ret-thunk-23.c | 2 +-
gcc/testsuite/gcc.target/i386/ret-thunk-24.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/ret-thunk-22.c
Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all] command-line
option and zero_caller_saved_regs("skip|used|all") function attribue:
1. -mzero-caller-saved-regs=skip and zero_caller_saved_regs("skip")
Don't zero caller-saved registers upon function return.
2.
Add ix86_any_return_p to check simple_return in a PARALLEL to support:
(jump_insn 39 38 40 5 (parallel [
(simple_return)
(unspec [
(const_int 0 [0])
] UNSPEC_SIMPLE_RETURN)
]) "/tmp/x.c":105 -1
(nil)
-> simple_return)
On Fri, May 1, 2020 at 6:04 AM Thomas Koenig via Gcc-patches
wrote:
>
> Hello world,
>
> because the test case for PR 94788 requires -fsanitize=address to expose
> the double free, I have created a subdirectory under gfortran.dg
> where such test cases can go.
>
> I have tested this with
>
> make
Currently patchable area is at the wrong place. It is placed immediately
after function label, before both .cfi_startproc and ENDBR. This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
changes ENDBR insertion pass to also insert patchable area instruction.
On Thu, Feb 6, 2020 at 12:01 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Wed, Feb 5, 2020 at 2:51 PM H.J. Lu wrote:
> >>
> >> On Wed, Feb 5, 2020 at 2:37 PM Marek Polacek wrote:
> >> >
> >> > On Wed, Feb 05, 2020 at 02:24:48PM -0800, H.J. Lu wrote:
> >> > > On Wed, Feb 5, 2020 at
On Wed, Apr 29, 2020 at 5:02 AM H.J. Lu wrote:
>
> On Tue, Apr 28, 2020 at 11:38 PM Richard Biener
> wrote:
> >
> > On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > Allow -fcf-protection with external thunk since th
On Tue, Apr 28, 2020 at 11:38 PM Richard Biener
wrote:
>
> On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > Allow -fcf-protection with external thunk since the external thunk can be
> > made compatible with -fcf-protection.
> >
> >
Allow -fcf-protection with external thunk since the external thunk can be
made compatible with -fcf-protection.
OK for master?
Thanks.
H.J.
---
gcc/
PR target/93654
* config/i386/i386-options.c (ix86_set_indirect_branch_type):
Allow -fcf-protection with
GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host
has Intel CET enabled by introducing an Intel CET violation on purpose.
To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first.
-fcf-protection=none is added to avoid false negative when -fcf-protection
is
On Sat, Apr 25, 2020 at 9:29 AM Richard Biener wrote:
>
> On April 24, 2020 9:31:58 PM GMT+02:00, "H.J. Lu" wrote:
> >Since ld is Intel CET enabled on Intel CET enabled host, dlopen fails
> >on
> >liblto_plugin.so if it isn't Intel CET enabled. Add GCC_CET_HOST_FLAGS
> >to cet.m4, use it in
Since ld is Intel CET enabled on Intel CET enabled host, dlopen fails on
liblto_plugin.so if it isn't Intel CET enabled. Add GCC_CET_HOST_FLAGS
to cet.m4, use it in libiberty and lto-plugin to always enable Intel
CET in liblto_plugin.so on Intel CET enabled host.
On Linux/x86 host, enable Intel
On Wed, Apr 8, 2020 at 9:41 AM Jeff Law wrote:
>
> On Wed, 2020-04-08 at 09:23 -0700, H.J. Lu wrote:
> > On Wed, Apr 8, 2020 at 9:16 AM Jeff Law wrote:
> > > On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > > Since constant_call_address_op
We must restore the frame pointer in word_mode for eh_return epilogues
since the upper 32 bits of RBP register can have any values.
Tested on Linux/x32 and Linux/x86-64. OK for master and backport to
GCC 8/9 branches?
Thanks.
H.J.
---
PR target/94556
* config/i386/i386.c
Even though ix86_hard_regno_mode_ok doesn't allow xmm16-xmm31 nor
ymm16-ymm31 in 128/256 bit modes when AVX512VL is disabled, reload
can still generate reg to reg moves with xmm16-xmm31 and ymm16-ymm31
in 128/256 bit modes. Remove mode size check in ix86_get_ssemov.
gcc/
PR target/94561
On Wed, Apr 8, 2020 at 12:55 AM Tobias Burnus wrote:
>
> I have now committed this patch
> as r10-7614-g13e41d8b9d3d7598c72c38acc86a3d97046c8373,
On Linux/x86, I got
FAIL: g++.dg/declare-pr94120.C -std=c++14 (test for excess errors)
FAIL: g++.dg/declare-pr94120.C -std=c++17 (test for excess
On Wed, Apr 8, 2020 at 9:16 AM Jeff Law wrote:
>
> On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > Since constant_call_address_operand has
> >
> > ;; Test for a pc-relative call operand
> > (define_predicate "constant_call_address_ope
On Sat, Apr 4, 2020 at 1:28 PM Eric Botcazou wrote:
>
> > Hmmm, sorry about that. Which target? x86_64? It does seem that
> > glibc consolidated mmap implementations in 2.26, but even in 2.22 I
> > see definitions for __mmap.
>
commit fa872e1b6210e81e60d6029429f0a083b8eab26e
Author:
On Sat, Apr 4, 2020 at 5:40 AM Eric Botcazou wrote:
>
> > gcc/ChangeLog:
> >
> > 2020-04-04 Jan Hubicka
> >
> > PR ipa/93940
> > * ipa-fnsummary.c (vrp_will_run_p): New function.
> > (fre_will_run_p): New function.
> > (evaluate_properties_for_edge): Use it.
> > *
commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979
Author: H.J. Lu
Date: Wed May 15 15:26:19 2019 +
i386: Emulate MMX pshufb with SSE version
has
+(define_insn_and_split "ssse3_pshufbv8qi3"
+ [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
+ (unspec:V8QI [(match_operand:V8QI
On Thu, Apr 2, 2020 at 3:43 AM Kewen.Lin wrote:
>
> on 2020/4/2 上午6:51, H.J. Lu wrote:
> >
> > This caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
> >
>
> Thanks for reporting this. The attached patch is to fix the stupid
> mistake by using gsi_insert_seq_before instead of
On Mon, Mar 30, 2020 at 4:09 AM Richard Biener via Gcc-patches
wrote:
>
> On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin wrote:
> >
> > Hi,
> >
> > As PR94043 shows, my commit r10-4524 exposed one issue in
> > vectorizable_live_operation, which inserts one extra BB
> > before the single exit,
On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
wrote:
>
> Please find attached a patch to fix test case failures of pr93365.f90,
> pr93600_1.f90 and pr93600_2.f90.
>
> OK to commit?
>
> gcc/fortran/ChangeLog:
>
> Mark Eggleston
>
> PR fortran/04386
^^^
Since constant_call_address_operand has
;; Test for a pc-relative call operand
(define_predicate "constant_call_address_operand"
(match_code "symbol_ref")
{
if (ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC
|| flag_force_indirect_call)
return false;
if
On Sun, Mar 29, 2020 at 5:25 AM H.J. Lu wrote:
>
> On Thu, Mar 26, 2020 at 4:38 AM Tobias Burnus wrote:
> >
> > Dear Paul,
> >
> > OK – thanks for the patch.
> >
> > Tobias
> >
> > PS: I assume that the spacing issue in the patch
> > is due to the mail program.
> >
> > On 3/26/20 12:20 PM, Paul
On Thu, Mar 26, 2020 at 4:38 AM Tobias Burnus wrote:
>
> Dear Paul,
>
> OK – thanks for the patch.
>
> Tobias
>
> PS: I assume that the spacing issue in the patch
> is due to the mail program.
>
> On 3/26/20 12:20 PM, Paul Richard Thomas via Fortran wrote:
>
> > This turned out to be relatively
Change -falign-functions=N to
Align the start of functions to the next power-of-two greater than
or equal to N.
Add
If '-falign-labels' is greater than this value, then its value is
used instead.
to -falign-loops=N and -falign-jumps=N.
OK for master?
H.J.
--
PR
On Mon, Mar 23, 2020 at 10:17 AM Martin Liška wrote:
>
> On 3/23/20 5:06 PM, H.J. Lu wrote:
> > #if __has_include ()
> > ...
> > #ifdef __BYTE_ORDER
> > #if __BYTE_ORDER == __BIG_ENDIAN
> > ...
> >
> > We support V2 interface only if defines __BYTE_ORDER?
>
> Right now we rely on __BIG_ENDIAN__
On Mon, Mar 23, 2020 at 8:39 AM Richard Biener
wrote:
>
> On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
> >
> > Hi.
> >
> > There's a patch draft that will do the proper versioning of API.
>
> Would sth like this be preferred on the binutils side or would
> splitting up the 'def' field via
DW_CIE_VERSION is unused by GCC and has been removed from binutils by
commit 66f8b2cbbb675ccbcae56e2bdb6dae485878ec00
Author: Andrew Burgess
Date: Mon Nov 4 12:27:45 2019 +
gas: Add --gdwarf-cie-version command line flag
* dwarf2.h (DW_CIE_VERSION): Delete.
---
On Thu, Mar 19, 2020 at 12:56 PM Richard Biener
wrote:
>
> On March 19, 2020 5:51:14 PM GMT+01:00, "H.J. Lu" wrote:
> >On Thu, Mar 19, 2020 at 9:00 AM Martin Liška wrote:
> >>
> >> On 3/19/20 4:50 PM, H.J. Lu wrote:
> >> > I like it and I will take case of binutils side.
> >> >
> >> > Thanks.
>
On Thu, Mar 19, 2020 at 9:00 AM Martin Liška wrote:
>
> On 3/19/20 4:50 PM, H.J. Lu wrote:
> > I like it and I will take case of binutils side.
> >
> > Thanks.
>
> Great. I've just installed the 2 patches to master.
>
Here is the binutils patch:
On Thu, Mar 19, 2020 at 8:46 AM Richard Biener
wrote:
>
> On Thu, Mar 19, 2020 at 4:00 PM Martin Liška wrote:
> >
> > On 3/19/20 10:12 AM, Richard Biener wrote:
> > > On Wed, Mar 18, 2020 at 9:52 AM Martin Liška wrote:
> > >>
> > >> On 3/18/20 12:27 AM, Jan Hubicka wrote:
> > Hi.
> >
On Thu, Mar 19, 2020 at 4:10 AM Richard Sandiford
wrote:
>
> In this PR we had a 512-bit VECTOR_TYPE whose mode is XImode
> (an integer mode used for four 128-bit vectors). When trying
> to expand a zero constant for it, we hit code in expand_expr_real_1
> that tries to use the associated
On Mon, Mar 16, 2020 at 6:50 AM Martin Liška wrote:
>
> On 3/16/20 12:12 PM, H.J. Lu wrote:
> > (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V and
> > ^^^ Typo,
>
> Thank you. I fixed that in my development branch.
Still not right. It should
On Thu, Mar 12, 2020 at 7:54 AM Martin Liška wrote:
>
> Hi.
>
> There's updated version of the patch.
> Changes from the previous version:
> - comment added to ld_plugin_symbol
> - new section renamed to ext_symtab
> - assert added for loop iterations in produce_symtab and
>
On Wed, Mar 11, 2020 at 8:53 PM Jeff Law wrote:
>
> On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> > There is no need to set mode attribute to XImode since ix86_output_ssemov
> > can properly encode xmm16-xmm31 registers with and without AVX512VL.
> >
> > Remove ext_sse_reg_operand since it
On Wed, Mar 11, 2020 at 6:09 AM Martin Liška wrote:
>
> On 3/11/20 1:51 PM, Richard Biener wrote:
> > I'm not sure I understand the versioning, we should aim at something where
> > an updated plugin can talk to old and new ld and where a new ld can also
> > talk
> > to an old plugin. That
1201 - 1253 of 1253 matches
Mail list logo
