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
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 branch as well. It i
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): Ne
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
Nic
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
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
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
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
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
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
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.
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
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
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
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():
https://
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
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
"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
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 a/li
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.
O
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
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
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 support
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/conf
Hi JBG,
These three let it build. One done. Thanks for your support!
No worries. Patch pushed.
Cheers
Nick
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 p
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 "&ctx->buffer[16]"
potentially overlaps with the destination buffer "ctx->buffer", which
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 to
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
+++
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
>>
>>
-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/
revised patch. 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
deprecated-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/l
deprecated-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/l
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-
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 data
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
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 wo
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
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
> non-relevant
./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
-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
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
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
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: libib
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
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 fixed
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
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 a
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 an
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 a
Hi Ian,
Is the patch OK with you ?
Cheers
Nick
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 used
the patch, although 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
li
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 not
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
>
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
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
>
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: https://gcc.gnu.org/bugzilla/show_b
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
se 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
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
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 =
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
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 som
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
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
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 so
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
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
PR 84195
* tree.c (escaped_string
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, rx_f
oor C++ coding - it is not my strong point. I am
an assembler level programmer at heart).
Cheers
Nick
gcc/ChangeLog
2018-02-09 Nick Clifton
PR 84195
* tree.c (escaped_string): New class. Converts an unescaped
string into its escaped equivalent.
(warn_deprecate
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
Nick
gcc/ChangeLog
2018-02-08 Nick Clifton
* config/rs6000/rs6000.c (rs6000_option_override_internal):
In LTO mode prefer function attributes over command line -mcpu
setting.
Index: gcc/config/rs6000/rs6000.c
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 documentation
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
PR 84195
* tree.c (warn_deprecated_use): Replace
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 and
> + call_value_interna
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
Approved - please apply.
Ch
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
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 mes
it simple. :-)
No regressions with an x86_64-pc-linux-gnu toolchain.
OK to apply ?
Cheers
Nick
gcc/ChangeLog
2018-02-05 Nick Clifton
PR 84195
* tree.c (warn_deprecated_use): Sanitize deprecation messages.
Index: gcc/tree.c
hstk to enable CET
% gcc -c main.c -fcf-protection=return -mshstk
%
What do you think ? Is the patch OK for the mainline ?
Cheers
Nick
gcc/ChangeLog
2018-02-05 Nick Clifton
PR 84145
* config/i386/i386.c (ix86_option_override_internal): Rework
checks fo
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
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
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 the
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
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) failure
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 wr
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
Hi Jozef,
> Ok for trunk and gcc-7-branch?
Approved - please apply (to both).
Cheers
Nick
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 pa
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 -
-06-08 Nick Clifton
* 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.
* toplec.c (print_switch_values
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 'm
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
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. W
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: error
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 yank
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
w
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
1 - 100 of 468 matches
Mail list logo