RFA: Deprecate the ARM simulator

Hi Guys, I recently applied a patch to the top level configure script in the binutils-gdb repository to deprecate the ARM simulator and I would like to apply a similar one to the GCC repository so that the two configure systems are kept in sync. Any objections ? Cheers Nick diff

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

Hi Nelson, Sounds good to me, too.  Once get the approval, I will backport them to binutils-2_43-branch :-) Please could you ping me once you have done that. I will make sure not to make the point release before receiving your message. Cheers Nick

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

Hi Jeff, 2.43 was released over an weekend.  Is it possible to let it be supported after 2.44? cc Nick and jan. I don't think it's critical enough to backport to 2.43.  I'd just put it on the trunk so that it's available in 2.44. It might be worth adding it to the 2.43

Re: [PATCH 43/52] rx: New hook implementation rx_c_mode_for_floating_type

): New macro. * config/rx/rx.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH 32/52] stormy16: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Nick

Re: [PATCH 25/52] msp430: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in msp430 port. gcc/ChangeLog: * config/msp430/msp430.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH 21/52] m32r: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in m32r port. gcc/ChangeLog: * config/m32r/m32r.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH 20/52] m32c: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in m32c port. gcc/ChangeLog: * config/m32c/m32c.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH 18/52] iq2000: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in iq2000 port. gcc/ChangeLog: * config/iq2000/iq2000.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH 15/52] frv: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in frv port. gcc/ChangeLog: * config/frv/frv.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH 14/52] fr30: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in fr30 port. gcc/ChangeLog: * config/fr30/fr30.h (FLOAT_TYPE_SIZE): Remove. (DOUBLE_TYPE_SIZE): Likewise. (LONG_DOUBLE_TYPE_SIZE): Likewise. Approved - please apply. Cheers Nick

Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.

Hi Christophe, I have a follow-up one: I think the same applies to binutils, but I don't think any maintainer / contributor expressed an opinion, and IIUC patch policy for binutils is (lightly) documented at https://sourceware.org/binutils/wiki/HowToContribute Maybe Nick can update it?

RFC: Top level configure: Require a minimum version 6.8 texinfo

now almost 20 years old (it was released in April 2004), updating the requirement to a newer version does seem reasonable. On the other hand 6.8 is quite new (it was released in March 2021), so a lot of systems out there may not have it. Thoughts ? Cheers Nick [1] https

Re: [PATCH 14/24] libtool.m4: fix nm BSD flag detection

On 7 Aug 2023, Jeff Law uttered the following: > On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote: >> From: Nick Alcock >> Libtool needs to get BSD-format (or MS-format) output out of the system >> nm, so that it can scan generated object files for symbol names for >

Re: [PATCH] msp430: Mark unused attribute

Hi Jan-Benedict, gcc/ChangeLog: * config/msp430/msp430.cc (msp430_single_op_cost): Mark unused argument. Okay for HEAD? Patch approved - please apply. (I think that this patch would also count as an "obvious" fix, but thanks for asking anyway). Cheers Nick

Re: RFA: Another Rust demangler recursion limit

Hi Jeff, OK. Thanks. And yes, I wish someone else was looking at this stuff.  Rust isn't really on my radar right now... I have been toying with the idea of putting myself forward as a maintainer for the libiberty sources. I just wish that I had more free time... Cheers Nick

RFA: Another Rust demangler recursion limit

Nick diff --git a/libiberty/rust-demangle.c b/libiberty/rust-demangle.c index 36afcfae278..d6daf23af27 100644 --- a/libiberty/rust-demangle.c +++ b/libiberty/rust-demangle.c @@ -1082,6 +1082,18 @@ demangle_path_maybe_open_generics (struct rust_demangler *rdm) if (rdm->errored) return o

Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile

Hi Simon, Ping. Patch approved - please apply. I appreciate that modifying these top level files is a bit nerve wracking, but I think that you have done a good job in this case. :-) Cheers Nick

Fix another Rust demangling bugs (PR 105039)

Hi Guys, Attached is a proposed patch to fix another Rust demangling bug reported in PR 105039. I would like to say that this is the last time that we will see this problem for the Rust demangler, but I am not that naive... OK to apply ? Cheers Nickdiff --git a/libiberty/rust-deman

RFA: libiberty: Fix infinite recursion in rust demangler (PRs 98886 and 99935)

"uint" type is not used. Tested with a patched version of the binutils sources on an x86-pc-linux-gnu target. Cheers Nick 2022-01-26 Nick Clifton * rust-demangle.c (struct rust_demangler): Add a recursion counter. (demangle_path): Increment/decrement the re

Re: [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402, PR102033, PR102034, PR102039, PR102

hi Jason, IMHO, I think your patch probably finally solved this long-standing Core 1001 issue. Of course it is not up to me to say so. I just want to point out that it even solves the following case, even though it is more or less expected if concept and lambda all work expectedly. template conce

[PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402, PR102033, PR102034, PR102039, PR102

First of all, I am sorry for my late response as I missed your email. I need to update my filter setup of gmail after switching from hotmail. >I think WILDCARD_TYPE_P is what you want, except... I will try this one. >Your patch rejects that testcase even without the specialization on >int[], whic

Re: [PATCH] c++: Comment out announce_function to prevent ICE [PR102426]

I am terribly sorry for my typo of wrong PR #, it should be 102624. Please ignore this email thread and I resend the patch in next email with correct subject: [PATCH] c++: Comment out announce_function to prevent ICE [PR102624] Once again my apologies for spam. On Fri, Oct 8, 2021 at 12:31 AM qin

Re: [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402, PR102033, PR102034, PR102039, PR102

Here I attach [PATCH-v2]. On Sun, Oct 3, 2021 at 7:14 AM Nick Huang wrote: > > Hi Jason, > > I made a little improvement of my fix by including template > type parameter to not dropping cv-const because they are similar to dependent > type which you cannot determine whether the

[PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402, PR102033, PR102034, PR102039, PR102

Hi Jason, I made a little improvement of my fix by including template type parameter to not dropping cv-const because they are similar to dependent type which you cannot determine whether they are top-level cv-qualifier or not until instantiation. + if (processing_template_decl +

Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

ht never accomplish this task. Once again appreciate your patient help! On Fri, Oct 1, 2021 at 11:46 AM Jason Merrill wrote: > > On 10/1/21 11:10, Nick Huang wrote: > >> gcc-verify still fails with this version: > >> > >>> ERR: line should start with a tab: "

Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

thank you for your patience and really appreciate it. On Fri, Oct 1, 2021 at 9:29 AM Jason Merrill via Gcc-patches wrote: > > On 9/30/21 14:24, nick huang wrote: > >>> You may need to run contrib/gcc-git-customization.sh to get the git > >>> gcc-verify command. > >

Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

ment. Thank you again for your patient explanation and help! On 9/26/21 21:31, nick huang via Gcc-patches wrote: > Hi Jason, > > 1. Thank you very much for your detailed comments for my patch and I really > appreciate it! Here is my revised patch: > > The root cause of

Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

>>template >>struct A >>{ >> void f(T); >>}; >> >>template >>void A::f(const T) >>{ } >> >>which is certainly questionable code, but is currently also accepted by >>clang and EDG compilers. I just found out that clang actually correctly reject this code during specialization. (https://www.g

Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

ment. However, I just sent email to ass...@gnu.org to request assignment. Alternatively, I am not sure if adding this "signoff" tag in submission will help? Signed-off-by: qingzhe huang Thank you again! > On 8/28/21 07:54, nick huang via Gcc-patches wrote: > > Reference with c

Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

d of bugs. It happens during template function declaration stage #1 when producing template declarator. Instead of doing a later-correction-effort in PR92010, my patch tries to at least avoid dropping "const" in case of "typename" and "decltype" during template f

*PING* Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

Reference with cv-qualifiers should be ignored instead of causing an error because standard accepts cv-qualified references introduced by typedef which is ignored. Therefore, the fix prevents GCC from reporting error by not setting variable "bad_quals" in case the reference is introduced by typed

*PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

These bugs are considered duplicate cases of PR51851 which has been suspended since 2012, an issue known as "core1001/1322". Considering this background, it deserves a long comment to explain. Many people believed the root cause of this family of bugs is related with the nature of how and when

Re: [PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

On 21 Jul 2021, Alan Modra uttered the following: > On Wed, Jul 07, 2021 at 08:03:45PM +0100, Nick Alcock via Gcc-patches wrote: >> >>> PR libctf/27482 >> >>> * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided >> > >> >

[PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

These bugs are considered duplicate cases of PR51851 which has been suspended since 2012, an issue known as "core1001/1322". Considering this background, it deserves a long comment to explain. Many people believed the root cause of this family of bugs is related with the nature of how and when

[PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

Reference with cv-qualifiers should be ignored instead of causing an error because standard accepts cv-qualified references introduced by typedef which is ignored. Therefore, the fix prevents GCC from reporting error by not setting variable "bad_quals" in case the reference is introduced by typed

[PATCH] c++: Fix unnecessary error when top-level cv-qualifiers is dropped [PR101783]

The root cause of this bug is that it considers reference with cv-qualifiers as an error by generating value for variable "bad_quals". However, this is not correct for case of typedef. Here I quote spec: "Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through th

[C++ PATCH] Fix unnecessary error when top-level cv-qualifiers is dropped (PR c++/101783)

The root cause of this bug is that it considers reference with cv-qualifiers as an error by generating value for variable "bad_quals". However, this is not correct for case of typedef. Here I quote spec: "Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through

RFA: Libiberty: Fix stack exhaunstion demangling corrupt rust names

Hi Guys, Attached is a proposed patch to fix PR 99935 and 100968, both of which are stack exhaustion problems in libiberty's Rust demangler. The patch adds a recursion limit along the lines of the one already in place for the C++ demangler. OK to apply ? Cheers Nick diff --

Re: [PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

On 7 Jul 2021, Nick Clifton told this: > Hi Nick, > >> Ping? > > Oops. I sent a bunch of pings out at the same time, to a bunch of different projects. You are the only person to respond, so thank you! >>> PR libctf/27482 >>> * libtool.m4 (LT_PATH_N

Re: [PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

Hi Nick, Ping? Oops. PR libctf/27482 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided Changes to libtool need to be posted to the libtool project: https://www.gnu.org/software/libtool/ They have mailing lists for bug reports and patch submissions

Re: [PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

Ping? On 25 Jun 2021, Nick Alcock via Binutils said this: > Libtool needs to get BSD-format (or MS-format) output out of the system > nm, so that it can scan generated object files for symbol names for > -export-symbols-regex support. Some nms need specific flags to turn on > B

Re: Commit: Update libiberty sources

Hi H.J. My patch is needed to build binutils with LTO. I submitted a patch for GCC: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html Very well. I have reappplied your patch to the mainline and 2.37 branch sources. Cheers Nick

Re: [PATCH] inline: do not inline when no_profile_instrument_function is different

in Android. They are currently playing whack-a-mole with no_stack_protector. I'm not sure yet how we can better help them self diagnose, or whether we should consider a change in policy. I'm also not sure whether GCC's einliner corresponds with always_inline or not necessarily? -- Thanks, ~Nick Desaulniers

[PATCH 0/4 REVIEW] libtool and libctf fixes for Solaris 11

erate most relevant configure scripts, skipping only sim/ because it's in a ferment of change right now.) Cc: gcc-patches@gcc.gnu.org Nick Alcock (4): libtool.m4: augment symcode for Solaris 11 libtool.m4: fix nm BSD flag detection libctf: try several possibilities for linker ve

[PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

h/my-nm where *that* is a symlink to /usr/bin/nm.) Cc: gcc-patches@gcc.gnu.org ChangeLog 2021-06-22 Nick Alcock PR libctf/27482 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided NM, if there is one. Run nm on itself, not on /dev/null, to avoid er

[PATCH 1/4] libtool.m4: augment symcode for Solaris 11

This reports common symbols like GNU nm, via a type code of 'C'. Cc: gcc-patches@gcc.gnu.org ChangeLog 2021-06-22 Nick Alcock PR libctf/27967 * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for Solaris 11. --- libtool.m4 | 2 +- 1 file

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

Hi Guys, On 4/30/21 7:36 PM, Simon Marchi wrote: I think this fix is obvious enough, I encourage you to push it, OK - I have pushed the patch to the mainline branches of both the gcc and binutils-gfdb repositories. Cheers Nick

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

t off doing this however as I am not an autoconf expert and I have no idea what the consequences might be. Cheers Nick

RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

Hi Guys, Given that gcc, gdb and now binutils are all now requiring C99 as a minimum version of C, are there any objections to updating configure.ac to reflect this ? Cheers Nick diff --git a/configure.ac b/configure.ac index a721316d07b..59b4194fb24 100644 --- a/configure.ac +++ b

Re: GCC: v850-elf

Hi JBG, These three let it build. One done. Thanks for your support! No worries. Patch pushed. Cheers Nick

Re: GCC: v850-elf

y original patch, your addition to the patch and a fix for the above problem. Cheers Nick diff --git a/gcc/config/v850/v850.c b/gcc/config/v850/v850.c index 249cb400177..e0e5005d865 100644 --- a/gcc/config/v850/v850.c +++ b/gcc/config/v850/v850.c @@ -2181,7 +2181,7 @@ construct_restore_

RFA: libiberty: silence static analyzer warning

x->buffer, 64, ctx); left_over -= 64; - memcpy (ctx->buffer, &ctx->buffer[16], left_over); + memmove (ctx->buffer, &ctx->buffer[16], left_over); } ctx->buflen = left_over; } Cheers Nick

Re: GCC: v850-elf

61 | name, name); | I could not reproduce these in my local environment, but I suspect that you are using a more recent version of gcc than me. The fix looks obvious however, so please could you try out the attached patch and let me know if it resolves the problem ? Cheers

[COMMITED]: rx.h: Define supported debugging types.

about a redefinition. Cheers Nick gcc/ChangeLog 2021-03-09 Nick Clifton * config/rx/rx.h (DBX_DEBUGGING_INFO): Define. (DWARF"_DEBUGGING_INFO): Define. diff --git a/gcc/config/rx/rx.h b/gcc/config/rx/rx.h index 8e23e311c03..59e1f7cfa96 100644 --- a/gcc/config/rx/rx.h +++

[PATCH 4/8] intl: turn LIBINTL into -L / -l form

ays do the right thing for both static and shared links. Cc: gcc-patc...@gnu.org intl/ChangeLog 2021-02-04 Nick Alcock * configure.ac (LIBINTL): Transform into -L/-lintl form. * configure: Regenerate. --- intl/configure| 3 +-- intl/configure.ac | 3 +-- 2 files changed, 2

[PATCH 3/8] intl: always picify

..@gnu.org intl/ChangeLog 2021-02-02 Nick Alcock * aclocal.m4: include picflag.m4. * configure.ac (PICFLAG): Add and substitute. * Makefile.in (PICFLAG): New. (COMPILE): Use it. * configure: Regenerate. --- intl/Makefile.in | 3 +- intl/aclocal.m4 |

[PATCH 0/8 RFC] unbreak --with-included-gettext, and other configury stuff

: gdb-patc...@sourceware.org Cc: gcc-patc...@gnu.org Jakub Jelinek (2): (sync from gcc) intl: Allow building both with old bison and bison >= 3 [PR92008] intl: Unbreak intl build with bison 3 when no regeneration is needed [PR92008] Nick Alcock (6): intl: always picify intl: turn LIBINTL

[PATCH v2] ld: depend on libctf

in the build tree will be automatically used, but if one *is* present, it may take precedence and break things.) (This is a maybe- dependency, so it will work even if libctf is disabled.) ChangeLog 2021-01-26 Nick Alcock PR 27250 * Makefile.def: Add install-libctf dependency to

Re: [PATCH] ld: depend on libctf

On 26 Jan 2021, Andreas Schwab outgrape: > On Jan 26 2021, Nick Alcock via Gcc-patches wrote: > >> diff --git a/Makefile.in b/Makefile.in >> index 03785200dc7..d8a94c4173d 100644 >> --- a/Makefile.in >> +++ b/Makefile.in >> @@ -565,7 +565,7 @@ S

Re: [PATCH] config: check for sighandler_t properly

On 25 Jan 2021, Nathan Sidwell said: > I think you're right about checking though, not I'll look at it once I've dealt with this unfortunate "installing binutils leaves the system linker broken" disaster I've caused. :) -- NULL && (void)

[PATCH] ld: depend on libctf

in the build tree will be automatically used, but if one *is* present, it may take precedence and break things.) (This is a maybe- dependency, so it will work even if libctf is disabled.) ChangeLog 2021-01-26 Nick Alcock PR 27250 * Makefile.def: Add install-libctf dependency to

Re: [PATCH] config: check for sighandler_t properly

On 25 Jan 2021, Nathan Sidwell uttered the following: > On 1/22/21 12:19 PM, Nick Alcock wrote: >> Searching for sighander_t is unlikely to succeed anywhere. >> >> The attempt to #include is also not working, >> and fixing it shows that doing an AC_DEFINE in the body

[PATCH] config: check for sighandler_t properly

Searching for sighander_t is unlikely to succeed anywhere. The attempt to #include is also not working, and fixing it shows that doing an AC_DEFINE in the body of an AC_CHECK_TYPE like that is also risky: both fixed. (The purpose of this check is opaque to me: neither libcody nor GCC ever includ

[PATCH v2 toplevel] sync libctf toplevel from binutils-gdb

trunk directly so should definitely apply this time. Sorry about that. diff --git a/ChangeLog b/ChangeLog index bd87d5fc6ee..0a352870cd6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2021-01-06 Nick Alcock + + * Makefile.def: Sync with binutils-gdb: + (dependencies): a

Re: [PATCH toplevel] libctf: new testsuite

On 5 Jan 2021, Alan Modra via Binutils told this: > It doesn't apply due to gcc missing binutils 87279e3cef5b2c5 changes > too. I could fix that easily enough but I'm going to ask that you > post a combined patch to bring the gcc repo up to date with any libctf > changes. Oops! That never occurr

[PATCH toplevel] libctf: new testsuite

This enables 'make libctf-check', used by a new libctf testsuite in binutils. 2021-01-05 Nick Alcock * Makefile.def (libctf): No longer no_check. Checking depends on all-ld. * Makefile.in: Regenerated. --- Makefile.def

Re: [PATCH] Implement no_stack_protect attribute.

+ correct kernel mailing list this time. On Wed, Oct 21, 2020 at 2:33 PM Nick Desaulniers wrote: > > Thanks for the quick feedback! > > On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote: > > > > On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers vi

Re: [PATCH] Implement no_stack_protect attribute.

Thanks for the quick feedback! On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote: > > On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches > wrote: > > Tangentially related question: > > We're running into a bug related to LTO for the kernel w

Re: [PATCH] Implement no_stack_protect attribute.

On Tue, Oct 20, 2020 at 5:19 AM Richard Biener wrote: > > On Tue, Oct 20, 2020 at 1:24 PM Martin Liška wrote: > > > > PING^5 > > So can we use the same identifier as clang here as Nick > requests? Thus, OK with re-naming everything alongside > no_stack_protector.

Re: [PATCH] Implement no_stack_protect attribute.

's many examples of this on LLVM's side too, but I would prefer to stop the proliferation of subtle differences like this that harm toolchain portability when possible and when we can proactively address. -- Thanks, ~Nick Desaulniers

Re: RFA: Remove use of register keyword in libiberty.h

Hi Guys, >> include/ChangeLog >> 2020-06-25 Nick Clifton >> >> * libiberty.h (bsearch_r): Remove use of the register keyword from >> the prototype. >> >> libiberty/ChangeLog >> 2020-06-25 Nick Clifton >> >>

[COMMITTED} m32r: Disable movsicc pattern

-O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects execution test > PASS: gcc.dg/strcmpopt_2.c execution test > PASS: gcc.dg/lto/pr67452 c_lto_pr67452_0.o-c_lto_pr67452_0.o link, -O2 -flto > -fopenmp-simd Cheers Nick gcc/ChangeLog 2020-06-25 Nick Clifton * config/

Re: RFA: Remove use of register keyword in libiberty.h

Hi Nick, Hi Ian, >> In file included from gold/archive.cc:29: >> include/libiberty.h:646:25: error: 'register' storage class >> specifier is deprecated and incompatible with C++17 >> [-Werror,-Wdeprecated-register] >> >> So I w

Re: RFA: Remove use of register keyword in libiberty.h

On 25 Jun 2020, Nick Clifton outgrape: > Hi Ian, Hi Nick, > > Comping the GOLD linker with Clang has started producing this error > message: > > In file included from gold/archive.cc:29: > include/libiberty.h:646:25: error: 'register' storage class >

RFA: Remove use of register keyword in libiberty.h

Hi Ian, Hi Nick, Compiling the GOLD linker with Clang has started producing this error message: In file included from gold/archive.cc:29: include/libiberty.h:646:25: error: 'register' storage class specifier is deprecated and incompatible with C++17 [-Werror,-W

RFA: Remove use of register keyword in libiberty.h

Hi Ian, Hi Nick, Comping the GOLD linker with Clang has started producing this error message: In file included from gold/archive.cc:29: include/libiberty.h:646:25: error: 'register' storage class specifier is deprecated and incompatible with C++17 [-Werror,-W

[PATCH v2] libiberty, include: add bsearch_r

libctf wants a bsearch that takes a void * arg pointer to avoid a nonportable use of __thread. bsearch_r is required, not optional, at this point because as far as I can see this obvious-sounding function is not implemented by anyone's libc. We can easily move it to AC_LIBOBJ later if it proves n

[PATCH] libiberty, include: add bsearch_r

libctf wants a bsearch that takes a void * arg pointer to avoid a nonportable use of __thread. bsearch_r is required, not optional, at this point because as far as I can see this obvious-sounding function is not implemented by anyone's libc. We can easily move it to AC_LIBOBJ later if it proves n

[PATCH] libiberty, include: add bsearch_r

A resend of something I sent over, sheesh, six months ago. Jeff Law acked it but, well, it was six months ago. I think getting a re-ack might be a good idea. (Also... could someone push it for me? I should have push privs, but only on binutils and I have yet to test them. Starting my pushing car

RFA: Fix libiberty testsuite failure

ix this. Is this OK ? Cheers Nick libiberty/ChangeLog 2020-01-20 Nick Clifton * testsuite/demangle-expected: Fix expected demangling. Index: libiberty/testsuite/demangle-expected === --- libiberty/testsuite/demangle-

[PATCH] libiberty, include: add bsearch_r

libctf wants a bsearch that takes a void * arg pointer to avoid a nonportable use of __thread. bsearch_r is required, not optional, at this point because as far as I can see this obvious-sounding function is not implemented by anyone's libc. We can easily move it to AC_LIBOBJ later if it proves n

Re: [PATCH 0/2] Introduce a new GCC option, --record-gcc-command-line

--frecord-options=object is a synonym for your option The user could supply one or more of the selectors to have the recording happen in multiple places. Just an idea. Cheers Nick

Re: Type representation in CTF and DWARF

On 18 Oct 2019, Pedro Alves stated: > On 10/18/19 2:21 PM, Richard Biener wrote: > In most cases local types etc are a fairly small contributor to the total volume -- but macros can contribute a lot in some codebases. >>> (The Linux kernel's READ_ONCE macro is one I've personally be

Re: Type representation in CTF and DWARF

On 17 Oct 2019, Richard Biener verbalised: > On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock wrote: >> >> On 11 Oct 2019, Indu Bhagat stated: >> > Compile with -g -gdwarf-like-ctf and use dwz -o >> > (using >> > dwz compiled from the master branch) on th

Re: Type representation in CTF and DWARF

On 11 Oct 2019, Indu Bhagat stated: > Compile with -g -gdwarf-like-ctf and use dwz -o (using > dwz compiled from the master branch) on the generated binaries: > > (coreutils-0.22) > .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf > (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4)) >

Re: Type representation in CTF and DWARF

On 9 Oct 2019, Indu Bhagat told this: > Yes, CTF does not support C++ at this time. To cover all of C (including > GNU C extensions), we need to add representation for things like Vector type, > non IEEE float etc. (somewhat infrequently occurring constructs) One note: adding C++ support will not

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Sat, Sep 7, 2019 at 6:11 AM Segher Boessenkool wrote: > > On Fri, Sep 06, 2019 at 06:04:54PM -0700, Nick Desaulniers wrote: > > On Fri, Sep 6, 2019 at 5:14 PM Segher Boessenkool > > wrote: > > > On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers v

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Fri, Sep 6, 2019 at 5:14 PM Segher Boessenkool wrote: > > On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via gcc-patches > wrote: > > Just to prove my point about version checks being brittle, it looks > > like Rasmus' version check isn't even right.

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Fri, Sep 6, 2019 at 3:56 PM Segher Boessenkool wrote: > > On Fri, Sep 06, 2019 at 03:35:02PM -0700, Nick Desaulniers wrote: > > On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool > > wrote: > > > And if instead you tested whether the actual feature you need works

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool wrote: > > On Fri, Sep 06, 2019 at 11:14:08AM -0700, Nick Desaulniers wrote: > > Here's the case that I think is perfect: > > https://developers.redhat.com/blog/2016/02/25/new-asm-flags-feature-for-x86-in-gcc-6/ > >

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

detection instead. This simplifies use of this feature even between codebases supporting multiple versions of GCC. (Also, I'm guessing the cost of another preprocessor define is near zero compared to parsing comments for -Wimplicit-fallthrough) -- Thanks, ~Nick Desaulniers

Re: RFA: Synchronize top level files with binutils

Hi Richard, Please may I apply this patch to the gcc-9, gcc-8 and gcc-7 branches ? I have tested it on all three branches and found no problems. Cheers Nick 2019-06-07 Nick Clifton Import these changes from the binutils/gdb repository: 2019-05-28 Nick Alcock

Re: RFA: Synchronize top level files with binutils

h current binutils would be available? Do you have any particular branches in mind ? There do seem to be quite a lot of them... Cheers Nick

Re: RFA: Synchronize top level files with binutils

Hi Richard, OK, here is a resubmission of my patch with just the addition of the libctf patches this time. (Sorry about the previous bad patch). Tested with a bootstrap and a normal build. OK to apply ? Cheers Nick 2019-06-07 Nick Clifton Import these changes from the

Re: RFA: Synchronize top level files with binutils

ill work on it over the weekend and try again on Monday. Cheers Nick

RFA: Synchronize top level files with binutils

Hi Guys, I would like to bring over a few additions that have recently been made to the binutils versions of the Makefile.def and configure.ac files. Any objections ? Note - I did run a toolchain bootstrap after applying this patch locally and that went OK... Cheers Nick

Ping: [PATCH] PR88395 Fix Nullptr when compiling with -fconcepts

I'm pinging this patch as it's old now and should be applied to fix the bug. Nick On 2019-04-08 7:20 p.m., Nicholas Krause wrote: > This fixes the caller in tsubst_requires_expr to > tsubst_constraint_variables to wrap their respective > trees in PARM_CONSTR_PARMS. This is

RFA: Patch to fix severe recursion in d_count_templates_scopes (PR 89394)

further investigation proved this guess to be wrong. I felt that leaving the check in however would still be a good idea. Tested with no regressions with an x86_64-linux-gnu toolchain, as well as against the testcase in PR 89394. OK to apply ? Cheers Nick libiberty/ChangeLog 2019-03

Re: [PATCH] Use proper print formatter in main function in fixincl.c

again and sorry for wasting your time Joseph, Nick

  1   2   3   4   5   6   >