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 Thu, Mar 11, 2021 at 11:21 PM Uros Bizjak 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:
> > > >
> > > > Update 'P' operand modifier for -fno-plt to support
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. In 32-bit, we load function
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. In 32-bit, we load function
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 \
> > + CFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CFLAGS)" \
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 "retain".
> > > */
> >
> > s/-symbol/-symbols/
>
>
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/-symbols/
Fixed.
> > + if (flag_retain_used_symbols
> > + &&
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 flags, tree name, tree args, tree ns,
> > +
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 be better?
I used
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 with
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 patch.
> >
> > Bootstrapped/regtested on
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
> > processors. Issue an error for
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 will keep 2 separate since I
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
> > +++ b/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 assign the bug to
> yourself.
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
> > Failed: ar --plugin
> >
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
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
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 1:24 AM Uros Bizjak 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:
> > > >
> > > > > Since R10 is preserved when calling mcount, R10 can be used
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 mention that R10 can be used as a static chain
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 mention that R10 can be used as a static chain registers and is
> preserved when calling mcount for nested
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
On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers wrote:
>
> On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote:
>
> > Work around what appears to be a GNU make bug handling MAKEFLAGS
> > values defined in terms of make variables, as is the case for CC and
> > friends when
On Thu, Dec 31, 2020 at 8:21 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Thu, Dec 31, 2020 at 7:57 AM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> aarch64's *add3_poly_1 has a pattern with the constraints:
> >>
> >> "=...,r,"
> >> "...,0,rk"
> >> "...,Uai,Uat"
> >>
On Thu, Dec 31, 2020 at 7:57 AM Richard Sandiford via Gcc-patches
wrote:
>
> aarch64's *add3_poly_1 has a pattern with the constraints:
>
> "=...,r,"
> "...,0,rk"
> "...,Uai,Uat"
>
> i.e. the penultimate alternative requires operands 0 and 1 to match,
> but the final alternative does not
Hi,
I have 2 patches to enable CET in libffi on users/hjl/cet/master branch at:
https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/cet/master
They use FFI_EXEC_TRAMPOLINE_TABLE to avoid changing libffi ABI.
I tested it on Tiger Lake with
CC="cc" CXX="g++"
Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating
Work around what appears to be a GNU make bug handling MAKEFLAGS
values defined in terms of make variables, as is the case for CC and
friends when we are called from the top level Makefile.
* Makefile.am (AM_MAKEFLAGS): New.
* Makefile.in: Regenerated.
---
gnulib/Makefile.am | 39
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO
build.
* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
* configure.ac: Include config/gcc-plugin.m4.
AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating
When configured with --enable-pgo-build, set TESTS to gdb.dwarf2/*.exp
for PGO build training.
* Makefile.in (TESTS): Set to gdb.dwarf2/*.exp for PGO build
training.
---
gdb/testsuite/Makefile.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/gdb/testsuite/Makefile.in
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO
build.
bfd/
* configure: Regenerated.
binutils/
* configure: Regenerated.
gas/
* configure: Regenerated.
gprof/
* configure: Regenerated.
ld/
* configure: Regenerated.
libctf/
On Thu, Dec 17, 2020 at 11:07 AM Martin Sebor via Gcc-patches
wrote:
>
> The top of trunk fails to build with the error below. I haven't
> spent any time debugging it except to look at git log where
> the description for r11-6238 mentions the function also referenced
> in the error message.
On Thu, Dec 17, 2020 at 6:16 AM Richard Sandiford via Gcc-patches
wrote:
>
> Kyrylo Tkachov via Gcc-patches writes:
> > Hi all,
> >
> > While experimenting with some backend costs for Advanced SIMD and SVE I hit
> > many cases where GCC would pick SVE for VLA auto-vectorisation even when the
> >
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO
build.
* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
* configure.ac: Include config/gcc-plugin.m4.
AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO
build.
bfd/
* configure: Regenerated.
binutils/
* configure: Regenerated.
gas/
* configure: Regenerated.
gprof/
* configure: Regenerated.
ld/
* configure: Regenerated.
libctf/
Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating
Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating
On Thu, Dec 17, 2020 at 5:36 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Dec 17, 2020 at 08:25:12AM -0500, Nathan Sidwell wrote:
> > > Yeah. If it is meant as an optimization barrier, shouldn't it be just
> > >__asm__ volatile ("");
> > > or
> > >__asm__ volatile ("" : : :
On Wed, Dec 16, 2020 at 11:49 AM Nathan Sidwell wrote:
>
>
> I'd missed an install-strip rule in c++tools. Here it is, cribbed
> from gcc/ subdir.
>
> c++tools/
Missing PR other/98328 here.
> * Makefile.in (INSTALL): Replace with ...
> (INSTALL_PROGRAM): ... this.
>
On Wed, Dec 16, 2020 at 5:05 AM Jakub Jelinek wrote:
>
> On Wed, Dec 02, 2020 at 05:15:21AM -0800, H.J. Lu via Gcc-patches wrote:
> > gcc/
> >
> > PR middle-end/93195
> > PR middle-end/93197
> > * configure.ac (HAVE_GAS
On Tue, Dec 15, 2020 at 4:44 PM Jeff Law wrote:
>
>
>
> On 12/15/20 10:30 AM, H.J. Lu wrote:
> > When definitions marked with used attribute and unmarked definitions are
> > placed in the section with the same name, switch to a new section if the
> > SECTION_RETAIN bit doesn't match.
> >
> > gcc/
When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.
gcc/
PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like
int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;
since assembler will
Since SHF_GNU_RETAIN support doesn't work for crtstuff.c which switches
the output section directly with asm statement:
---
static void __attribute__((used))
__do_global_dtors_aux (void)
{
static _Bool completed;
if (__builtin_expect (completed, 0))
return;
completed = 1;
}
static
When SECTION_RETAIN is used, definitions marked with used attribute and
unmarked definitions are placed in a section with the same name. Instead
of issue an error:
[hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
-fdiagnostics-plain-output
c.c:2:49: error: ‘foo1’ causes a section type
On Thu, Oct 29, 2020 at 12:11 PM H.J. Lu wrote:
>
> Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
> is not built together with GCC, --enable-pgo-build enables the PGO build:
>
> 0. Pass --plugin to AR and RANLIB.
> 1. First build with -fprofile-generate.
> 2. Use "make
On Mon, Dec 14, 2020 at 5:06 PM Jeff Law wrote:
>
>
>
> On 12/8/20 5:51 AM, H.J. Lu wrote:
> > When definitions marked with used attribute and unmarked definitions are
> > placed in the section with the same name, switch to a new section if the
> > SECTION_RETAIN bit doesn't match.
> >
> > gcc/
>
On Mon, Dec 14, 2020 at 7:09 AM Uros Bizjak wrote:
>
> On Mon, Dec 14, 2020 at 2:13 PM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
> > then -m32 or -mabi=ms stops working.
> > What is worse, if one configures gcc
On Tue, Dec 8, 2020 at 4:51 AM H.J. Lu wrote:
>
> When SECTION_RETAIN is used, definitions marked with used attribute and
> unmarked definitions are placed in a section with the same name. Instead
> of issue an error:
>
> [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
>
On Thu, Dec 10, 2020 at 1:57 PM Uros Bizjak wrote:
>
> On Thu, Dec 10, 2020 at 10:20 PM H.J. Lu wrote:
> >
> > User interrupt handler stack frame is similar to exception interrupt
> > handler stack frame. Instead of error code, the second argument is
> > user interrupt request register vector.
User interrupt handler stack frame is similar to exception interrupt
handler stack frame. Instead of error code, the second argument is
user interrupt request register vector.
gcc/
PR target/98219
* config/i386/uintrintrin.h (__uintr_frame): Remove uirrv.
gcc/testsuite/
On Wed, Dec 9, 2020 at 7:10 PM Jim Wilson wrote:
>
> This fixes a riscv64-linux bootstrap failure.
>
> get_constant_section calls the select_section target hook, and select_section
> calls get_named_section which calls get_section. So it is possible to have
> a constant not a decl in both of
On Wed, Dec 9, 2020 at 6:08 PM Jim Wilson wrote:
>
> On Tue, Dec 8, 2020 at 4:51 AM H.J. Lu via Gcc-patches
> wrote:
>>
>> When SECTION_RETAIN is used, definitions marked with used attribute and
>> unmarked definitions are placed in a section with the same name. I
When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.
gcc/
PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like
int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;
since assembler will
When SECTION_RETAIN is used, definitions marked with used attribute and
unmarked definitions are placed in a section with the same name. Instead
of issue an error:
[hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
-fdiagnostics-plain-output
c.c:2:49: error: ‘foo1’ causes a section type
On Sun, Dec 6, 2020 at 7:09 AM H.J. Lu wrote:
>
> -mcet was removed by
>
> commit 231baae28ef7ff784683fa5a80df119da2b9a99b
> Author: H.J. Lu
> Date: Tue Apr 24 16:56:04 2018 +
>
> x86/CET: Remove the -mcet command-lint option
>
> PR target/98162
> * doc/extend.texi:
On Sun, Dec 6, 2020 at 10:59 AM Uros Bizjak wrote:
>
> On Sun, Dec 6, 2020 at 7:51 PM H.J. Lu wrote:
> >
> > commit 266f44a91c0c9705d3d18e82d7c5bab32927a18f
> > Author: H.J. Lu
> > Date: Sun May 17 10:10:34 2020 -0700
> >
> > x86: Allow V1TI vector register pushes
> >
> > Add V1TI
commit 266f44a91c0c9705d3d18e82d7c5bab32927a18f
Author: H.J. Lu
Date: Sun May 17 10:10:34 2020 -0700
x86: Allow V1TI vector register pushes
Add V1TI vector register push and split it after reload to a sequence
of:
(set (reg:P SP_REG) (plus:P SP_REG) (const_int -8)))
(set
-mcet was removed by
commit 231baae28ef7ff784683fa5a80df119da2b9a99b
Author: H.J. Lu
Date: Tue Apr 24 16:56:04 2018 +
x86/CET: Remove the -mcet command-lint option
PR target/98162
* doc/extend.texi: Remove -mcet.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1
When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.
gcc/
PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
When SECTION_RETAIN is used, definitions marked with used attribute and
unmarked definitions are placed in a section with the same name. Instead
of issue an error:
[hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
-fdiagnostics-plain-output
c.c:2:49: error: ‘foo1’ causes a section type
When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like
int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;
since assembler will
On Fri, Dec 4, 2020 at 4:17 AM Jozef Lawrynowicz
wrote:
>
> On Thu, Dec 03, 2020 at 04:06:50PM -0800, H.J. Lu via Gcc-patches wrote:
> > When SECTION_RETAIN is used, definitions marked with used attribute and
> > unmarked definitions are placed in the same section. Instead of
801 - 900 of 1253 matches
Mail list logo
