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

Hi Kewen, This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE defines in rx port, and add new port specific hook implementation rx_c_mode_for_floating_type. gcc/ChangeLog: * config/rx/rx.cc (rx_c_mode_for_floating_type): New function. (TARGET_C_MODE_FOR_FLOATING_TYPE):

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

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

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? 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: Problems when building NT kernel drivers with GCC / LD

Hi Pali, Hello! Just for a record, I filled individual issues to bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=30004 https://sourceware.org/bugzilla/show_bug.cgi?id=30139 https://sourceware.org/bugzilla/show_bug.cgi?id=30140 https://sourceware.org/bugzilla/show_bug.cgi?id=30141

Re: Problems when building NT kernel drivers with GCC / LD

Hi Pali, Hello! I would like to remind this thread for gcc/binutils developers. Most of these issues are still present and cause problems for compiling native PE binary. If you have questions or you need any other information please let me know. Have bug reports been filed for the individual

Re: Error: attempt to get value of unresolved symbol `L0'

Hi Pali, Hi Richard, Having file name and line number would be also useful as it took me some time to figure out where is the issue... Right - I have tried a little harder and come up with a follow up patch. This is now checked in, and given an input file that looks like this: % cat t.s

Re: Error: attempt to get value of unresolved symbol `L0'

Hi Pali, Hi Richard, Interesting... Another test case which is working fine: kernoffs: .word 0x4 - (. - 0x0) This works because this expression can be converted into an instruction and a relocation in the object file: % as t.s -o t.o % objdump -dr t.o Disassembly of section

Re: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)

Hi Thomas, +/* Linker supports '-v' option. */ +#define LINK_SPEC "%{v}" ..., Tom rightfully asked: [...] I wonder, normally we don't pass -v to ld, and need -Wl,-v for that. So, on my quest for making things uniform/simple, I now wonder: should we also forward GCC '-v' to binutils

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: Counting static __cxa_atexit calls

Hi Florian, What would be the most ELF-flavored way to implement this? After the final link, I expect that the count (or counts, we need a separate counter for thread-local storage) would show up under a new dynamic tag in the dynamic segment. This is actually a very good fit because older

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: [committed] exec-stack warning for test which wants executable stacks

Hi Jeff, Just FYI - I am also looking at adding in another warning. This time for when the linker creates a PT_LOAD segment which has all of the RWX flags set. At the moment my testing seems to show that it only causes problems when a custom linker script is used that defines its own

Re: [committed] exec-stack warning for test which wants executable stacks

Hi Jeff, I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other failures that have popped up over the last week.  Essentially all the nested

Re: [CVE] zlib (< 1.2.12) memory corruption

Hi Luis, There is a CVE [1] for zlib < 1.2.12 (released march 27th). GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory from GCC. The recommendation is to get it updated to 1.2.12, which contains the proper fix [2]. Right - I have now updated the binutils-gdb

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

Re: [CVE] zlib (< 1.2.12) memory corruption

Hi Luis, There is a CVE [1] for zlib < 1.2.12 (released march 27th). GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory from GCC. The recommendation is to get it updated to 1.2.12, which contains the proper fix [2]. I am all for updating the binutils-gdb copy of

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: Making *-netbsd-* to mean ELF not a.out for all CPUs

Hi John, But they did offer some tentative support for my second suggestion of changing the meaning of bare "netbsd" --- "netbsdaout" would still be available to unambiguously request a.out for anyone that wants it. I think that this would be OK for the binutils, providing that when

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

Accessing fields in the global_options structure from out-of-sync plugins

Hi Guys, With the annobin plugin for gcc I have a problem accessing some of the fields in the global_options structure. Although the plugin can use the macros defined in options.h, this only works if the plugin is in sync with gcc. If the plugin was built for one version of gcc, but

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

Fall 2017 GNU Toolchain Update

Hi Guys, A new version of GLIBC and a whole boatload of new GCC features means that there is lots to report this time. --- GLIBC: Version 2.26 is now out. There are loads of new features and bug fixes in this release.

Re: RFC: Update top level libtool files

Hi Joseph, > As per previous discussions on the issue: it's necessary to revert libtool > commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see > . OK - thanks for that pointer. > I do not know > if there are other local libtool

RFC: Update top level libtool files

Hi Guys, I would like to update the top level libtool files (libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by gcc, gdb and binutils. Currently we have version 2.2.7a installed in the source trees and I would like to switch to the latest official version:

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)

  1   2   3   4   5   6   >