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? Done.

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

Hi Guys, Currently the top level configure.ac file sets the minimum required version of texinfo to be 4.7. I would like to propose changing this to 6.8. The reason for the change is that the bfd documentation now needs at least version 6.8 in order to build[1][2]. Given that 4.7 is

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

Hi Jeff, [I am sending this to your directly since you seem to be the only one reviewing these patches]. Hot on the heels of the fix for the recursion problem in demangle_const a binutils user has filed another PoC that exposes a problem in demangle_path_maybe_open_generics():

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

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 recursi

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 --git

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: 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: 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

Hi Joseph, This isn't an objection, since upgrading auto* for the toolchain can be complicated, but note that AC_PROG_CC_C99 is obsolete in Autoconf 2.70 Ah - in which case changing to an about-to-be-obsolete macro is probably a bad idea. and instead AC_PROG_CC enables C11 mode if

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 +++

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

Hi Jan-Benedict, However, next one is: ../.././gcc/defaults.h:938: error: "PREFERRED_DEBUGGING_TYPE" redefined [-Werror] 938 | #define PREFERRED_DEBUGGING_TYPE NO_DEBUG Ah - this is the same as the fix needed for the RX target. Please try the attached patch. It includes my original

RFA: libiberty: silence static analyzer warning

Hi Ian, One of the static analyzers we use is throwing up an error report for one of the libiberty source files: Error: BUFFER_SIZE (CWE-474): libiberty/sha1.c:261: overlapping_buffer: The source buffer ">buffer[16]" potentially overlaps with the destination buffer "ctx->buffer", which

Re: GCC: v850-elf

Hi Jan-Benedict, With my re-started testing efforts, I've got another one for you I guess (`./configure --target=v850-elf && make all-gcc`): ../.././gcc/config/v850/v850.c: In function ‘char* construct_restore_jr(rtx)’: ../.././gcc/config/v850/v850.c:2260:22: error: ‘%s’ directive writing up

[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 +++

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

tch. Ian - is this OK ? Cheers Nick 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 * bsearch.c (bsearch): Remove use of register keyword.

RFA: Remove use of register keyword in libiberty.h

-register] So I would like to apply the patch below to fix this. Is this OK ? Cheers Nick include/ChangeLog 2020-06-25 Nick Clifton * libiberty.h (bsearch_r): Remove use of the register keyword from the prototype. diff --git a/include/libiberty.h b/include/libiberty.h

RFA: Remove use of register keyword in libiberty.h

-register] So I would like to apply the patch below to fix this. Is this OK ? Cheers Nick include/ChangeLog 2020-06-25 Nick Clifton * libiberty.h (bsearch_r): Remove use of the register keyword from the prototype. diff --git a/include/libiberty.h b/include/libiberty.h

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-

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

Hi Egeyar, Thanks for including me in this discussion. >>> This option is similar to -frecord-gcc-switches. For the record I will also note that there is -fverbose-asm which does almost the same thing, but only records the options as comments in the assembler. They are never converted into

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

Hi Richard, >> OK, here is a resubmission of my patch with just the addition of the >> libctf patches this time. [Sorry - this one got put on a back burner]. > Would it be feasible to backport this to the other maintained branches > so that the option of using them with current binutils

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

Re: RFA: Synchronize top level files with binutils

Hi Richard, >>> +target_modules = { module= libmpx; >>> + bootstrap=true; >>> + lib_path=.libs; }; >> >> It seems to re-introduce things that have been removed on the >> GCC side. > Is it just that one hunk that's problematic (I can't see any other >

RFA: Synchronize top level files with binutils

./ChangeLog 2019-05-29 Nick Clifton Import from binutils: 2019-05-29 Nick Clifton * configure.ac (noconfigdirs): Add libctf if the target does not use the ELF file format. * configure: Regenerate. 2019-05-28 Nick Alcock * Makefile.def

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

-21 Nick Clifton PR 89394 * cp-demangle.c (cplus_demangle_fill_name): Reject negative lengths. (d_count_templates_scopes): Replace num_templates and num_scopes parameters with a struct d_print_info pointer parameter. Adjust body of the function

Re: RFA: libiberty: Add a limit on demangling qualifiers (PR 87241)

Hi Jason, > This issue also will be resolved by disabling or removing the old > demangling code, which I haven't seen anyone argue against. Doh - of course. I withdraw my patch and I hope that yours will go in soon. Cheers Nick

Re: RFA: libiberty: Add a limit on demangling qualifiers (PR 87241) (version 2)

Hi Ian, > I thought we were removing the old demangling schemes? Doh! yes, I totally forgot. So I will withdraw this patch in favour of Jason's. Cheers Nick

RFA: libiberty: Add a limit on demangling qualifiers (PR 87241) (version 2)

Hi Ian, *sigh* 5 minutes after sending the patch for this PR, I realised that I had made a mistake. I should have conditionalized the limit on the number of supported qualifiers, so that the check is only made if we have resource limits enabled. Like this: Cheers Nick Index:

RFA: libiberty: Add a limit on demangling qualifiers (PR 87241)

Nick libiberty/ChangeLog 2018-12-12 Nick Clifton * cplus-dem.c (demangle_qualified): Add an upper limit on the number of qualifiers supported, based upon the value of DEMANGLE_RECURSE_LIMIT. Index: libiberty/cplus-dem.c

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi David, > Apologies in advance if this has been covered, as I've only been half- > watching this thread, but is it always the case that the recursion > depth can be bounded by some scalar multiple of the number of > characters in the name? Probably, but the point of this patch is to add a

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi Jakub, >> My current suggestion >> is to raise the limit to 2048, which allows the libiberty patch to >> pass. But do you have a feel for how much is a realistic limit ? > > For recursion limit I think that is fine. > For just stack size limit, I think it is extremely small. > I see that in

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi Michael, > I think this points toward the limit being _much_ too low. Fair enough - several other people have said this as well. So I have proposed an alternative patch instead. My current suggestion is to raise the limit to 2048, which allows the libiberty patch to pass. But do you have

Re: RFC: libiberty PATCH to disable demangling of ancient mangling schemes

Hi Guys, Looks good to me. Independently, do you see a reason not to disable the old demangler entirely? >> * How likely is it that there are old toolchain in use out there that >> still >> use the v2 mangling ? > GCC 3.0 and up used the new (Itanium C++ ABI) mangling, 2.95

Re: RFC: libiberty PATCH to disable demangling of ancient mangling schemes

Hi Jason, >> Looks good to me. Independently, do you see a reason not to disable the >> old demangler entirely? > > Like so. Does anyone object to this? These mangling schemes haven't > been relevant in decades. I am not really familiar with this old scheme, so please excuse my ignorance in

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v5]

Hi Ian, Is the patch OK with you ? Cheers Nick

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v5]

Hi Pedro, > The issue pointed out by > > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02592.html > > is still present in this version. Doh! Yes I meant to fix that one too, but forgot. > Also, noticed a typo here: > >> +/* If DMGL_NO_RECURE_LIMIT is not enabled, then this is the value

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v4]

ough I had to make sure that the affected code could handle NULL pointers properly afterwards. OK to apply ? Cheers Nick include/ChangeLog 2018-11-29 Nick Clifton * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define libiberty/ChangeL

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Cary, > In order to handle arbitrary user input without crashing, perhaps the > demangler should switch from recursive descent parsing to a state > machine, where exhaustion of resources can be handled gracefully. I think that that would be a better long term fix for the problem, but it is

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

Hi Richard, >> * The description of the DMGL_RECURSE_LIMIT option in demangle.h has >> been enhanced to add a note that if the option is not used, then >> bug reports about stack overflows in the demangler will be rejected. > > Shouldn't we make it fool-proof by instead introducing a

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

this version acceptable ? Cheers Nick libiberty/ChangeLog 2018-11-29 Nick Clifton PR 87681 PR 87675 PR 87636 PR 87335 * cp-demangle.h (struct d_info): Add recursion_limit field. * cp-demangle.c (d_function_type): If the recursion limit is

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Jakub, >> Also - Tom and Pedro have raised the issue that the patch introduces >> a new static variable to the library that is not thread safe. I am >> not sure of the best way to address this problem. Possibly the >> variable could be made thread local ? Are there any other static

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Scott, > Thank you for looking into this Nick. I've been staring at a few of these > CVEs off-and-on for a few days, and the following CVEs all look like > duplicates: > > CVE-2018-17985: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 > CVE-2018-18484:

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

other static variables in libiberty that face the same issue ? Cheers Nick libiberty/ChangeLog 2018-11-29 Nick Clifton PR 87681 PR 87675 PR 87636 PR 87335 * cp-demangle.c (demangle_recursion_limit): New static variable

RFA/RFC: Add stack recursion limit to libiberty's demangler

of this new feature, should it be accepted into libiberty. Patches: include/ChangeLog 2018-11-29 Nick Clifton * demangle.h (DMGL_RECURSE_LIMIT): Define. (cplus_demangle_set_recursion_limit): Prototype. libiberty/ChangeLog 2018-11-29 Nick Clifton PR 87675 PR

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, > I'm getting a bootstrap failure: *sigh* yes - my bad. Fortunately a patch has already been posted: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01039.html And I think that it has now been approved. Cheers Nick

Re: [tree.c] Replace cast to (char *) by const_cast

Hi Prathamesh, > I am getting the following build error with trunk: > ../../gcc/gcc/tree.c: In member function ‘void > escaped_string::escape(const char*)’: > ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to > type ‘char*’ casts away qualifiers [-Werror=cast-qual] >m_str

RFA: Restore ability to build zlib in a srcdir == builddir

Hi Guys, The patch below allows the zlib library to be built when the build directory is the same as the source directory. This patch has been in the binutils/gdb sources for a while now, but unfortunately was never copied to gcc. So I am trying to right that mistake now. OK to apply

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Jeff, Thanks for the review. > The docs still say "Control characters in the string will be replaced > with spaces", but they're being escaped now. That needs to be fixed. Done. > I note you overload the cast operator in your new class. Why not just > use an accessor? Was this style

Re: [PATCH] [configure] Added "nfp" to the build for binutils.

Hi Francois, > 2018-05-01 Francois H. Theron > > * configure.ac: Added "nfp" target. > * configure: Regenerate. I have applied this change patch to both the gcc and binutils mainline sources. Cheers Nick

Re: [PATCH] RX TARGET_RTX_COSTS function

Hi Oleg, > Ping. Sorry - I am not very good at spotting RX bugs on the gcc-patches list. :-( >> gcc/ChangeLog: >> * config/rx/rx.c (rx_rtx_costs): New function. >> (TARGET_RTX_COSTS): Override to use rx_rtx_costs. Approved - please apply. Cheers Nick

Re: plugin-api.h patch to add a new interface for linker plugins

Hi Cary, Hi Sriraman, >> Ping. Is this alright to apply now or should I wait for Stage 1? >> >> * plugin-api.h (ld_plugin_get_wrap_symbols): New >> plugin interface. > > I'd say go ahead and apply the patch in binutils, and wait for Stage 1 > to sync back to GCC, unless someone there OKs it

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, > Since the class manages a resource it should ideally make sure it > doesn't try to release the same resource multiple times.  I.e., its > copy constructor and assignment operators should either "do the right > thing" (whatever you think that is) or be made inaccessible (or declared

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi David, Attached is a revised version of the patch which I hope addresses all of your (very helpful) comments on the v3 patch. OK to apply once the sources are back on stage 1 ? Cheers Nick gcc/ChangeLog 2018-02-09 Nick Clifton <ni...@redhat.com> PR 84195 *

Re: [RX] Fix PR 83831 -- Unused bclr, bnot, bset insns

Hi Oleg, > OK for trunk? > gcc/ChangeLog: > > PR target/83831 > * config/rx/rx-protos.h (rx_reg_dead_or_unused_after_insn, > rx_copy_reg_dead_or_unused_notes, rx_fuse_in_memory_bitop): New > declarations. > (set_of_reg): New struct. > (rx_find_set_of_reg,

Re: RFA: Sanitize deprecation messages (PR 84195)

++ coding - it is not my strong point. I am an assembler level programmer at heart). Cheers Nick gcc/ChangeLog 2018-02-09 Nick Clifton <ni...@redhat.com> PR 84195 * tree.c (escaped_string): New class. Converts an unescaped string into its escaped equi

Re: RFA: Fix PR 68028: LTO error when compiling PowerPC binaries with single precision floating point

Hi Segher, > I thought you were going to do a patch like the following, to make the > e500 cores less special (they are not): Sorry - my bad. I defer to your patch then. Whatever it takes to get the BZ fixed and off the books... :-) Cheers Nick

RFA: Fix PR 68028: LTO error when compiling PowerPC binaries with single precision floating point

Nick gcc/ChangeLog 2018-02-08 Nick Clifton <ni...@redhat.com> * config/rs6000/rs6000.c (rs6000_option_override_internal): In LTO mode prefer function attributes over command line -mcpu setting. Index: gcc/config/rs6000/rs

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi David, >> + /* PR 84195: Replace control characters in the message with their >> + escaped equivalents. Allow newlines if -fmessage-length has >> + been set to a non-zero value. > > I'm not quite sure why we allow newlines in this case, sorry. Because the

Re: RFA: Sanitize deprecation messages (PR 84195)

decided to leave it for now. Fixing them will require mucking about in the C preprocessor library, which I did not fancy doing at the moment. So, is this enhanced patch OK now ? Cheers Nick gcc/ChangeLog 2018-02-07 Nick Clifton <ni...@redhat.com> PR 84195 *

Re: PING [PATCH] -mjsr option bug fix

Hi Sebastian, > +2018-01-05 Sebastian Perta > + > + * config/rx/constraints.md: added new constraint > CALL_OP_SYMBOL_REF > + to allow or block "symbol_ref" depending on value of TARGET_JSR > + * config/rx/rx.md: use CALL_OP_SYMBOL_REF in call_internal

Re: PING [PATCH] RX movsicc degrade fix

Hi Sebastian, Sorry for missing this one. If it helps in the future, feel free to ping me directly. > +2018-01-09 Sebastian Perta > + > + *config/rx.md: updated "movsicc" expand to be matched by GCC > + *testsuite/gcc.target/rx/movsicc.c: new test case

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, > My only suggestions are to consider how control characters and > excessively messages are handled in other contexts and adopt > the same approach here. Are there other places where user-supplied messages are displayed by gcc ? > In the tests I did, control characters > were mostly

Re: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

Hi Igor, >> Attached is a potential patch for PR 84145: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145 > Coincidentally, I have worked on the same patch. Great minds, etc :-) > Please look at the patch, I uploaded it to the bug. The main differences are > > - updated the output

RFA: Sanitize deprecation messages (PR 84195)

it simple. :-) No regressions with an x86_64-pc-linux-gnu toolchain. OK to apply ? Cheers Nick gcc/ChangeLog 2018-02-05 Nick Clifton <ni...@redhat.com> PR 84195 * tree.c (warn_deprecated_use): Sanitize deprecation messages. Index: gcc/

RFA: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

-mshstk % What do you think ? Is the patch OK for the mainline ? Cheers Nick gcc/ChangeLog 2018-02-05 Nick Clifton <ni...@redhat.com> PR 84145 * config/i386/i386.c (ix86_option_override_internal): Rework checks for -fcf-protection and -mibt/-mshstk.

Re: [RX] Fix PR 81819

Hi Oleg, > gcc/ChangeLog: > PR target/81819 > * config/rx/rx.c (rx_is_restricted_memory_address): > Handle SUBREG case. Go ahead make my day^H^H^H^H^H^H Approved - please apply. Cheers Nick

Re: [RX] Fix PR 81821

Hi Oleg, > OK for trunk and GCC 7? Approved. Do you have access to the repository, or would you like me to apply the patch for you ? Cheers Nick

Re: [PATCH 0/3] Add __builtin_load_no_speculate

Hi Guys, It seems to me that it might be worth taking a step back here, and consider adding a security framework to gcc. Mitigations for CVEs in the past have resulted in individual patches being added to gcc, oftern in a target specific manner, and with no real framework to support

Re: [PATCH] [MSP430] Pass -mcode/data-region to the linker and assembler

Hi Jozef, > The changes made in a series of binutils patches > (https://sourceware.org/ml/binutils/2017-08/msg00274.html) > to ld and gas require the -mcode/data-region options to be propagated > from gcc. > > The attached patch adds that functionality. Approved and applied. Cheers Nick

Re: [PATCH] [MSP430] Read mcu data from file instead of hardcoded data

Hi Jozef, > If the file is found then it is parsed, and the device passed to the > mmcu option is searched for. If the file or device aren't found, then > GCC uses the old hard-coded data instead. Whilst testing this patch with -mlarge enabled on the command line, I encountered this (new)

Re: [PATCH] [MSP430] [PR80993] Prevent lto removing interrupt handlers

Hi Jozef, > As reported in PR80993, enabling lto causes interrupt handlers to be > removed. This patch marks interrupt handlers as used, preventing them > from being optimized out. > > If the attached patch is acceptable, I would appreciate if someone could > commit it for me, as I do not have

Re: [PATCH 2/2] [MSP430] Fix issues handling .persistent attribute (PR 78818)

Hi Jozef, > Sorry, didn't mention in that last post that I don't have write access, > could someone please apply this for me. Applied. Sorry about the delay (again). Cheers Nick

Re: [PATCH 2/2] [MSP430] Fix issues handling .persistent attribute (PR 78818)

Hi Jozef, > Ok for trunk and gcc-7-branch? Approved - please apply (to both). Cheers Nick

Re: RFA: Enhance information recorded by -frecord-gcc-switches

Hi Jakub, >> Regardless, the point of this patch is to record which options were enabled, >> via >> whatever route, in the binaries. This can be useful to users, or >> distributors, >> who want to check that, for example, a specific security option was enabled, >> or >> that a particular a

Re: RFA: Enhance information recorded by -frecord-gcc-switches

Hi Richard, >>The -frecord-gcc-switches option records the gcc command line. It >>does not however expand options like -O2 into the optimizations that >>this enables. > > I think individually enabled passes by -On are not really useful information > as you generally cannot replace

RFA: Enhance information recorded by -frecord-gcc-switches

-06-08 Nick Clifton <ni...@redhat.com> * varasm.c (dump_enabled_to_asm_out_file): New function. Prints enabled options to the asm_out_file. (elf_record_gcc_switches): If verbose-asm is set then also dump all enabled options to the asm file. * to

Re: [PATCH 2/2] [MSP430] Fix issues handling .persistent attribute (PR 78818)

Hi Jozef, > Attached patch with the string wrapped in G_(). When I applied this patch to the sources and ran the new test, I encountered an internal compiler error: msp430-elf/gcc/xgcc [...] pr78818-auto-warn.c [...] [...] gcc/testsuite/gcc.target/msp430/pr78818-auto-warn.c: In function

Re: [PATCH] [MSP430] PR78838: Do not add section name prefixes when section name is .lowtext

Hi Josef, Thanks for reporting this problem, and providing a patch to fix it. I have checked your patch in, along with one, very very minor change to the formatting of the comment in gen_prefix(). Cheers Nick

Re: PR translation/80280

Hi Martin, > Rats! I ran into this when building for sparcv9-solaris2.11 but > didn't look at the cause of the error carefully enough to recognize > it was caused by my change so I just raised 80673 for it. It didn't > occur to me that targets defined their own format extensions like > this.

Re: PR translation/80280

Hi Martin, I am currently unable to build gcc for the x86_64-pc-cygwin target because gcc/config/i386/msformat-c.c uses the format_flag_spec struct but it has not been updated with the new field. :-( For example: gcc/config/i386/msformat-c.c gcc/config/i386/msformat-c.c:52:1:

Re: install.texi and arm

Hi Guys, >>> References to dependencies on really, really old versions of >>> binutils (talking 10+ years here) which I think we can remove. >>ARM-family processors. Subtargets that use the ELF object format >>require GNU binutils 2.13 or newer. Such subtargets include: >> Okay to

RFA: Patch for ARM PR77770

Hi Richard, Hi Ramana, The patch below is a simple fix for PR0. I am not really expecting you to agree with it, but I thought that it was worth posting so that this PR could be looked at again and maybe a better patch found. (Plus I am trying to close PRs so that the gcc 7 branch

RFA: Update XFAIL comments in

are not broken, it is just that, for these particular test cases, for these specific architectures (ARM, PPC), the unshrink- wrapped code is actually smaller than the shrink wrapped version. So - is it OK to apply the patch ? Cheers Nick gcc/testsuite/ChangeLog 2017-01-20 Nick Clifton

Re: [PATCH] Fix PR78189

en closing the PR ? Cheers Nick gcc/ChangeLog 2017-01-20 Richard Biener <rguent...@suse.de> Nick Clifton <ni...@redhat.com> PR testsuite/78421 * lib/target-supports.exp (check_effective_target_vect_hw_misalign): If the target is ARM return the

RFA: Fail gracefully when registering info for an unknown plugin

to apply ? Cheers Nick gcc/ChangeLog 2016-10-20 Nick Clifton <ni...@redhat.com> * plugin.c (register_plugin_info): Produce an error message if the plugin is not found in the hash table. Index: gcc/pl

Re: [PATCH, nds32] Enable GDB building for nds32*-*-* target.

Hi Yan-Ting, > After contributing our porting for GDB, we need a patch to enable GDB > building. > > Is this patch OK for commit? It is. I have applied the patch to the binutils sources. Please note however that the top level configure and configure.ac files are shared with the gcc project,

Commit: M32R: Build crtinit.o and crtfini.o

libgcc/ChangeLog 2016-07-19 Nick Clifton <ni...@redhat.com> * config.host (m32r): Add m32r/t-m32r to tmake_file. Add crtinit.o and crtfini.o to extra_parts. Index: libgcc/config.host === --- libgcc/config.host (re

Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

Hi Jeff, > I can buy that ;-) OK with a suitable ChangeLog entry. Thanks! Checked in with this changelog entry. Cheers Nick gcc/ChangeLog 2016-06-22 Nick Clifton <ni...@redhat.com> * dwarf2out.c (scompare_loc_descriptor): Use SCALAR_INT_MODE_P() in

Commit: MSP430: Rename entries in option enums

this. Tested with no regressions on an msp430-elf toolchain. Cheers Nick gcc/ChangeLog 2016-06-16 Nick Clifton <ni...@redhat.com> * config/msp430/msp430-opts.h (msp430_hwmult_types): Add MSP430_HWMULT_ prefix to enum values. (msp430_regions): Add MSP430_REGION_ prefix t

Re: [RX] Add support for atomic operations

Hi Oleg, > Sorry, but my original patch was buggy. There are two problems: Thanks for your diligence in checking the patch. > The attached patch fixes those issues. > OK for trunk? > > Cheers, > Oleg > > gcc/ChangeLog: > * config/rx/rx.md (FETCHOP_NO_MINUS): New code iterator. >

Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

Hi Jeff, >>> I may be missing something, but isn't it the transition to an FP >>> relative address rather than a SP relative address that's the problem >>> here? >> >> Yes, I believe so. >> >>> Where does that happen? I think that it happens in dwarf2out.c:based_loc_descr() which detects the

Commit: MSP430: Three small fixes

to extract the low 16 bits of a 20 bit pointer. Adding a simple pattern to the machine description file fixes this. Cheers Nick gcc/ChangeLog 2016-05-25 Nick Clifton <ni...@redhat.com> * config/msp430/msp430.c (msp430_attr): Produce an error if a static interrupt h

Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

Hi Jeff, >> Currently dwarf2out.c:mem_loc_descriptor() has some special case >> code to handle the situation where an address is held in a register >> whose mode is not of type MODE_INT. It generates a >> DW_OP_GNU_regval_type expression which may later on be converted into >> a frame

  1   2   3   4   5   >