): New macro.
* config/rx/rx.h (FLOAT_TYPE_SIZE): Remove.
(DOUBLE_TYPE_SIZE): Likewise.
(LONG_DOUBLE_TYPE_SIZE): Likewise.
Approved - please apply.
Cheers
Nick
Nick
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
is 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
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
>
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
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
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
;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
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
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[],
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
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
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
+
plish 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: "PR c++/101783
k 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.
>
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
>>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.
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 cv-qualifiers should
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 function
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
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
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
>> >
>> >
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
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
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
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
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
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
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
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
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
. 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
cause 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 versioning flags
configure: regenerate in all projects that use libtoo
y-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
errors from nms t
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 changed, 1
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
doing this however as I
am not an autoconf expert and I have no idea what the consequences might be.
Cheers
Nick
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
Hi JBG,
These three let it build. One done. Thanks for your support!
No worries. Patch pushed.
Cheers
Nick
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_
, ctx);
left_over -= 64;
- memcpy (ctx->buffer, >buffer[16], left_over);
+ memmove (ctx->buffer, >buffer[16], left_over);
}
ctx->buflen = left_over;
}
Cheers
Nick
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
Nic
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
+++
always
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
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 | 1 +
intl
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 into -L / -l form
bfd, opcodes, libctf: support --with-inc
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
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
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)
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
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
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
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): all-ld
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
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 | 4
+ 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
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
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.
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
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/
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 would
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
>
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,-Wdeprecated
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,-Wdeprecated
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
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
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
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-
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
--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
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
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
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))
>
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
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
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. GCC supp
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 n
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/
> >
>
e 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
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
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
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
n it over the weekend and try again on Monday.
Cheers
Nick
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
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 to get th
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
end again and sorry for wasting your time Joseph,
Nick
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
1 - 100 of 505 matches
Mail list logo
