On Sat, Jul 28, 2018 at 08:47:33PM +0200, Andreas Schwab wrote:
> On Jul 28 2018, sly...@inbox.ru wrote:
>
> > From: Sergei Trofimovich
> >
> > Cc: Ian Lance Taylor
> > Cc: Jeff Law
> > Cc: Andreas Schwab
> > Signed-off-by: Sergei Trofimovich
> > ---
> > libgcc/config/m68k/lb1sf68.S | 19 +++
On Mon, Feb 21, 2022 at 09:25:43AM -0800, Ian Lance Taylor via Gcc-patches
wrote:
> Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
> using uc_regs instead of regs, which does look correct to me.
Yes, this is absolutely the correct fix. Having pt_regs appear at all
in code n
On Sun, Mar 06, 2022 at 10:22:56AM -0500, Rich Felker wrote:
> On Mon, Feb 21, 2022 at 09:25:43AM -0800, Ian Lance Taylor via Gcc-patches
> wrote:
> > Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
> > using uc_regs instead of regs, which does look corre
s.
> (dumpregs): Ditto.
> ---
> Changes since v1: Use .gp_regs/.gregs instead of .regs based on
> feedback by Rich Felker, thereby avoiding the need to include
> asm/ptrace.h for struct pt_regs.
>
> libgo/runtime/go-signal.c | 25 +
> 1 file ch
On Mon, Mar 07, 2022 at 02:59:02PM -0800, Ian Lance Taylor wrote:
> On Sun, Mar 6, 2022 at 11:11 PM wrote:
> >
> > +#ifdef __PPC64__
> > + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gp_regs[32];
> > +#else
> > + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[32];
> > +#
On Wed, Mar 09, 2022 at 08:26:11AM +0100, Sören Tempel wrote:
> Ian Lance Taylor wrote:
> > Have you tested this in 32-bit mode? It does not look correct based
> > on the glibc definitions. Looking at glibc it seems that it ought to
> > be
>
> As stated in the commit message, I have only tested
On Tue, Nov 16, 2021 at 03:40:00PM +0100, Dragan Mladjenovic wrote:
> Hi,
>
> Looks fine to me. If possible, maybe it should even be back-ported
> to stable branches.
>
> Not sure if MIPS assembly sources (if any) in musl would need
> explicit ..note.GNU-stack
>
> to complement this?
What are t
ls available so that support gets detected.
2015-09-14 Rich Felker
* config/gnu-user.h (GNU_USER_TARGET_STARTFILE_SPEC): use
rcrt1.o for static-linked PIE.
* gcc.c (LINK_PIE_SPEC): pass --no-dynamic-linker to linker
for static-linked PIE.
--- gcc-5.2.0.orig/gcc/co
On Tue, Sep 29, 2015 at 09:34:07PM -0400, Rich Felker wrote:
> This is the gcc side support of the static-linked PIE functionality
> added to binutils in commit 9b8b325a1f4cdaf235e7d803849dde6ededec865:
And unfortunately I wasn't aware of this:
https://gcc.gnu.org/git/?p=gcc.git;a=c
This is a forward-port of the abandoned SH FDPIC patch from 2010:
https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html
I'm submitting it at this point for initial review, not to be applied
right away; I would not be surprised if some changes are needed. It
applies on top of gcc 5.2.0 with the
On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote:
> On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote:
> > This is a forward-port of the abandoned SH FDPIC patch from 2010:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html
> >
> > I&
On Thu, Oct 01, 2015 at 07:39:10PM -0400, Rich Felker wrote:
> On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote:
> > On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote:
> > > This is a forward-port of the abandoned SH FDPIC patch from 2010:
> > >
>
On Fri, Oct 02, 2015 at 10:51:03PM +0900, Oleg Endo wrote:
> On Thu, 2015-10-01 at 21:30 -0400, Rich Felker wrote:
>
> > If you have any other general comments on the patch in the mean time
> > I'd be happy to hear them.
>
> Below are some comments. Might be a bi
On Sat, Oct 03, 2015 at 06:57:56AM +0900, Kaz Kojima wrote:
> Rich Felker wrote:
> > I worked around it and opened an issue for it:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67812
> >
> > But trying the patch on vanilla GCC trunk without my usual
On Sat, Oct 03, 2015 at 05:17:53PM +0900, Oleg Endo wrote:
> On Sat, 2015-10-03 at 00:50 -0400, Rich Felker wrote:
>
> > I have -mfdpic in the self-specs when FDPIC_DEFAULT is defined, so I
> > think only the positive form is needed.
>
> Having positive and negative
On Thu, Oct 01, 2015 at 09:30:17PM -0400, Rich Felker wrote:
> But trying the patch on vanilla GCC trunk without my usual J2 target
> setup revealed some additional issues I need to address. I'm getting
> ICE in the code that generates the libgcc bitshift calls, which
> weren'
On Sat, Oct 03, 2015 at 03:12:16PM -0400, Rich Felker wrote:
> On Thu, Oct 01, 2015 at 09:30:17PM -0400, Rich Felker wrote:
> > But trying the patch on vanilla GCC trunk without my usual J2 target
> > setup revealed some additional issues I need to address. I'm getting
>
On Fri, Oct 02, 2015 at 11:18:32AM -0400, Rich Felker wrote:
> > > +#ifdef __FDPIC__
> > > +#define udiv_qrnnd(q, r, n1, n0, d) \
> > > + do {
> > > \
> > > +
On Sun, Oct 04, 2015 at 02:10:42PM +0900, Oleg Endo wrote:
> On Sat, 2015-10-03 at 18:34 -0400, Rich Felker wrote:
> > >
> > > I found and fixed the problem, but I have a new concern: calls to the
> > > new shift instructions are using the following address forms:
On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote:
> On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote:
> > This is a forward-port of the abandoned SH FDPIC patch from 2010:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html
> >
> > I&
On Tue, Oct 06, 2015 at 09:39:20PM +0900, Oleg Endo wrote:
> On Mon, 2015-10-05 at 23:15 -0400, Rich Felker wrote:
> > Attached is the initial version of the patch against trunk. I've fixed
> > the functional issues I'm aware of from the previous version: ICE in
> >
On Wed, Oct 07, 2015 at 07:22:59AM +0900, Oleg Endo wrote:
> On Tue, 2015-10-06 at 12:52 -0400, Rich Felker wrote:
> > > > + if (TARGET_FDPIC)
> > > > +{
> > > > + rtx a = force_reg (Pmode, plus_constant (Pmode, XEXP (tramp_mem,
> &g
Attached is a hopefully near-ready-for-commit version of the SH/FDPIC
patch. I believe I've addressed all comments by Oleg and Kaz on the
previous versions of the patch. I'm still working on drafting the
Changelog entry (there's a lot to go in it, and I might very well be
going into more detail tha
On Wed, Oct 21, 2015 at 10:17:51PM +0900, Oleg Endo wrote:
> Rich,
>
> Thanks for the updated patch.
> Please do not start new threads for a continuation of an existing
> thread. This makes it difficult to track in the archives.
>
> On Tue, 2015-10-20 at 23:41 -04
Jacobowitz
Joseph Myers
Mark Shinwell
Andrew Stubbs
Rich Felker
gcc/
* config.gcc: Handle --enable-fdpic.
* config/sh/constraints.md: Add Ccl constraint.
* config/sh/linux.h (SUBTARGET_LINK_EMUL_SUFFIX): Hand
On Mon, Oct 26, 2015 at 12:32:01PM +, Szabolcs Nagy wrote:
> On 23/10/15 21:20, Joseph Myers wrote:
> >On Fri, 23 Oct 2015, Szabolcs Nagy wrote:
> >
> >>i think bsd libcs do the same, compiler headers interfering
> >>with libc headers is problematic (e.g. FLT_ROUNDS is wrong
> >>in gcc float.h,
On Mon, Oct 26, 2015 at 11:42:37PM +, Joseph Myers wrote:
> On Mon, 26 Oct 2015, Rich Felker wrote:
>
> > musl explicitly does not support using a mix of libc headers and
> > compiler-provided freestanding headers. While there may be
>
> In that case the GCC port
On Tue, Oct 27, 2015 at 12:16:16AM +, Joseph Myers wrote:
> On Mon, 26 Oct 2015, Rich Felker wrote:
>
> > On Mon, Oct 26, 2015 at 11:42:37PM +, Joseph Myers wrote:
> > > On Mon, 26 Oct 2015, Rich Felker wrote:
> > >
> > > > musl explicitly does n
On Sun, Oct 25, 2015 at 11:28:51PM +0900, Oleg Endo wrote:
> On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote:
> > Here's my updated version of the FDPIC patch with all requested
> > changes made and Changelog added. I've included all the original
> > authors
On Tue, Oct 27, 2015 at 11:01:39PM +0900, Oleg Endo wrote:
> On Mon, 2015-10-26 at 22:47 -0400, Rich Felker wrote:
> > On Sun, Oct 25, 2015 at 11:28:51PM +0900, Oleg Endo wrote:
> > > On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote:
> > > > Here's my upda
On Wed, Nov 11, 2015 at 11:36:26PM +0900, Oleg Endo wrote:
> On Tue, 2015-11-10 at 15:07 -0500, Rich Felker wrote:
>
> > > The way libcalls are now emitted is a bit unhandy. If more special
> > > -ABI
> > > libcalls are to be added in the future, they all have t
On Wed, Nov 11, 2015 at 09:56:42AM -0500, Rich Felker wrote:
> > > I'm actually
> > > trying to prepare a simpler FDPIC patch for other gcc versions we're
> > > interested in that's not so invasive, and for now I'm just having
> > >
k entirely if possible. I
tried non-FDPIC with it disabled and did not experience any problems;
I suspect it was written to work around a bug that no longer exists.
2015-11-13 Rich Felker
gcc/
* config/sh/sh.md (symGOT_load): Suppress __stack_chk_guard
address loading hack
On Fri, Nov 13, 2015 at 09:58:30PM +0100, Bernd Schmidt wrote:
> On 11/13/2015 06:11 PM, Szabolcs Nagy wrote:
> >Followup to https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01433.html
> >
> >The posix_memalign declaration is incompatible with musl libc in C++,
> >because of the exception specificatio
On Sat, Nov 14, 2015 at 09:24:32AM +0900, Kaz Kojima wrote:
> Rich Felker wrote:
> > The "chk_guard_add" pattern used for loading the GOT slot address for
> > __stack_chk_guard hard-codes use of r12 as a fixed GOT register and
> > thus is not suitable for FDPIC, w
On Sun, Nov 15, 2015 at 02:08:34PM +0900, Oleg Endo wrote:
> On Wed, 2015-11-11 at 09:56 -0500, Rich Felker wrote:
>
> > Sorry, I don't really understand RTL well enough to make a code
> > snippet. What I want to express is that an insn "uses" (in the (us
On Fri, Nov 15, 2019 at 01:22:20PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 15, 2019 at 06:58:24PM +, Szabolcs Nagy wrote:
> > 2019-11-15 Szabolcs Nagy
> >
> > * configure.ac (gcc_cv_target_ldbl128): Set for *-musl* targets.
>
> That is not what the patch does. It sets it to yes
On Sun, Nov 17, 2019 at 11:31:02AM -0700, Jeff Law wrote:
> On 11/15/19 3:00 AM, Szabolcs Nagy wrote:
> > The gthr weak reference based single thread detection is unsafe with
> > static linking and in case of dynamic linking it's ineffective on musl
> > since pthread symbols are defined in libc.so.
On Mon, Nov 27, 2017 at 03:48:41PM +, Szabolcs Nagy wrote:
> On 28/10/17 05:08, Jeff Law wrote:
> > On 10/13/2017 02:26 PM, Wilco Dijkstra wrote:
> >> For larger frames the first oddity is that there are now 2 separate params
> >> controlling how probes are generated:
> >>
> >> stack-clash-prot
On Wed, Sep 26, 2018 at 11:10:29AM -0700, H.J. Lu wrote:
> Add -mzero-caller-saved-regs=[skip|used|all] command-line option and
> zero_caller_saved_regs("skip|used|all") function attribue:
Minor nit, but could this be named -mzero-call-clobbered-regs?
"Caller-saved" is a misnomer and inconsistent
On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote:
> On 05/21/14 21:59, Rich Felker wrote:
> >On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote:
> >>On Wed, May 21, 2014 at 3:59 AM, Rich Felker wrote:
> >>>Bug # 61144 is a regression in 4.9.0 tha
On Mon, Jun 09, 2014 at 03:40:44PM +0400, Alexander Monakov wrote:
>
>
> On Fri, 6 Jun 2014, Rich Felker wrote:
>
> > On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote:
> > > On 05/21/14 21:59, Rich Felker wrote:
> > > >On Wed, May 21, 2014 at
Ping. Do you have any feedback on my tests? What is the next step?
Rich
On Mon, Jun 09, 2014 at 03:40:44PM +0400, Alexander Monakov wrote:
>
>
> On Fri, 6 Jun 2014, Rich Felker wrote:
>
> > On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote:
> > > On 05/21/
On Mon, Jun 16, 2014 at 11:06:04AM +0200, Jan Hubicka wrote:
> >
> > Are the attached files acceptable?
>
> The testcase looks OK to me, but it already should be fixed on mainline
> by patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01315.html that
> prevents dummy to be marked as constant.
On Mon, Jun 16, 2014 at 06:05:19PM +0200, Jan Hubicka wrote:
> > > This needs your decl_replaceable change to not be optimized to if (0),
> > > because of the explicit const modifier.
> >
> > The case I care about actually has "dummy" as const (with the intent
> > that it be allocated in a read-on
On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
> With relax branch in 32-bit, there are 2 cases:
>
> 1. PIC or PIE: We generate
>
> set up EBX
> relax call foo@PLT
>
> It is almost the same as we do now, except for the relax prefix.
> If foo is defined in another shared library or may
On Fri, May 15, 2015 at 01:35:14PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 1:23 PM, Rich Felker wrote:
> > On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
> >> With relax branch in 32-bit, there are 2 cases:
> >>
> >> 1. PIC or PIE: We gene
On Fri, May 15, 2015 at 04:14:07PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka wrote:
> > Hello,
> >>
> >> There are codes like
> >>
> >> extern void foo (void);
> >>
> >> void
> >> bar (void)
> >> {
> >> foo ();
> >> }
> >>
> >> Even with LTO, compiler may have to assum
On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:30 PM, H.J. Lu wrote:
> > On Fri, May 15, 2015 at 4:14 PM, H.J. Lu wrote:
> >> My relax branch proposal works even without LTO.
> >>
> >
> > I will borrow GOTPCREL from x86-64 and do
> >
> > [hjl@gnu-6 relax-4]$
On Sat, May 16, 2015 at 11:59:56AM -0700, H.J. Lu wrote:
> On Sat, May 16, 2015 at 7:19 AM, H.J. Lu wrote:
> > On Fri, May 15, 2015 at 4:49 PM, Rich Felker wrote:
> >> On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
> >>> On Fri, May 15, 2015 at 4:30 PM,
On Tue, May 19, 2015 at 04:43:53PM +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 15 May 2015, Rich Felker wrote:
>
> > Forget lazy binding. It's dead anyway because serious distros want
> > PIE+relro+bindnow+...
>
> You keep saying this, but I can't help
On Tue, May 19, 2015 at 06:01:07PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Jeff Law wrote:
>
> > > > Forget lazy binding. It's dead anyway because serious distros want
> > > > PIE+relro+bindnow+...
> > >
> > > You keep saying this, but I can't help the feeling it's mostly beca
On Tue, May 19, 2015 at 11:59:00AM -0700, Richard Henderson wrote:
> On 05/19/2015 11:06 AM, Rich Felker wrote:
> > I'm still mildly worried that concerns for supporting
> > relaxation might lead to decisions not to optimize code in ways that
> > would be difficult to re
On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson
> >> wrote:
> >>> On 05/19/2015 11:06
On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson
> >> wrote:
> >> >
On Tue, May 19, 2015 at 05:10:11PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 1:54 PM, Rich Felker wrote:
> > On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> >> > On Tue, May 19, 2015 at 1
On Wed, May 20, 2015 at 02:10:41PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Richard Henderson wrote:
>
> > It is. The relaxation that HJ is working on requires that the reads
> > from the got not be hoisted. I'm not especially convinced that what
> > he's working on is a win.
On Tue, Apr 21, 2015 at 01:58:02PM +, Matthew Fortune wrote:
> Szabolcs Nagy writes:
> > Set up dynamic linker name for mips.
> >
> > gcc/Changelog:
> >
> > 2015-04-16 Gregor Richards
> >
> > * config/mips/linux.h (MUSL_DYNAMIC_LINKER): Define.
>
> I understand that mips musl is o32
On Mon, May 04, 2015 at 11:42:20AM -0600, Jeff Law wrote:
> On 05/04/2015 11:39 AM, Jakub Jelinek wrote:
> >On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote:
> >>On 05/04/2015 10:37 AM, Alexander Monakov wrote:
> >>>This patch introduces option -fno-plt that allows to expand calls that
> >
On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov wrote:
> On Wed, 6 May 2015, Jakub Jelinek wrote:
> > The linker would know very well what kind of relocations are used for
> > particular PLT slot, and for the new relocations which would resolve to the
> > address of the .got.plt slot it
On Wed, May 06, 2015 at 11:26:29AM -0700, H.J. Lu wrote:
> On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
> > On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov wrote:
> >> On Wed, 6 May 2015, Jakub Jelinek wrote:
> >> > The linker would know very wel
On Wed, May 06, 2015 at 11:44:57AM -0700, H.J. Lu wrote:
> On Wed, May 6, 2015 at 11:37 AM, Rich Felker wrote:
> > On Wed, May 06, 2015 at 11:26:29AM -0700, H.J. Lu wrote:
> >> On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
> >> > On Wed, May 06, 2015 at 07:43
On Wed, May 06, 2015 at 12:05:20PM -0700, H.J. Lu wrote:
> >> -Bsymbolic will bind all references to local definitions in shared
> >> libraries,
> >> with and without visibility, weak or non-weak. Compiler can use it
> >> in binds_tls_local_p and we can generate much better codes in shared
> >> l
On Fri, May 08, 2015 at 02:25:11PM +, Matthew Fortune wrote:
> H.J. Lu writes:
> > On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy
> > wrote:
> > >
> > >
> > > On 21/04/15 15:59, Matthew Fortune wrote:
> > >> Rich Felker writes:
>
On Fri, May 08, 2015 at 03:41:31PM +0100, Szabolcs Nagy wrote:
> > I.e. as it stands this patch is not OK for backporting to GCC 5
> > without further discussion.
> >
> > There is also the perspective that we should be able to aim for
> > an ABI variant agnostic dynamic linker at some point over t
On Fri, May 08, 2015 at 04:50:28PM +, Joseph Myers wrote:
> On Fri, 8 May 2015, Rich Felker wrote:
>
> > On Fri, May 08, 2015 at 03:41:31PM +0100, Szabolcs Nagy wrote:
> > > > I.e. as it stands this patch is not OK for backporting to GCC 5
> >
On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote:
> On Fri, Apr 17, 2015@4:59 AM, Jakub Jelinek wrote:
> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
> >> > creating yet another library for that.
> >>
On Sat, May 09, 2015 at 10:41:41AM -0700, H.J. Lu wrote:
> On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy wrote:
> > * H.J. Lu [2015-04-17 05:36:30 -0700]:
> >> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
> >> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> >> > I don't
On Mon, May 11, 2015 at 12:31:51PM +0200, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote:
> >
> >
> > On 09/05/15 19:57, Szabolcs Nagy wrote:
> > > * H.J. Lu [2015-05-09 10:41:41 -0700]:
> > >> There are
> > >>
> > >> 4: 2b70 806 FUNCG
On Mon, May 11, 2015 at 01:48:03PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2015, Rich Felker wrote:
>
> > I don't see how this case is improved unless GCC is failing to consider
> > strong definitions in the same TU as locally-binding.
>
> Interpo
On Thu, Mar 05, 2015 at 06:39:10AM -0800, H.J. Lu wrote:
> On Wed, Mar 4, 2015 at 3:26 PM, H.J. Lu wrote:
> > Protected symbol means that it can't be pre-emptied. It
> > doesn't mean its address won't be external. This is true
> > for pointer to protected function. With copy relocation,
> > add
On Tue, May 21, 2019 at 05:28:51PM +0200, Christophe Lyon wrote:
> On Wed, 15 May 2019 at 18:06, Rich Felker wrote:
> >
> > On Wed, May 15, 2019 at 03:59:39PM +, Szabolcs Nagy wrote:
> > > On 15/05/2019 16:37, Rich Felker wrote:
> > > > On Wed, May 15,
On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> On 04/11/18 09:05, Stafford Horne wrote:
> > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> >> On 27/10/18 05:37, Stafford Horne wrote:
> ...
> >>> +#undef LINK_SPEC
> >>> +#define LINK_SPEC "%{h*} \
On Tue, Jul 16, 2019 at 11:34:06AM +0100, Richard Sandiford wrote:
> > diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> > index 66ec0ea..d7cc923 100644
> > --- a/gcc/config/arm/linux-eabi.h
> > +++ b/gcc/config/arm/linux-eabi.h
> > @@ -89,7 +89,7 @@
> > #define MUSL_DYNAMIC
On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote:
> On 15/05/2019 13:39, Christophe Lyon wrote:
> > In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> > -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> > for executables rather than shared li
On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote:
> On Wed, 15 May 2019 at 16:37, Rich Felker wrote:
> >
> > On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote:
> > > On 15/05/2019 13:39, Christophe Lyon wrote:
> > > > In FDPIC mode, w
On Wed, May 15, 2019 at 03:59:39PM +, Szabolcs Nagy wrote:
> On 15/05/2019 16:37, Rich Felker wrote:
> > On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote:
> >> On Wed, 15 May 2019 at 16:37, Rich Felker wrote:
> >>> On Wed, May 15, 2019 at 01:55:3
On Sun, Oct 15, 2017 at 06:16:57AM -0700, H.J. Lu wrote:
> crt1.o is used to create dynamic and non-PIE static executables. Static
> PIE needs to link with Pcrt1.o, instead of crt1.o, to relocate static PIE
> at run-time. When -pg is used with -static-pie, gPcrt1.o should be used.
>
> Tested on
On Mon, Aug 24, 2015 at 06:25:14PM +0200, Szabolcs Nagy wrote:
> * David Edelsohn [2015-08-24 10:21:05 -0400]:
> > Patch v2.
> >
> > Powerpc does not include the top level linux.h, so I had to
> > repeat the include order fixes from there in rs6000/sysv4.h.
> >
> > I corrected the endianness han
A missing * in the pattern for sh targets prevents the --with-cpu
configure option from being accepted for certain targets (e.g. ones
with explicit endianness, like sh2eb).
The latest config.sub should also be pulled from upstream since it has
a fix for related issues.
Rich
--- gcc-5.2.0.orig/gcc
The J2 Core is an open hardware cpu implementing the SH-2 instruction
set, with the addition of barrel shift instructions and an atomic
compare-and-swap instruction. This patch adds a cpu model option -mj2
to the sh target. Presently all it does is enable use of the barrel
shift instructions (and t
On Tue, Sep 01, 2015 at 10:45:10PM +0900, Oleg Endo wrote:
> Hi Rich,
>
> On 01 Sep 2015, at 02:49, Rich Felker wrote:
>
> > The J2 Core is an open hardware cpu implementing the SH-2 instruction
> > set, with the addition of barrel shift instructions and an ato
On Wed, Sep 02, 2015 at 01:24:55AM +0900, Oleg Endo wrote:
> > I'm not sure what the best way to achieve multiple goals is, but the
> > current behavior makes it so you need --isa=any (and a final binary
> > with weird ABI tag) to have a binary that supports atomic operations
> > on any SH model. m
I've started work on reviving the FDPIC support patch for the SH
target, which was proposed upstream in 2010 then abandoned:
https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01464.html
Right now I'm in the process of determining what parts can be applied
as-is to current gcc, and what parts need to
On Wed, Sep 02, 2015 at 07:59:45PM +, Joseph Myers wrote:
> On Wed, 2 Sep 2015, Rich Felker wrote:
>
> > Also, according to Joseph Myers, there was some unresolved
> > disagreement that stalled (and eventually sunk) the old patch, so if
> > anyone's still ar
On Wed, Sep 02, 2015 at 05:05:35PM -0400, Rich Felker wrote:
> On Wed, Sep 02, 2015 at 07:59:45PM +, Joseph Myers wrote:
> > On Wed, 2 Sep 2015, Rich Felker wrote:
> >
> > > Also, according to Joseph Myers, there was some unresolved
> > > disagreement that
On Thu, Sep 03, 2015 at 02:58:39PM +, Joseph Myers wrote:
> On Wed, 2 Sep 2015, Rich Felker wrote:
>
> > So if __fpscr_values was the only reason for patch 1/3 in the FDPIC
> > patchset, I think we can safely drop it. And patch 2/3 was already
> > committed, so 3/3,
On Thu, Sep 03, 2015 at 11:53:45AM -0400, Rich Felker wrote:
> On Thu, Sep 03, 2015 at 02:58:39PM +, Joseph Myers wrote:
> > On Wed, 2 Sep 2015, Rich Felker wrote:
> >
> > > So if __fpscr_values was the only reason for patch 1/3 in the FDPIC
> > > patchset, I
On Fri, Sep 04, 2015 at 06:04:15PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote:
> > One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces
> > different (less efficient) code from just gcc -mfdpic, which se
On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote:
> On Thu, Sep 03, 2015 at 11:53:45AM -0400, Rich Felker wrote:
> > On Thu, Sep 03, 2015 at 02:58:39PM +, Joseph Myers wrote:
> > > On Wed, 2 Sep 2015, Rich Felker wrote:
> > >
> > > > So if
On Thu, Sep 10, 2015 at 11:49:19PM -0400, Rich Felker wrote:
> On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote:
> > On Thu, Sep 03, 2015 at 11:53:45AM -0400, Rich Felker wrote:
> > > On Thu, Sep 03, 2015 at 02:58:39PM +, Joseph Myers wrote:
> > > > O
Bad patterns caused configure to always disable TLS for big-endian sh
targets and for anything other than sh 3/4.
Rich
--- gcc-5.2.0.base/gcc/configure.ac 2015-08-11 16:23:36.0 +
+++ gcc-5.2.0/gcc/configure.ac 2015-09-13 08:17:31.714972082 +
@@ -3300,7 +3300,7 @@
tls_f
On Sun, Sep 13, 2015 at 06:55:56PM +0900, Kaz Kojima wrote:
> Rich Felker wrote:
> > Bad patterns caused configure to always disable TLS for big-endian sh
> > targets and for anything other than sh 3/4.
>
> Could you please give a patch for the trunk with an appropriate
&g
On Fri, Sep 04, 2015 at 06:04:15PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote:
> > One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces
> > different (less efficient) code from just gcc -mfdpic, which se
On Mon, Sep 14, 2015 at 07:08:33AM +0900, Kaz Kojima wrote:
> Rich Felker wrote:
> > I'm pretty sure this will still apply to trunk, but I can check that
> > and add the changelog entry. Is there something I should read on the
> > form or just follow the example from my
On Mon, Sep 14, 2015 at 06:06:02PM +0100, Szabolcs Nagy wrote:
> On 14/09/15 17:58, Rich Felker wrote:
> >trunk. For the ChangeLog message, do I need to list both configure and
> >configure.ac or just the latter? And should configure be included in
> >the patch like I did, or
2015-09-14 Rich Felker
* gcc/configure.ac: Change target pattern for sh TLS support
test from "sh[34]-*-*" to "sh[123456789lbe]*-*-*".
* gcc/configure: Regenerate.
diff --git a/gcc/configure b/gcc/configure
index 846c996..6fb11a7 100755
--- a/gcc
On Fri, Nov 11, 2016 at 05:40:04PM +0100, Uros Bizjak wrote:
> On Fri, Nov 11, 2016 at 4:50 PM, Szabolcs Nagy wrote:
> > The __cpu_indicator_init and __cpu_model symbols are not safe to use
> > from shared libgcc_s.so from ifunc resolvers, so since gcc-6, only
> > the definitions from static libgc
Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc
due to aggressive and semantically-incorrect constant folding of weak
aliases. The attached patch seems to fix the issue. A weak alias
should never be a candidate for constant folding because it may always
be replaced by a stron
1 - 100 of 102 matches
Mail list logo
