---
gcc/config/netbsd.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/netbsd.h b/gcc/config/netbsd.h
index f2d6cc6..65ce943 100644
--- a/gcc/config/netbsd.h
+++ b/gcc/config/netbsd.h
@@ -96,6 +96,7 @@ along with GCC; see the file COPYING3. If not see
%{!pg:-lposix}}
On Wed, Jan 11, 2017 at 04:41:44PM +0100, Krister Walfridsson wrote:
> On Mon, 9 Jan 2017, co...@sdf.org wrote:
>
> >3 month ping, 1 week ping (trying again), etc...
>
> Apologies for not getting back to you sooner.
>
>
> >Like most operating systems, NetBSD has a libc which contains
> >stuff
Identical patch was committed to NetBSD in April 28, 2008.
https://github.com/jsonn/src/commit/7105def538f68e0a0034f5c93ec7fc384ca849b2
Like most operating systems, NetBSD has a libc which contains
stuff it needs for most programs to work, and people expect
it to be linked without explicitly specifying -lc.
This patch is needed for just about any program to work.
---
gcc/config/netbsd.h | 2 ++
1 file changed, 2 insertions(+)
3 month ping, 1 week ping (trying again), etc...
This patch has zero affect on non-netbsd users and was already
accepted in NetBSD years ago.
On Wed, Jan 04, 2017 at 11:24:27AM +, coypu wrote:
> Like most operating systems, NetBSD has a libc which contains
> stuff it needs for most pr
On Thu, Jun 29, 2017 at 05:23:37PM -0600, Jeff Law wrote:
> On 06/29/2017 09:51 AM, coypu wrote:
> > I was thinking of holding a party for the upcoming one year anniversary
> > of pinging this patch, that was committed to NetBSD's copy of GCC about
> > a decade ago. withou
Ping.
On Tue, Jun 20, 2017 at 08:05:42PM +, co...@sdf.org wrote:
> VAX' FFS as variable-length bit field instruction uses a "base"
> operand of type "vb" meaning "byte address".
> "base" can be 32 bits (SI) and due to the definition of
> ffssi2/__builtin_ffs() with the operand constraint "m",
I was thinking of holding a party for the upcoming one year anniversary
of pinging this patch, that was committed to NetBSD's copy of GCC about
a decade ago. without it, I can't compile simple programs.
---
gcc/config/netbsd.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
I paid extra attention to it because it appeared in the last line of a
build failure likely caused by shell tools differences. cd rarely outputs
the new directory for me.
VAX' FFS as variable-length bit field instruction uses a "base"
operand of type "vb" meaning "byte address".
"base" can be 32 bits (SI) and due to the definition of
ffssi2/__builtin_ffs() with the operand constraint "m", code can be
emitted which incorrectly implies a mode-dependent (= longword,
This script has the only occurrence of it, and in this line
it defines and exports it.
---
config-ml.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/config-ml.in b/config-ml.in
index 47f153350..58c80a35c 100644
--- a/config-ml.in
+++ b/config-ml.in
@@ -493,7 +493,6 @@ multi-do:
ping
On Fri, Oct 13, 2017 at 11:13:52AM -0600, Jeff Law wrote:
> So we can't depend on patches that OpenBSD applies. What's important is
> what is in the official GCC sources.
>
> I'd like to see some discussion about what these macros should look like
> for the *bsd ports. Merely removing them from
On Thu, May 24, 2018 at 06:31:25PM +0100, Jonathan Wakely wrote:
> On 24/05/18 16:14 +0100, Jonathan Wakely wrote:
> > On 24/05/18 13:14 +, co...@sdf.org wrote:
> > > In the past I was asked to post bugzilla patches here. I am doing this.
> > > It fixes a build failure.
> > >
> > > PR
On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
> On 05/24/2018 07:54 AM, Maya Rashish wrote:
> > Move linux-specific specfile definitions to linux.h
> > gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from
> > alpha/elf.h
> > ---
> > gcc/config/alpha/elf.h | 26
In the past I was asked to post bugzilla patches here. I am doing this.
It fixes a build failure.
PR target/85904
libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
libstdc++-v3/configure: Regenerate
Attached is patch.
>From ac7a1f364b0ca5e3a6a5a68a16266d1cb78ee5da Mon Sep 17 00:00:00
On Thu, May 24, 2018 at 01:32:17PM -0600, Jeff Law wrote:
> On 05/24/2018 01:17 PM, co...@sdf.org wrote:
> > On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
> >> On 05/24/2018 07:54 AM, Maya Rashish wrote:
> >>> Move linux-specific specfile definitions to linux.h
> >>>
Ping.
Anything else to do for this?
Thanks.
On Tue, Jun 19, 2018 at 03:31:55PM +, Joseph Myers wrote:
> On Sun, 4 Feb 2018, Maya Rashish wrote:
>
> > Of the currently supported BSDs:
> > - FreeBSD, doesn't have ansi.h or define _MACHINE_ANSI_H anywhere
> > in its other headers since the long-gone 5.x release.
> > - OpenBSD,
No need to have VMS in a separate elif case and a separate comment
for it saying the same thing.
No functional change intended.
---
gcc/ginclude/stddef.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h
index
ping, let me know if there is anything wrong with it.
ping
they're good patches. ask questions. I have more.
hi gcc-patches,
as part of pinging, i'll explain the story of this patch.
I want to make sure all netbsd archs work with upstream gcc.
in this case, netbsd/arm's EABI support.
I try to break up my changes into digestible chunks that are rational,
which is why this change came first.
building
On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
> I think strongarm would be a better choice. I'm not aware of anyone
> running NetBSD on Arm8 cpus.
Clarifying: this is the global default for all GCC ARM targets,
not just netbsd. Is strongarm still the preferred choice?
On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
> I think strongarm would be a better choice. I'm not aware of anyone
> running NetBSD on Arm8 cpus.
>
> Otherwise, this is fine with a suitable ChangeLog entry.
>
> R.
I hope this is OK. Thanks!
Maya Rashish
PR
Regarding target/86383, it wasn't sufficient to not just pick arm6 for
netbsd, as the default -mcpu is still arm6, which also fails to build.
I assume the default is expected to be the oldest support, and I think
now that's arm8, so maybe default to that.
diff --git a/gcc/config.gcc
Thanks for the detailed response.
Sorry to give only a partial reply.
On Tue, Oct 23, 2018 at 02:36:57PM +0100, Richard Earnshaw (lists) wrote:
> Thanks for posting this. Before we can commit it, however, we need to
> sort out the authorship and ensure that all the appropriate copyright
>
Thanks for the feedback. I made some improvements.
Changes from the first patch:
config.gcc:
need_64bit_hwint=yes No longer needed
resolve conflict from strongarm being default for netbsd.
switch default cpu for armv7--netbsdelf-eabi: cortex-a8 -> generic-armv7-a,
(make -mfpu=auto pick VFPv3-D16)
On Wed, Oct 31, 2018 at 03:23:27PM +, Richard Earnshaw (lists) wrote:
> On 31/10/2018 14:10, co...@sdf.org wrote:
> > +
> > +# Currently there is a bug somewhere in GCC's alias analysis
> > +# or scheduling code that is breaking _fpmul_parts in fp-bit.c.
> > +# Disabling function inlining is a
On Fri, Nov 02, 2018 at 11:04:06AM +, Richard Earnshaw (lists) wrote:
> Sorry about that. You don't really expect me to remember every patch I
> committed 18 years ago!
>
> And pedantically, that was a branch merge patch. The original commit
> (back in the CVS days) was:
>
>
> revision
Re-sending because my patch doesn't seem to appear on the archive
This matches to what netbsd is doing with its own copy of GCC,
it can be simpler.
PR target/87221:
config/netbsd-elf.h (NETBSD_STARTFILE_SPEC): use crtbeginS.o for PIE
(NETBSD_ENDFILE_SPEC): use crtendS.o for PIE
---
Hi folks,
This typo meant that HAVE_CC_TLS wasn't added to confdefs.h.
We run a potentially questionable setup where we save the results of
running configure for every architecture and then use it in subsequent
builds for reliability.
the addition of -DHAVE_CC_TLS wasn't saved to confdefs, so
(Oops, added the wrong email out of habit to the first reply :-))
On Tue, Jan 22, 2019 at 08:37:25PM +0100, Iain Buclaw wrote:
> > diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
> > index b0a315a3ed9..ca105c7635d 100644
> > --- a/gcc/d/d-builtins.cc
> > +++ b/gcc/d/d-builtins.cc
> > @@
Hi folks,
I was bitten by this, and it seemed like a few people online had similar
issues (for example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794).
We run a configure script from another configure script, to generate
auto-build.h.
Secondary configure might fail.
This failure isn't
ping.
I can provide a less scary patch to correct the typo if people are
afraid of the cleanup changes.
On Sun, Sep 16, 2018 at 01:00:21PM +0200, Andreas Schwab wrote:
> On Sep 03 2018, co...@sdf.org wrote:
>
> > config/tls.m4: Remove extra parentheses
>
> There are no extra parentheses.
>
For the benefit of the discussion, I've added the more minimal version
of the patch.
This is a weird
More pings!
On Fri, Mar 08, 2019 at 09:56:05AM +, co...@sdf.org wrote:
> Ping.
>
> Link for possible convenience :-)
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html
As far as I can tell, alpha can be emulated by QEMU.
VAX has SIMH. (Perhaps I should mention it somewhere? :))
Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.84
diff -u -r1.84
architecture list from netbsd src/tests/libexec/ld.elf_so/t_ifunc.c
(quick reference:
https://github.com/NetBSD/src/blob/trunk/tests/libexec/ld.elf_so/t_ifunc.c#L38 )
tested on netbsd/amd64.
ifuncs worked anyway, but I can't use target_clones without this change.
that is one very cool feature
Pinging again in the hope of getting the patch in, I'd like to have
less outstanding patches :) (I have quite a few and new releases
can become painful!)
gcc/ChangeLog
config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
config.host (arm*-*-netbsd*): Build driver-arm.o
Small addition for ARM. Since it doesn't have a geneirc way to detect
CPU features the code in libatomic relies on a linux-specific behaviour,
the ifunc condition is only defined for linux.
To unbreak compilation, I'd like to exclude netbsd/arm from the
libatomic ifunc camp :)
support for EABI configuration
config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
HOST_LIBGCC2_CFLAGS: workaround possible bug
config/arm/t-netbsd-eabi: New file.
>From c138b94b036e1485ed71c57966894e80f84fea1a Mon Sep 17 00:00:00 2001
From: coypu
Date: Wed, 31 Oct 2
Ping.
Link for possible convenience :-)
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html
On Wed, Jan 23, 2019 at 09:35:03AM +, co...@sdf.org wrote:
> > Is this necessary? I'd prefer to not set this field if it can be
> > avoided. The same goes for the others, I intend to remove them at
> > soonest convenience once the problematic parts of the front-end logic
> > has been
Hi folks,
This patch adds support for netbsd/aarch64.
It would be nice to have it committed, please tell me if anything is
wrong.
Thanks.
Matthew Green
Maya Rashish
gcc:
* config.gcc (aarch64*-*-netbsd*): New target.
* config/aarch64/aarch64-netbsd.h: New file.
*
This adds netbsd/hppa support. I tested it on the shiny new QEMU-git
which can now boot NetBSD too :-)
Files are very similar to the linux code.
Please let me know if any changes need to be made.
Matt Thomas
Nick Hudson
Matthew Green
Maya Rashish
gcc/ChangeLog:
config.gcc
On Fri, Jun 14, 2019 at 01:32:11PM -0400, John David Anglin wrote:
> >> +hppa*-*-netbsd*)
> >> + target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
> > Any reason to not use the PA 2.0 ISA? I'm virtually certain we
> > supported the 32bit ABI running on PA 2.0 hardware in hpbsd (which is
> >
pinging this with more changes:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01471.html
S A Free simulator does not exist.
HPPA and alpha are supported by QEMU.
https://wiki.qemu.org/Features/HPPA
https://wiki.qemu.org/Documentation/Platforms/Alpha
VAX is supported by SIMH.
I think copyright assignment is done. Thanks for bearing with me.
I noticed the version I submitted in April is missing some changes we
discussed on October 2018.
I took the patch from then and removed -matpcs too, the unnecessary
change to libgcc t-netbsd (which is the OABI configuration
The definition originates in
https://nxr.netbsd.org/xref/src/sys/arch/arm/include/sysarch.h#58
I've added the prefix SYSARCH to avoid any naming conflict concerns.
It looked a bit like an error on a first impression :-)
* config/arm/netbsd-elf.h (SYSARCH_ARM_SYNC_ICACHE): New definition.
On Tue, Apr 09, 2019 at 05:36:47PM +0100, Richard Earnshaw (lists) wrote:
> > So we're well into stage4 which means technically it's too late for
> > something like this. However, given it's limited scope I won't object
> > if the ARM port maintainers want to go forward. Otherwise I'll queue it
On Thu, May 23, 2019 at 05:11:30PM +0100, Richard Earnshaw (lists) wrote:
> On 23/05/2019 17:01, Richard Earnshaw (lists) wrote:
> > On 23/05/2019 15:11, Richard Earnshaw (lists) wrote:
> >> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote:
> >>> On 20/05/2019 20:24, Jeff Law wrote:
> On
On Fri, May 10, 2019 at 11:44:28AM +0100, Richard Earnshaw (lists) wrote:
> I was hoping to get a comment from one of the netbsd port maintainers on
> the changes to the common NetBSD code. Are they no-longer active?
Jason Thorpe said he can't contribute to GCC because of where he works.
Krister
This seems to be the way the rest of ira-color.c does it.
I hope it's OK. It does fix the segfault.
2019-09-10 Maya Rashish
PR target/85401
* ira-color.c: (allocno_copy_cost_saving) Call
ira_init_register_move_cost_if_necessary
diff --git a/gcc/ira-color.c
According to Bob Supnik (who is a very authoritative source on VAX),
> Funny you should ask. The short answer is no. No VAX ever did
> speculative or out of order execution.
As such, marking VAX as not needing speculation barriers.
PR target/86811
* config/vax/vax.c
re-posting, now CC'ing vmakarov who might be the right person to ping
about issues in this file. apologies for the noise if I'm wrong.
--
This seems to be the way the rest of ira-color.c does it.
I hope it's OK. It does fix the segfault.
2019-09-10 Maya Rashish
PR target/85401
On Fri, Sep 20, 2019 at 09:38:38AM -0600, Jeff Law wrote:
> this time -- removals would happen during the gcc-11 cycle.
Hi Jeff,
I'm concerned that if I don't reach this milestone for VAX, it'll mean
that future code review will require justifying some of the original
changes which is getting
On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> Yes, the patch is mostly ok. You can commit it into the trunk after
> applying changes mentioned below. If you do not have a write access, let me
> know I'll commit the patch by myself.
I don't have commit access. It would be
On Thu, Oct 10, 2019 at 09:41:35AM +0100, Maciej W. Rozycki wrote:
> On Wed, 9 Oct 2019, co...@sdf.org wrote:
>
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> > b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> > new file mode 100644
> > index 000..1d68d0b
> > ---
On Fri, Oct 04, 2019 at 02:28:55PM -0600, Jeff Law wrote:
> On 10/4/19 1:43 PM, co...@sdf.org wrote:
> > On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> >> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> >>> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> Yes, the
On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> > On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> >> Yes, the patch is mostly ok. You can commit it into the trunk after
> >> applying changes mentioned below. If you do not
On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> > On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
> >> Yes, the patch is mostly ok. You can commit it into the trunk after
> >> applying changes mentioned below. If you do not
On Tue, Nov 24, 2020 at 05:27:10AM +, Maciej W. Rozycki wrote:
> On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
>
> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be
I hope that writing the detailed commit message will encourage someone
with better knowledge of GCC internals to point out a better place for
this logic. I can follow through with any suggestions :)
On Sat, Feb 13, 2021 at 12:20:30PM +, Maya Rashish wrote:
> Some subtargets don't provide the
64 matches
Mail list logo
