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
t off doing this however as I
am not an autoconf expert and I have no idea what the consequences might be.
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
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
's many examples of this
on LLVM's side too, but I would prefer to stop the proliferation of
subtle differences like this that harm toolchain portability when
possible and when we can proactively address.
--
Thanks,
~Nick Desaulniers
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
On 5 Jan 2021, Alan Modra via Binutils told this:
> It doesn't apply due to gcc missing binutils 87279e3cef5b2c5 changes
> too. I could fix that easily enough but I'm going to ask that you
> post a combined patch to bring the gcc repo up to date with any libctf
> changes.
Oops! That never occurr
trunk directly so should definitely apply
this time. Sorry about that.
diff --git a/ChangeLog b/ChangeLog
index bd87d5fc6ee..0a352870cd6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2021-01-06 Nick Alcock
+
+ * Makefile.def: Sync with binutils-gdb:
+ (dependencies): a
A resend of something I sent over, sheesh, six months ago. Jeff Law acked it
but, well, it was six months ago. I think getting a re-ack might be a good
idea.
(Also... could someone push it for me? I should have push privs, but only on
binutils and I have yet to test them. Starting my pushing car
libctf wants a bsearch that takes a void * arg pointer to avoid a
nonportable use of __thread.
bsearch_r is required, not optional, at this point because as far as I
can see this obvious-sounding function is not implemented by anyone's
libc. We can easily move it to AC_LIBOBJ later if it proves n
libctf wants a bsearch that takes a void * arg pointer to avoid a
nonportable use of __thread.
bsearch_r is required, not optional, at this point because as far as I
can see this obvious-sounding function is not implemented by anyone's
libc. We can easily move it to AC_LIBOBJ later if it proves n
Hi Ian, Hi Nick,
Comping the GOLD linker with Clang has started producing this error
message:
In file included from gold/archive.cc:29:
include/libiberty.h:646:25: error: 'register' storage class
specifier is deprecated and incompatible with C++17
[-Werror,-W
Hi Ian, Hi Nick,
Compiling the GOLD linker with Clang has started producing this error
message:
In file included from gold/archive.cc:29:
include/libiberty.h:646:25: error: 'register' storage class
specifier is deprecated and incompatible with C++17
[-Werror,-W
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 Nick, Hi Ian,
>> In file included from gold/archive.cc:29:
>> include/libiberty.h:646:25: error: 'register' storage class
>> specifier is deprecated and incompatible with C++17
>> [-Werror,-Wdeprecated-register]
>>
>> So I w
-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 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
>>
>>
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.
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
+ 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
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
+++
61 | name, name);
|
I could not reproduce these in my local environment, but I suspect that
you are using a more recent version of gcc than me. The fix looks obvious
however, so please could you try out the attached patch and let me know
if it resolves the problem ?
Cheers
x->buffer, 64, ctx);
left_over -= 64;
- memcpy (ctx->buffer, &ctx->buffer[16], left_over);
+ memmove (ctx->buffer, &ctx->buffer[16], left_over);
}
ctx->buflen = left_over;
}
Cheers
Nick
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_
Hi JBG,
These three let it build. One done. Thanks for your support!
No worries. Patch pushed.
Cheers
Nick
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
h/my-nm where
*that* is a symlink to /usr/bin/nm.)
Cc: gcc-patches@gcc.gnu.org
ChangeLog
2021-06-22 Nick Alcock
PR libctf/27482
* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
NM, if there is one. Run nm on itself, not on /dev/null, to avoid
er
erate most
relevant configure scripts, skipping only sim/ because it's in a ferment
of change right now.)
Cc: gcc-patches@gcc.gnu.org
Nick Alcock (4):
libtool.m4: augment symcode for Solaris 11
libtool.m4: fix nm BSD flag detection
libctf: try several possibilities for linker ve
in
Android. They are currently playing whack-a-mole with
no_stack_protector. I'm not sure yet how we can better help them self
diagnose, or whether we should consider a change in policy.
I'm also not sure whether GCC's einliner corresponds with
always_inline or not necessarily?
--
Thanks,
~Nick Desaulniers
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/
> >
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.
501 - 531 of 531 matches
Mail list logo
