I realized that
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-regs-o
Move OPTION_MASK_* to i386-common.h so that they can be used in x86
backend.
* common/config/i386/i386-common.c (OPTION_MASK_*): Move to ...
* common/config/i386/i386-common.h: Here. New file.
* config/i386/i386.h: Include common/config/i386/i386-common.h.
---
On Tue, Apr 13, 2021 at 8:51 AM Martin Sebor wrote:
>
> On 4/12/21 7:03 PM, H.J. Lu wrote:
> > On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor wrote:
> >>
> >> On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
> >>> On Mon, Apr 12, 2021 at 2:21 AM Richard
On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor wrote:
>
> On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
> > On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
> > wrote:
> >>
> >> On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
> >> wrote:
On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
wrote:
>
> On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Add inline_ignore_target function attribute to inform the compiler that
> > target specific option mismatch on functions with the alwa
On Mon, Apr 12, 2021 at 5:54 AM Martin Liška wrote:
>
> On 4/12/21 2:18 PM, Jakub Jelinek wrote:
> > On Mon, Apr 12, 2021 at 02:15:16PM +0200, Martin Liška wrote:
> >> The old syntax with the alias is quite ugly..
> >
> > Not that much. And users have no other option (besides inline asm
> > but
Add inline_ignore_target function attribute to inform the compiler that
target specific option mismatch on functions with the always_inline
attribute may be ignored. On x86 targets, this attribute can be used on
integer functions to ignore target non-integer option mismatch.
gcc/c-family/
On Sun, Feb 23, 2020 at 10:32 PM Prathamesh Kulkarni
wrote:
>
> On Wed, 19 Feb 2020 at 19:54, Richard Biener
> wrote:
> > > >
> > > > OK with those changes. Did you try if the diagnostics are visible
> > > > (when you add -Wl,-debug or/and -Wl,-v to the link command?)
> > > Made the changes
are macros. And, for those that are inline functions, a lot
> > of them will be rejected if an immediate argument doesn't have a constant
> > value.
>
> LGTM for the patch.
>
> Thanks,
> Uros.
Here is another one. OK for master?
Thanks.
--
H.J.
From 3b9fce8c045f9
On Tue, Apr 6, 2021 at 2:51 AM Jan Hubicka wrote:
>
> > > Do you know what of the three changes (preferring reps/stosb,
> > > CLEAR_RATIO and algorithm choice changes) cause the two speedups
> > > on eebmc?
> >
> > A extracted testcase from nnet_test in https://godbolt.org/z/c8KdsohTP
> >
> >
On Mon, Apr 5, 2021 at 2:14 PM Jan Hubicka wrote:
>
> > > /* skylake_cost should produce code tuned for Skylake familly of CPUs.
> > > */
> > > static stringop_algs skylake_memcpy[2] = {
> > > - {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > > - {libcall, {{16,
On Mon, Mar 22, 2021 at 6:16 AM H.J. Lu wrote:
>
> Simply memcpy and memset inline strategies to avoid branches for
> Skylake family CPUs:
>
> 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
>load and store for up to 16 * 16 (256) bytes when the data
On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote:
>
> > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> > >
> > > Since uiret should be used only for user interrupt handler return, don't
> > > generate uiret in interrupt handler return with -mcmodel=k
Since uiret should be used only for user interrupt handler return, don't
generate uiret in interrupt handler return with -mcmodel=kernel even if
UINTR is enabled.
gcc/
PR target/99870
* config/i386/i386.md (interrupt_return): Don't generate uiret
for -mcmodel=kernel.
On Wed, Mar 31, 2021 at 11:21 AM Jan Hubicka wrote:
>
> > On Linux/x86_64,
> >
> > d7145b4bb6c8729a1e782373cb6256c06ed60465 is the first bad commit
> > commit d7145b4bb6c8729a1e782373cb6256c06ed60465
> > Author: Jan Hubicka
> > Date: Wed Mar 31 11:35:29 2021 +0200
> >
> > Small refactoring
On Wed, Mar 31, 2021 at 10:43 AM Jan Hubicka wrote:
>
> > > Reading through the optimization manual it seems that mosvb is fast for
> > > small block no matter if the size is hard wired. In that case you
> > > probably want to check whetehr max_size or expected_size is known to be
> > > small
On Wed, Mar 31, 2021 at 6:47 AM Jan Hubicka wrote:
>
> > > >
> > > > Patch is OK now. I was wondering about using avx256 for moves of known
> > >
> > > Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> > > you take a look at the patch for Skylake:
> > >
> > >
On Wed, Mar 31, 2021 at 1:05 AM Jan Hubicka wrote:
>
> > > It looks like X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is quite obviously
> > > benefical and independent of the rest of changes. I think we will need
> > > to discuss bit more the move ratio and the code size/uop cache polution
> > >
On Mon, Mar 22, 2021 at 4:57 PM H.J. Lu wrote:
>
> On Mon, Mar 22, 2021 at 7:10 AM Jan Hubicka wrote:
> >
> > >
> > > gcc/
> > >
> > > * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
> > > For TARGET_PREFER_KNOWN_RE
rote:
> > > >
> > > > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > > > > How can we move forward with it? I'd like to resolve it in GCC 11.
> > > >
> > > > I think it is too late for GCC 11 for
On Thu, Mar 25, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote:
> > I think the "proper" way to do this is to have 'open' above end up
> > refering to the out-of-line 'open' in the DSO, _not_ to emit the
> > fortification
On Thu, Mar 25, 2021 at 6:13 AM Jakub Jelinek wrote:
>
> On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote:
> > > Aren't *intrin.h system headers too?
> >
> > I was under impression that they are not, since they live outside of
> > /usr/include.
>
> Yes, they aren't in /usr/include, but
For always_inline in system headers, we don't know if caller's ISAs are
compatible with callee's ISAs until much later. Skip ISA check for
always_inline in system headers if caller has target attribute.
gcc/
PR target/98209
PR target/99744
* config/i386/i386.c
Check if host supports multi-byte NOPs before enabling CET on host.
gcc/
PR bootstrap/99703
* configure: Regenerated.
libbacktrace/
PR bootstrap/99703
* configure: Regenerated.
libcc1/
PR bootstrap/99703
* configure: Regenerated.
libcpp/
Check if host supports multi-byte NOPs before enabling CET on host.
config/
PR binutils/27397
* cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
NOPs.
libiberty/
PR binutils/27397
* configure: Regenerated.
---
config/cet.m4 | 19
Check if host supports multi-byte NOPs before enabling CET on host.
This fixes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703
H.J. Lu (2):
GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
config/cet.m4 | 19
t;
> expected_size is not -1 if we have profile feedback and we detected from
> histogram average size of a block. It seems to me that from description
> that you want the const to be actual compile time constant that would be
> min_size == max_size I guess.
>
You are right. Here is the
On Mon, Mar 22, 2021 at 6:29 AM Richard Biener
wrote:
>
> On Mon, Mar 22, 2021 at 2:19 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Simply memcpy and memset inline strategies to avoid branches for
> > -mtune=generic:
> >
> > 1. With MOVE_RATIO and CLEAR_R
Simply memcpy and memset inline strategies to avoid branches for
-mtune=icelake:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a.
Simply memcpy and memset inline strategies to avoid branches for
-mtune=generic:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a.
Simply memcpy and memset inline strategies to avoid branches for
Skylake family CPUs:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
nce improvements on eembc benchmarks with one
regression.
H.J. Lu (3):
x86: Update memcpy/memset inline strategies for Ice Lake
x86: Update memcpy/memset inline strategies for Skylake family CPUs
x86: Update memcpy/memset inline strategies for -mtune=generic
gcc/config/i386/i386-expand.c
Tested on Linux/x86-64 and Linux/i686. OK for master and release
branches?
Thanks.
H.J.
---
Since CPUID instruction may return different values on hybrid core.
volatile is needed on asm statements in .
PR target/99704
* config/i386/cpuid.h (__cpuid): Add __volatile__.
On Sat, Mar 20, 2021 at 6:46 AM Martin Liška wrote:
>
> On 3/20/21 1:21 PM, H.J. Lu wrote:
> > |Since construct_container may be called with cfun == NULL, check cfun !=
> > NULL before accessing silent_p. |
>
> Thank you for the quick fix.
>
> Please use the mini
Since construct_container may be called with cfun == NULL, check
cfun != NULL before accessing silent_p.
gcc/
PR target/99679
* config/i386/i386.c (construct_container): Check cfun != NULL
before accessing silent_p.
gcc/testsuite/
PR target/99679
*
On Fri, Mar 19, 2021 at 1:39 AM Uros Bizjak wrote:
>
> On Thu, Mar 18, 2021 at 11:44 PM H.J. Lu wrote:
> >
> > If we never generate function body, we shouldn't issue errors for return
> > nor argument. Add init_cumulative_args_called to i386 machine_function
>
If we never generate function body, we shouldn't issue errors for return
nor argument. Add init_cumulative_args_called to i386 machine_function
to avoid issuing errors for return and argument without function body.
gcc/
PR target/99652
* config/i386/i386.c
On Thu, Mar 18, 2021 at 11:35 AM Marek Polacek via Gcc-patches
wrote:
>
> As discussed in the r11-7709 patch, we can now make sure that tsubst
> never sees a FLOAT_EXPR, much like its counterpart FIX_TRUNC_EXPR.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/cp/ChangeLog:
>
>
On Wed, Mar 17, 2021 at 6:14 AM Uros Bizjak wrote:
>
> On Wed, Mar 17, 2021 at 1:45 PM H.J. Lu wrote:
> >
> > On Wed, Mar 17, 2021 at 12:40 AM Uros Bizjak wrote:
> > >
> > > On Tue, Mar 16, 2021 at 4:59 PM H.J. Lu wrote:
> > > >
> &
On Wed, Mar 17, 2021 at 12:40 AM Uros Bizjak wrote:
>
> On Tue, Mar 16, 2021 at 4:59 PM H.J. Lu wrote:
> >
> > On Sun, Mar 14, 2021 at 1:31 PM H.J. Lu wrote:
> > >
> > > On Sun, Mar 14, 2021 at 12:43 PM Uros Bizjak wrote:
> > > >
> &
On Sun, Mar 14, 2021 at 1:31 PM H.J. Lu wrote:
>
> On Sun, Mar 14, 2021 at 12:43 PM Uros Bizjak wrote:
> >
> > On Sun, Mar 14, 2021 at 8:14 PM H.J. Lu wrote:
> > > > > Done. Here is the updated patch. Tested on Linux/x86-64. OK for
> > > >
On Sun, Feb 14, 2021 at 9:26 AM H.J. Lu wrote:
>
> Check if host supports multi-byte NOPs before enabling CET on host.
>
> config/
>
> PR binutils/27397
> * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
> NOPs.
>
> libiberty/
On Sun, Mar 14, 2021 at 12:43 PM Uros Bizjak wrote:
>
> On Sun, Mar 14, 2021 at 8:14 PM H.J. Lu wrote:
> > > > Done. Here is the updated patch. Tested on Linux/x86-64. OK for
> > > > master?
> > >
> > > I don't understand the purpose of the
On Sun, Mar 14, 2021 at 11:49 AM Uros Bizjak wrote:
>
> On Sat, Mar 13, 2021 at 8:39 PM H.J. Lu wrote:
> >
> > On Fri, Mar 12, 2021 at 8:37 AM Uros Bizjak wrote:
> > >
> > > On Fri, Mar 12, 2021 at 2:20 PM H.J. Lu wrote:
> > > >
> > &
On Fri, Mar 12, 2021 at 8:37 AM Uros Bizjak wrote:
>
> On Fri, Mar 12, 2021 at 2:20 PM H.J. Lu wrote:
> >
> > On Thu, Mar 11, 2021 at 11:21 PM Uros Bizjak wrote:
> > >
> > > On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
> > > >
> > &
On Thu, Mar 11, 2021 at 11:21 PM Uros Bizjak wrote:
>
> On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
> >
> > Update 'P' operand modifier for -fno-plt to support inline assembly
> > statements. In 64-bit, we can always load function address with
> > @GOTPCREL
On Thu, Mar 11, 2021 at 11:27 PM Uros Bizjak wrote:
>
> On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
> >
> > Update 'P' operand modifier for -fno-plt to support inline assembly
> > statements. In 64-bit, we can always load function address with
> > @GOTPCREL
Update 'P' operand modifier for -fno-plt to support inline assembly
statements. In 64-bit, we can always load function address with
@GOTPCREL. In 32-bit, we load function address with @GOT only for
non-PIC since PIC register may not be available at call site.
gcc/
PR target/99504
On Sat, Feb 27, 2021 at 11:01 PM Mike Frysinger wrote:
>
> On 19 Dec 2020 10:10, H.J. Lu via Gdb-patches wrote:
> > --- a/Makefile.in
> > +++ b/Makefile.in
> >
> > +PGO_BUILD_TRAINING_FLAGS_TO_PASS = \
> > + PGO_BUILD_TRAINING=yes \
> > + CFLA
Since retain attribute requires SHF_GNU_RETAIN, run retain tests only
if SHF_GNU_RETAIN is supported.
PR testsuite/99173
* c-c++-common/attr-retain-5.c: Require R_flag_in_section.
* c-c++-common/attr-retain-6.c: Likewise.
* c-c++-common/attr-retain-7.c: Likewise.
On Sat, Feb 20, 2021 at 1:49 AM Andreas Schwab wrote:
>
> FAIL: c-c++-common/attr-retain-5.c -Wc++-compat (test for excess errors)
> Excess errors:
> /opt/gcc/gcc-20210220/gcc/testsuite/c-c++-common/attr-retain-5.c:23:1:
> warning: 'retain' attribute ignored [-Wattributes]
>
On Thu, Feb 18, 2021 at 7:15 AM Richard Biener
wrote:
>
> On Thu, Feb 18, 2021 at 4:01 PM H.J. Lu wrote:
> >
> > On Thu, Feb 18, 2021 at 2:25 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Feb 18, 2021 at 5:15 AM H.J. Lu via Gcc-patches
> > >
On Thu, Feb 18, 2021 at 2:25 AM Richard Biener
wrote:
>
> On Thu, Feb 18, 2021 at 5:15 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > On Wed, Feb 17, 2021 at 12:50 PM H.J. Lu wrote:
> > >
> > > On Wed, Feb 17, 2021 at 12:14 PM Jakub Jelinek wrote:
> &
On Wed, Feb 17, 2021 at 12:50 PM H.J. Lu wrote:
>
> On Wed, Feb 17, 2021 at 12:14 PM Jakub Jelinek wrote:
> >
> > On Wed, Feb 17, 2021 at 12:04:34PM -0800, H.J. Lu wrote:> >
> > > + /* For -fretain-used-symbol, a "used" attribute also implies &quo
On Wed, Feb 17, 2021 at 12:14 PM Jakub Jelinek wrote:
>
> On Wed, Feb 17, 2021 at 12:04:34PM -0800, H.J. Lu wrote:> >
> > + /* For -fretain-used-symbol, a "used" attribute also implies "retain".
> > */
>
> s/-symbol/-sym
On Wed, Feb 17, 2021 at 10:57 AM Jakub Jelinek wrote:
>
> On Wed, Feb 17, 2021 at 09:34:34AM -0800, H.J. Lu wrote:
> > -fretain-used-symols.
> > +/* Add the NAME attribute to *ANODE. */
> > +
> > +static void
> > +add_attribute (tree *anode, int
On Wed, Feb 17, 2021 at 6:26 AM Jakub Jelinek wrote:
>
> On Tue, Feb 16, 2021 at 11:59:21AM -0800, H.J. Lu wrote:
> > PR target/99113
> > * common.opt: Add -fgnu-retain.
>
> I'm not sure -fgnu-retain as the option name.
> Wouldn't say -fretain-used-vars
On Tue, Feb 16, 2021 at 8:45 AM Jakub Jelinek wrote:
>
> On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> > thousands of
> >
> > ld: warning: orphan section `.da
When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
thousands of
ld: warning: orphan section `.data.event_initcall_finish' from `init/main.o'
being placed in section `.data.event_initcall_finish'
ld: warning: orphan section `.data.event_initcall_start' from `init/main.o'
Check if host supports multi-byte NOPs before enabling CET on host.
config/
PR binutils/27397
* cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
NOPs.
libiberty/
PR binutils/27397
* configure: Regenerated.
---
config/cet.m4 | 19
On Fri, Jan 29, 2021 at 7:53 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Jan 21, 2021 at 07:33:34PM +, Kwok Cheung Yeung wrote:
> > The detach support clearly needs more work, but is this particular patch
> > okay for trunk?
>
> Sorry for the delay.
>
> I'm afraid it is far from being
On Tue, Feb 9, 2021 at 6:33 AM Jakub Jelinek wrote:
>
> On Tue, Feb 09, 2021 at 06:25:10AM -0800, H.J. Lu via Gcc-patches wrote:
> > My patch does nothing for GCC 10.
> >
> > > files from GCC 11
> > > and -fcf-protection=none (aka the long-year default)?
&g
On Tue, Feb 9, 2021 at 6:19 AM Richard Biener
wrote:
>
> On Tue, Feb 9, 2021 at 2:11 PM H.J. Lu wrote:
> >
> > On Tue, Feb 9, 2021 at 12:59 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Feb 8, 2021 at 3:07 PM H.J. Lu via Gcc-patches
> >
On Tue, Feb 9, 2021 at 12:59 AM Richard Biener
wrote:
>
> On Mon, Feb 8, 2021 at 3:07 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > When the SHSTK feature is not available or not enabled, RDSSP is a NOP,
> > always save and restore shadow stack pointer to support
When the SHSTK feature is not available or not enabled, RDSSP is a NOP,
always save and restore shadow stack pointer to support compiling source
codes, containing __builtin_setjmp and __builtin_longjmp, with different
-fcf-protection options.
PR target/98997
* config/i386/i386.md
On Thu, Jan 28, 2021 at 1:21 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Jan 28, 2021 at 7:32 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > Hi:
> >GCC11 will be the system GCC 2 years from now, and for the
> > processors then, they shouldn't even need to split a 256-bit vector
> >
On Mon, Jan 25, 2021 at 4:54 AM Martin Liška wrote:
>
> On 1/22/21 3:51 PM, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> PR gcov-profile/98739
> >> * common.opt: Add missing sign symbol.
> >> * value-prof.c (get_nth_most_common_value): Restore handling
> >> of
On Tue, Jan 19, 2021 at 8:32 PM Hongtao Liu via Gcc-patches
wrote:
>
> On Wed, Jan 20, 2021 at 12:10 AM Richard Sandiford
> wrote:
> >
> > Jakub Jelinek via Gcc-patches writes:
> > > On Tue, Jan 19, 2021 at 12:38:47PM +, Richard Sandiford via
> > > Gcc-patches wrote:
> > >> > actually only
-fcf-protection is automatically enabled in libstdc++ on Linux/x86.
Starting from
commit 77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu
Date: Thu Jan 14 05:56:46 2021 -0800
x86: Error on -fcf-protection with incompatible target
GCC issues an error on -fcf-protection
On Fri, Jan 15, 2021 at 4:07 AM Richard Biener wrote:
>
> On Fri, 15 Jan 2021, Jakub Jelinek wrote:
>
> > On Thu, Jan 14, 2021 at 04:08:20PM -0800, H.J. Lu wrote:
> > > Here is the updated patch. OK for master?
> >
> > Here is my version of the entire p
On Thu, Jan 14, 2021 at 3:01 PM Jakub Jelinek wrote:
>
> On Thu, Jan 14, 2021 at 01:04:31PM -0800, H.J. Lu via Gcc-patches wrote:
> > If x86 libatomic isn't compiled with -march=i486 or better, append
> > -march=i486 XCFLAGS for x86 libatomic build. Set try_ifunc to yes
> &
If x86 libatomic isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libatomic build. Set try_ifunc to yes
if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or
better isn't used to compile x86 libatomic.
PR target/70454
* configure.tgt
Starting from
commit 77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu
Date: Thu Jan 14 05:56:46 2021 -0800
x86: Error on -fcf-protection with incompatible target
GCC issues an error on -fcf-protection with incompatible target. CET
is enabled in run-time libraries on x86 when GCC
If x86 libgomp isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libgomp build.
PR target/70454
* configure.tgt (XCFLAGS): Append -march=i486 to compile x86
libgomp if needed.
---
libgomp/configure.tgt | 36
If x86 libitm isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libitm build.
PR target/70454
* configure.tgt (XCFLAGS): Append -march=i486 to compile x86
libitm if needed.
---
libitm/configure.tgt | 39 +++
On Thu, Jan 14, 2021 at 12:33 PM Jakub Jelinek wrote:
>
> On Thu, Jan 14, 2021 at 10:52:24AM -0800, sunil.k.pandey via Gcc-patches
> wrote:
> > On Linux/x86_64,
>
> It breaks x86_64-linux build pretty much everywhere.
> libatomic (but as well libgomp and libitm) uses -march=i486 in certain
On Thu, Jan 14, 2021 at 6:51 AM Uros Bizjak wrote:
>
> On Thu, Jan 14, 2021 at 3:05 PM H.J. Lu wrote:
> >
> > -fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
> > ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE
> > proces
Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid
disabling STV by:
/* Disable STV if -mpreferred-stack-boundary={2,3} or
-mincoming-stack-boundary={2,3} or -mstackrealign - the needed
stack realignment will be extra cost the pass doesn't take into
account and the
-fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE
processors. Issue an error for -fcf-protection with CF_BRANCH when
compiling for 32-bit non-TARGET_CMOVE targets.
gcc/
PR target/98667
*
On Tue, Jan 12, 2021 at 3:55 AM Martin Liška wrote:
>
> The patch is about an extensive debugging facility that I see
> beneficial for GCOV issue.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I'm going to push it.
>
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
>
On Mon, Jan 11, 2021 at 4:22 PM Alan Modra wrote:
>
> On Mon, Jan 11, 2021 at 04:07:22PM -0800, H.J. Lu wrote:
> > These are not fatal errors. Here is the updated patch to use
> > AC_MSG_WARN instead. OK for master?
>
> OK by me. Please squash the two patches.
>
I w
On Mon, Jan 11, 2021 at 3:27 PM Alan Modra wrote:
>
> On Mon, Jan 11, 2021 at 08:57:05AM -0800, H.J. Lu via Binutils wrote:
> > diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
> > index c5b72e9a13d..798a2054edd 100644
> > --- a/config/gcc-plugin.m4
> &
On Mon, Jan 11, 2021 at 3:05 PM Alan Modra wrote:
>
> On Mon, Jan 11, 2021 at 08:57:04AM -0800, H.J. Lu via Binutils wrote:
> > Check if AR works with --plugin and rc before passing --plugin to AR and
> > RANLIB.
>
> Thanks for looking at this, but next time please assi
On Mon, Jan 11, 2021 at 1:20 PM Alan Modra wrote:
>
> On Mon, Jan 11, 2021 at 11:53:15AM -0800, H.J. Lu via Binutils wrote:
> > Check if AR is usable for LTO build with --enable-pgo-build=lto:
> >
> > checking for -plugin option... ar: no operation specified
> > Fai
Check if AR is usable for LTO build with --enable-pgo-build=lto:
checking for -plugin option... ar: no operation specified
Failed: ar --plugin
/usr/gcc-11.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.so rc
no
configure: error: AR with --plugin and rc is required for LTO build
or (at your option) any later version.
This program has absolutely no warranty.
[hjl@gnu-cfl-2 bin]$
Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.
Tested:
1. Binutils build
2. ./src-release.sh gdb
3. ./src-release.sh binutils
with binutils 2.30.
H.J. Lu (2):
GCC
Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.
bfd/
PR ld/27173
binutils/
PR ld/27173
* configure: Regenerated.
gas/
PR ld/27173
* configure: Regenerated.
gprof/
PR ld/27173
* configure: Regenerated.
AR from older binutils doesn't work with --plugin and rc:
[hjl@gnu-cfl-2 bin]$ touch foo.c
[hjl@gnu-cfl-2 bin]$ ar --plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
[hjl@gnu-cfl-2 bin]$ ./ar --plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc
On Thu, Jan 7, 2021 at 4:10 AM Nick Clifton wrote:
>
> Hi H.J.
>
> > I got no feedbacks for my current patch set:
> > https://sourceware.org/pipermail/gdb-patches/2020-December/174216.html
>
> Right - in which case I would like to do this:
>
>1. Do not apply the patch now. But when the 2.36
On Fri, Jan 8, 2021 at 12:15 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > Is there an utility routine in GCC to query the pointer width of the
> > current target? Whether it’s 32bit pointer or 64 bit pointer for the target?
> >
>
On Fri, Jan 8, 2021 at 6:43 AM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
> >
> > On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > > >
> >
On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
>
> On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> >
> > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > >
> > > > &
On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> >
> > > Since R10 is preserved when calling mcount, R10 can be used a scratch
> > > register to call mcount in large model.
> >
> > Please ment
ling mcount. */
>
> Also mention that R10 can be used as a static chain register and is
> preserved when calling mcount for nested functions.
>
> + fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> + mcount_name);
> + break;
This is the patch I am
Since R10 is preserved when calling mcount, R10 can be used a scratch
register to call mcount in large model.
gcc/
PR target/98482
* config/i386/i386.c (x86_function_profiler): Use R10 to call
mcount in large model. Sorry for large model with PIC.
gcc/testsuite/
On Mon, Jan 4, 2021 at 7:41 PM Jeff Law wrote:
>
>
>
> On 1/1/21 6:34 AM, H.J. Lu via Gcc-patches wrote:
> > _mm_extract_pi16 is intrinsic for pextrw, which should be zero-extended,
> > not sign-extended.
> >
> > gcc/
> >
> > PR
On Tue, Jan 5, 2021 at 5:27 AM Christian Biesinger
wrote:
>
> On Fri, Jan 1, 2021 at 1:07 AM H.J. Lu via Gdb-patches
> wrote:
> >
> > On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers
> > wrote:
> > >
> > > On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches
On Sat, Jan 2, 2021 at 11:24 AM Segher Boessenkool
wrote:
>
> On Sat, Dec 19, 2020 at 10:10:31AM -0800, H.J. Lu via Gcc-patches wrote:
> > Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
> > is not built together with GCC, --enable-pgo-build enables the PG
On Fri, Jan 1, 2021 at 3:15 PM Ian Lance Taylor via Gcc-patches
wrote:
>
> As far as I know all the build problems introduced by the update to
> Go1.16beta1 are now fixed.
>
> Please let me know if I missed anything.
>
You missed this one for x32:
diff --git
_mm_extract_pi16 is intrinsic for pextrw, which should be zero-extended,
not sign-extended.
gcc/
PR target/98495
* config/i386/xmmintrin.h (_mm_extract_pi16): Cast to unsigned
short first.
gcc/testsuite/
PR target/98495
* gcc.target/i386/pr98495-1.c: New
901 - 1000 of 5860 matches
Mail list logo
