These patches seem to fix this problem. I haven't tested the resulting
gij very extensively, but it can at least execute "hello world" type
stuff now.
p.
arm-gij.dpatch
Description: application/shellscript
arm-libffi.dpatch
Description: application/shellscript
On Mon, 2005-09-12 at 22:24 +0200, Matthias Klose wrote:
> > On arm only, gcc cannot handle C identifiers like:
> >
> > static void L1__GET_$ENVIRONMENT__defmacro()
>
> please could you (or somebody having access to an arm machine) check,
> if the problem exists in gcc-3.4 and/or gcc-snapshot as
On Tue, 2005-01-11 at 12:37 -0500, Branden Robinson wrote:
> Here are his remarks, recast a bit from IRC-speak into something more
> conventional.
>
> GCC on ARM is doing something different from every other C compiler I've
> seen. It may not deviate from what the C specification allows, but
merge 237126 233633
thanks
on Tue, Mar 09, 2004 at 10:18:48PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> (...)
> cc -g -Wall -O2 `sh ./cflags` -c monitor_dialog.c
> gcc -g -Wall -O2 `sh ./cflags`-c backend.c
> backend.c: In function `backend_empty':
> backend.c:566: error
on Fri, Mar 12, 2004 at 07:38:54AM +0100, Matthias Klose wrote:
> arm-10730.dpatch:
> 2003-05-15 Philip Blundell <[EMAIL PROTECTED]>
>
> PR target/10730
> * config/arm/arm.c (adjacent_mem_locations): Reject offsets
> involving invalid constants.
I guess this one should also be
on Fri, Mar 12, 2004 at 08:46:36AM -0800, Joe Buck wrote:
> Is the bug fixed in the gcc-3.3 CVS branch? This one was serious and
> visible enough that we should have a PR for it (so there's a referenceable
> bug description for the 3.3.4 release notes when they come out).
Not yet. I think Richar
reassign 188513 gforth
thanks
Upstream closed the forwarded report as RESOLVED INVALID; apparently the
problem is caused by a source file containing asm statements with
undefined effects. So I'm reassigning this bug back to gforth.
For details, see: http://gcc.gnu.org/PR11442
p.
on Thu, Feb 19, 2004 at 05:38:08PM +0100, Falk Hueffner wrote:
> Probably related to gcc PR 14166. There's a patch for that here:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14166
Thanks. That's kind of related, but actually a separate problem. 14166
is a Thumb-specific case, which Debian d
reassign 133022 freefem
retitle 133022 freefem: g++-3.0 needed for arm build
severity 133022 serious
# justification: build failure on a released architecture
thanks
This crash doesn't occur when building with g++-3.0. The 2.95 branch is
no longer being maintained upstream so the best thing would
On Wed, 2002-02-27 at 23:04, Matthias Klose wrote:
> No problem. I'll update the CVS this weekend. Please wait with the
> upload until the current version did move to testing (should be in
> three days).
Which current version are we talking about? According to
update-excuses:
* gcc-defaults (0.1
On Wed, 2002-02-27 at 13:03, Dirk Eddelbuettel wrote:
> On Wed, Feb 27, 2002 at 12:29:15PM +0000, Phil Blundell wrote:
> > On Wed, 2002-02-27 at 02:40, Dirk Eddelbuettel wrote:
> > > gcc -I/usr/lib/R/include -fPIC -g -O2 -c coxfit2.c -o coxfit2.o
> > > coxf
On Wed, 2002-02-27 at 02:40, Dirk Eddelbuettel wrote:
> gcc -I/usr/lib/R/include -fPIC -g -O2 -c coxfit2.c -o coxfit2.o
> coxfit2.c: In function `coxfit2':
> coxfit2.c:352: Internal compiler error:
> coxfit2.c:352: internal error--unrecognizable insn:
> (insn 2883 243 245 (set (reg:DF 16 %fp0)
On Mon, 2002-02-18 at 05:25, Chris Cheney wrote:
> I wanted to let you know about a bug I have against one of my packages.
> It appears a fix wrt libtool/gcc (ppc) is not currently in Debian?
File a bug against gcc-2.95 and/or gcc-3.0, whichever is appropriate.
p.
reassign 130394 gcc-2.95
severity 130394 important
forwarded 130394 [EMAIL PROTECTED]
tags 130394 + patch
tags 130394 + upstream
tags 130394 + fixed
retitle 130394 [PR 5700] [ARM; fixed in 3.0] bug in __umodsi3
thanks
The reason this one didn't show up with a cross-compiler is that the bug
is in t
tags 129573 patch
thanks
Well, I think this patch will fix the immediate problem at hand. I've
no idea why CONST_DOUBLEs were being rejected previously, so it's
possible that this isn't a safe thing to do. I guess someone needs to
take it up with the upstream gcc folk.
p.
Index: linux.h
==
On Fri, 2002-02-15 at 11:41, Othmar Pasteka wrote:
> On Fri, Feb 15, 2002 at 11:23:00AM +0000, Phil Blundell wrote:
> > > should be more like
> > > arm-gnu-source because the patch is named arm-gnu-source.dpatch.
> >
> > Can you make a binary-only upload with
On Fri, 2002-02-15 at 08:42, Othmar Pasteka wrote:
> you have a small typo in the arm specific section of rules.patch.
>
> you wrote
>
> ifeq ($(DEB_HOST_ARCH),arm)
> debian_patches += arm-const-double arm-tune arm-gnus-source
> endif
>
> should be more like
>
> arm-gnu-source because the pat
On Mon, 2002-02-04 at 15:27, Santiago Vila wrote:
> > > For example, would "Build-Depends: gcj" be acceptable?
> >
> > gcj only works on i386, powerpc, m68k, sparc, s390, alpha and ia64.
>
> Hmm, do you mean it does not work on arm, hppa, mips and mipsel?
> Is this considered a release-critical bu
On Fri, 2002-01-18 at 02:18, Adam C Powell IV wrote:
> So that would seem to make for two RC bugs: one against gcc-2.95 for
> these LC* mystery symbols in fortran libs, and the other against
> gcc-3.0_3.0.3-1 for not building, right?
I think I looked at fixing this in 2.95 a long time ago and di
> I have attached the file in question, but I don't know if that will be
>enough information. Since I don't have an arm system, as I said above,
>finding a workaround will be difficult unless upstream knows one.
You need to supply a self-contained testcase, not just the particular header
file i
>/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/gc.c:37: gc.h:
> No such file or directory
>/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/gc.c:55: gc_ty
>ped.h: No such file or directory
You need libgc5-dev.
p.
21 matches
Mail list logo
