Hi, GCC!
I believe netbsd is the primary user of the vax target. its status is:
good: netbsd uses gcc 5.4.0, and cross compiles its userland+kernel with
this. it runs and is also able to natively build useful programs like perl.
bad: -O0 in places, text relocations. obvious signs of more bugs
Hi folks,
netbsd's copy of GCC differs enough that it fails elsewhere with
gcc-trunk, but the problematic code is upstream.
updating netbsd to gcc 6.4.0, I get an internal compiler error building
libstdc++. (Long version: http://gnats.netbsd.org/53039)
Short version:
test.cc: In function 'bool
It turns out (all from krister, I am still totally lost) that it is not
failing for this specific reason in this case.
Rather, the attached patch from krister fixes it, saying that gcc
wants to change the label and then doesn't recognise the new insn
thinking the memory_operand predicate is not
(updating)
krister found a better hack patch which explains what the problem is,
adding a useless move at the end of the instruction, so the label is
not the last instruction.
(And, in the problem code, the last instruction in the function.)
---
hi folks,
i was interesting in tackling some problems gcc netbsd/vax has.
it has some ICEs which are in reload phase. searching around, the answer
to that is "switch to LRA first". Now, I don't quite know what that is
yet, but I know I need to try to do it.
As an initial step, I need to sync the
On Sun, Mar 31, 2019 at 01:25:50PM -0400, Paul Koning wrote:
>
>
> > On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote:
> >
> > hi folks,
> >
> > i was interesting in tackling some problems gcc netbsd/vax has.
> > it has some ICEs which are in reload phase. searching around, the answer
> > to
Just chiming in.
My buddy wrote a traditional C pre-processor for use with Imake (and,
presumably, other old things).
https://www.netbsd.org/~dholland/tradcpp/
(It's standalone).
On Fri, Sep 20, 2019 at 03:45:46PM -0600, Jeff Law wrote:
> Conditional branching patterns must support the label_ref and pc
> operands in either position. Everything else I've seen on this thread
> is just working around that broken aspect of the builtins.md file.
>
>
> (define_insn "jbbssiqi"
On Fri, Sep 20, 2019 at 11:15:32AM +, co...@sdf.org wrote:
> Removed from the diff. Unfortunately this introduces an ICE during the
> build of GCC...
I took another look at the VAX atomic pattern issue.
(http://gnats.netbsd.org/53039)
It is a compiler crash to do with the added atomic
On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
> Introducing the reversed jbb* patterns doesn't seem to help with the
> original issue. It crashes building libatomic.
My loose understanding of what is going on:
- GCC emits this atomic in expand.
- When cleaning up, it looks for
Sorry for the delay...
Updated diff: http://coypu.sdf.org/vax-gcc10.diff
On Mon, Apr 29, 2019 at 02:08:32PM -0600, Jeff Law wrote:
> On 3/30/19 3:03 AM, co...@sdf.org wrote:
> > hi folks,
> >
> > i was interesting in tackling some problems gcc netbsd/vax has.
> > it has some ICEs which are in
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77470
--- Comment #1 from coypu ---
Created attachment 39560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39560=edit
Correct includes for libssp
This gets me a bit further, but I still have trouble using it.
For netbsd we have in stdi
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 39557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39557=edit
less bogus specfile for netbsd.
Attached a patch tha
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
apologies if this is invalid for vanilla GCC, I am very skeptical I will be
able to build it without the help of a package, which includes small changes.
configuring with --enable-libssp, I got
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Hello,
Building GCC 5.4.0 on netbsd 7.0.1 armv6hf I encounter failure like:
gcc.o:(.rodata+0x58c4): undefined reference to `host_detect_local_cpu(int, char
const**)'
I
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 39716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39716=edit
Errors in the build
Attached errors from the bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #4 from coypu ---
indeed in EXTRAOBJS I only have netbsd.o
I'll try to use arm*) instead, and will report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #6 from coypu ---
It is a local change bug! thanks.
I'll let you know if the build completes.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
This is the (currently latest) 20161218 snapshot.
int main() {
int num = 3;
int a;
switch (num
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
occasionally workarounds are needed for old libstdc++ versions, it would be
easier to do so with the help of a macro.
if the compiler used is not GCC, we can't check for GCC's
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Hi, I'm building a libc.
It doesn't use __attribute__((nonnull)) anywhere in stdio.h and other headers,
instead asserts in a convoluted way that the arguments aren't NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199
--- Comment #2 from coypu ---
To relay a comment on the netbsd bug,
"I don't think (the proposed idea) is correct and the real problem is that we
are linking libgcc first (again)."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199
--- Comment #1 from coypu ---
Maybe expose __clz_tab but only in the fallback definition case, and not make
it hidden.
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Bug report from building cmake on netbsd/vax with GCC 5.4.0
http://gnats.netbsd.org/52326
[ 88%] Building CXX object
Source/CMakeFiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #3 from coypu ---
$ /usr/pkg/gcc7/bin/gfortran -Wl,--verbose test.f95 |grep succeeded |sort -u
..
attempt to open /usr/lib/crt0.o succeeded
attempt to open /usr/lib/crtbegin.o succeeded
attempt to open /usr/lib/crtend.o succeeded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #1 from coypu ---
Related and possible duplicate for dfly: libgcc/61309
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
building a simple fortran hello world:
/usr/bin/ld: a.out: hidden symbol `__cpu_model' in
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/libgcc.a(cpuinfo.o) is referenced by
DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #10 from coypu ---
(In reply to H.J. Lu from comment #9)
>
> This may break Linux. You may want to investigate if this approach:
>
> commit 6e6c7fc1e15525a10f48d4f5ac2edd853e2f5cb7
> Author: nsz <nsz@138bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #8 from coypu ---
Created attachment 41317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41317=edit
Unbreak NetBSD following r243219
This patch works for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
--- Comment #2 from coypu ---
Created attachment 42103
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42103=edit
-mieee, asserts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
--- Comment #3 from coypu ---
Created attachment 42104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42104=edit
-mieee -mfp-trap-mode=n, doesn't assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
--- Comment #4 from coypu ---
sorry, I attached an object file rather than assembly. I am guessing it's good
enough.
I am passing only -mieee to make it fail.
(If I use instead -mieee -mfp-trap-mode=n, it doesn't fail, and I get a very
similar
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
background:
gcc 8.0.0 20170827
netbsd-8.99.2/alpha, 21264
the following test case asserts if built with -mieee, but not without:
#include
#include
#include
int
main (void
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
stack_probe on x86 is "or 0 offset(%rsp)".
it's not a no-op because it isn't atomic.
Related:
https://github.com/golang/go/issues/20427
https://lkml.org/lkml/2017/11/10/188
https:/
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 44175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44175=edit
Fixes configure for me
Out of the box (+3 patches I would like to get merged
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 44176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44176=edit
move linux specfile stuff to linux file.
when I build trunk I get in libgomp/config.log can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
1 - 100 of 142 matches
Mail list logo
