https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #2 from Valeriy E. Ushakov ---
I don't have the latest gcc handy, but I see this bug already in an old netbsd
tree from about an year ago with gcc 8.4.0
As hgutch@n.o pointed out, this seems to be a problem with this peephole2:
;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #16 from Valeriy E. Ushakov ---
(In reply to Eric Gallager from comment #15)
> (In reply to Valeriy E. Ushakov from comment #11)
> > Created attachment 44668 [details]
> > Diff against gcc-6.4.0
> >
> > This is essentially the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #14 from Valeriy E. Ushakov ---
Sorry, I meant comment #6 in the above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #13 from Valeriy E. Ushakov ---
The above build was done on a linux/amd64 host.
The error happens when NetBSD build cross-compiles native NetBSD/sh3 gcc, i.e.
the compiler that will run natively on sh3 as part of the NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #12 from Valeriy E. Ushakov ---
I've attached updated patch against gcc 6.4.0. If I un-apply that patch to the
NetBSD tree with patch -R (i.e. revert the files to their original state as in
gcc 6.4.0) I get
$ nbmake-landisk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
Valeriy E. Ushakov changed:
What|Removed |Added
CC||uwe at netbsd dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #8 from Valeriy E. Ushakov ---
I don't understand. The title mentions sh3, which is not obsolete.
It's been 11 (eleven!) years. As far as I know this patch (adjusted to catch
up with the changes, but essentially the same) is still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #6 from Valeriy E. Ushakov ---
(In reply to Oleg Endo from comment #5)
> (In reply to Valeriy E. Ushakov from comment #4)
>
> > GEN_INT (-4294967296L;
>
> > GEN_INT (4294967295L)),
>
> I think those should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #4 from Valeriy E. Ushakov ---
Seems to fail more or less the same way without the patch. NetBSD current with
gcc 5.4.0. Building on linux/amd64. When native gcc is cross compiled
shle--netbsdelf-c++ ... -c insn-emit.c
fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #3 from Valeriy E. Ushakov ---
The patch above has been committed to the NetBSD imported version of gcc back
in April 2008 and has been merged in all the new imported versions ever since.
It's been quite a few years so I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039
--- Comment #6 from Valeriy E. Ushakov uwe at netbsd dot org ---
As far as I can tell the actual problem is in this code:
.loc 1 189 0
mov.l.L91,r0
; ...
addr12,r0
mov.l.L84,r1
jsr@r0; udivsi3 for 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
--- Comment #7 from Valeriy E. Ushakov uwe at netbsd dot org 2011-08-24
21:26:23 UTC ---
This fixes the problem. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
Bug #: 50068
Summary: Invalid memory access in incr_ticks_for_insn
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
--- Comment #1 from Valeriy E. Ushakov uwe at netbsd dot org 2011-08-13
01:18:00 UTC ---
Created attachment 24995
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24995
Preprocessed source that triggers the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
--- Comment #2 from Valeriy E. Ushakov uwe at netbsd dot org 2011-08-13
01:27:57 UTC ---
The command that fails:
.../libexec/gcc/shle--netbsdelf/4.5.3/cc1plus -fpreprocessed fstream-inst.i
-quiet -dumpbase fstream-inst.i -auxbase-strip fstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880
Summary: SuperH: ICE when -m4 is used with -mdiv=call-div1
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
resolution during template
instantiation
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe
--- Comment #1 from uwe at netbsd dot org 2010-02-22 02:51 ---
Created an attachment (id=19932)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19932action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
--- Comment #3 from uwe at netbsd dot org 2010-02-22 04:08 ---
(In reply to comment #2)
This is not a bug. Because the base class of Node::OpNode does not
depend on template arguments, the members of the base class are
visible in Node::OpNode::f(). On the other hand, since the base
--- Comment #5 from uwe at netbsd dot org 2010-02-22 04:45 ---
(In reply to comment #4)
What I meant to say is this: during parsing ...
So do I get this right (knowing nothing about g++ internals) that in the first
phase (during parsing) the call to test is resolved to sibling
--- Comment #6 from uwe at netbsd dot org 2010-02-22 04:47 ---
(In reply to comment #5)
What confuses me is that explictly qualifying the offending call as
Node::test(op.i)
makes it compile correctly.
I mean as far as I understand Node::test should resolve to the same sibling
--- Comment #1 from uwe at netbsd dot org 2008-04-17 20:14 ---
Created an attachment (id=15492)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15492action=view)
Suggested fix
Attached patch makes NetBSD/landisk (sh4) cross-build complete successfully on
NetBSD/amd64, where it used
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: x86_64--netbsd
GCC host triplet: shle
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: sh3--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
--- Comment #1 from uwe at netbsd dot org 2007-05-31 11:37 ---
Created an attachment (id=13638)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13638action=view)
Preprocessed source of the file that causes the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
--- Comment #2 from uwe at netbsd dot org 2007-05-31 11:44 ---
Before failing to compile pic version of asprintf.o as reportde above,
non-pic version is successfully compiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
--- Comment #2 from uwe at netbsd dot org 2007-02-26 16:35 ---
(In reply to comment #1)
On the second thought, I might be confused here. Please, leave UNCONFIRMED.
I'll do more testing and get back with an update later today. Sorry.
That was a pilot error. Please close. Sorry
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC
--- Comment #1 from uwe at netbsd dot org 2007-01-26 14:18 ---
On the second thought, I might be confused here. Please, leave UNCONFIRMED.
I'll do more testing and get back with an update later today. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
--- Comment #9 from uwe at netbsd dot org 2006-07-20 03:27 ---
(In reply to comment #8)
Author: sayle
Date: Wed Jul 19 05:13:56 2006
New Revision: 115578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115578
Log:
PR middle-end/28283
* expmed.c
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: shle--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
31 matches
Mail list logo
