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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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 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
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 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #1 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #7 from coypu ---
I sent a patch to gcc-patches.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00896.html
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #12 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77800
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #7 from coypu
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #6 from coypu ---
I imagine I didn't write scheduling for the broken instruction, so it doesn't
ever happen. something silly like that, rather than it being a valid fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #5 from coypu ---
Created attachment 46872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46872=edit
providing instruction scheduling avoids this crash
So, I am trying to beat gcc/vax into shape and incorporate changes f
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77952
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #2 from coypu
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
> >
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929
coypu changed:
What|Removed |Added
Target|mips64-linux-gnuabi64 |mips64-linux-gnuabi64,
--- Comment #1 from
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
MIPS needs cache synchronization.
libgcc's __clear_cache expands to:
000119b0 <__clear_cache>:
119b0: 03e8jr ra
119b4:
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
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.
*
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
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
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
if I compile this code with -O3
typedef struct once_t {
int val;
int pto_done;
} once_t;
int
once_stub(once_t *o, void (*r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #44 from coypu ---
(In reply to jos...@codesourcery.com from comment #31)
> GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64),
Speaking for NetBSD only:
as of https://gcc.gnu.org/viewcvs/gcc?view=revision=253
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 :)
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
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
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
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
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
Ping.
Link for possible convenience :-)
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html
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
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
(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
> > @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #10 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421
--- Comment #5 from coypu ---
(In reply to Jakub Jelinek from comment #4)
> That is one header, not two, so why should that fenv.h's #include_next
> include that same header or some copy of that header in a different path?
I am in the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421
--- Comment #3 from coypu ---
include/c_compatibility/fenv.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794
--- Comment #4 from coypu ---
Hi,
It's probably a setup/configuration issue for everyone reporting this issue.
It's hard to debug, my patch helps with figuring out the problem - but doesn't
fix it.
I didn't ping this bug report because I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421
--- Comment #1 from coypu ---
suggested change: put #include_next outside of include guards?
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
I built GCC #1 (x86_64->sh3)
Now I'm trying to build GCC #2 (sh3->sh3) using GCC #1
during the build process,
libtool: compile: shle--netbsdelf-c++ --sysroot=/home/f
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88194
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #16 from coypu
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
---
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
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
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)
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #14 from coypu ---
Also, after these two patches, my own build of arm--netbsdelf is failing from
this:
configure: error: Pthreads are required to build libgomp
Looking at config.log, the error is actually:
configure:15118: /tmp
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
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #13 from coypu ---
I sent this to gcc-patches
for netbsd/eabi and stop picking arm6 -mcpu for oabi too:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01256.html
for all of arm to stop defaulting to non-existent -mcpu=arm6:
https
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #12 from coypu ---
to clarify, I still had trouble building oabi, but it fails elsewhere now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #11 from coypu ---
That cross builds with trunk.
For attempting to build oabi it wasn't enough to not specify
target_cpu_cname=arm6, because the default cpu is still arm6.
in gcc/config.gcc:3989 right now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #10 from coypu ---
Created attachment 44836
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44836=edit
netbsd eabi support
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
ping.
I can provide a less scary patch to correct the typo if people are
afraid of the cleanup changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221
--- Comment #3 from coypu ---
I think the change in bug 81523 to make -static imply no PIE might be wrong, as
static PIE is a thing.
It might be more right to limit that change only for configurations that don't
support static PIE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221
--- Comment #2 from coypu ---
(In reply to Andrew Pinski from comment #1)
> This is related to bug 81523. How did you configure GCC?
Configured with nothing related to default pie:
export ac_cv_func_freelocale=no
export ac_cv_func_newloc
: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
With any example code,
> /usr/local/bin/gcc -pie -fpie test2.c
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtbegin.o:
relocation R_X86_64_32 against hidden symbol `__TMC_END__'
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #5 from coypu
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
Ping.
Anything else to do for this?
Thanks.
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
> >>>
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #1 from coypu ---
Threw computing resources at the problem, so now I have an "offending" commit.
Before this commit, it doesn't segfault.
After, it does.
commit bbb9b536dd58015b5712a867954d34aae9d9dae5 (HEAD, refs/bisect/b
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 43929
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43929=edit
Reproduce test
build with the following flags fails:
-O2 -fno-pic -c ip_icmp.i
here is a backtr
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152
--- Comment #1 from coypu ---
*** Bug 85151 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 43808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43808=edit
Test case.
ICE with -O2, no ICE with -O0.
~/gcc/build/gcc$ PATH=.:$PATH ./xgcc -x c small.c -c -O2
during RTL p
: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 43807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43807=edit
Test case.
ICE with -O2, no ICE with -O0.
~/gcc/build/gcc$ PATH=.:$PATH ./xgcc -x c ~/small.c -c -O2
during RTL p
(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,
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
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
ping
they're good patches. ask questions. I have more.
ping, let me know if there is anything wrong with it.
1 - 100 of 142 matches
Mail list logo
