Package: gcc-4.4
Version: 4.4.4-2
- Forwarded message from Carlos O'Donell -
Date: Sat, 22 May 2010 22:58:18 -0400
From: Carlos O'Donell
To: John David Anglin ,
Debian HPPA Port List ,
libc-po...@sourceware.org
Subject: Test tstdiomisc fails when multiplication of NAN b
On Sat, Jun 13, 2009 at 08:15:36PM +0100, Mark Brown wrote:
> Might be worth putting a reference to the decision making process or
> something in these reports - this change doesn't appear to have been
> announced anywhere terribly widely and appears to be in very early
> stages so your report was
Package: lib32ffi5
Version: 3.0.7-1
On amd64, files in /emul/ia32-linux should be moved to /usr/lib32.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: lib32g2c0
Version: 1:3.4.6-9
On amd64, files in /emul/ia32-linux should be moved to /usr/lib32.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Thu, Nov 06, 2008 at 06:06:03AM +, Debian Bug Tracking System wrote:
> > reassign 499142 fakeroot
> Bug#499142: hangs while building eclipse
> Bug reassigned from package `gij-4.3' to `fakeroot'.
Are threads involved? Does fakeroot-tcp avoid the problem?
If neither, has the file being fsta
Package: java-gcj-compat-dev
Version: 1.0.76-5
/usr/lib/jvm/java-gcj/bin/java points to /usr/bin/ecj, which is not
provided by any of the dependencies.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Did you test it? I'm not convinced it can be easily backported without
> breaking anything. I'll ask the author.
No, I don't have access to any alpha machines.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
severity 370248 serious
tags 370248 + patch
quit
There is a patch listed at
http://gcc.gnu.org/PR27891
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> please recheck with gcc-4.1.
Looks to me like it builds.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> "-O2 -fwritable-strings" produces the same behavior as "-O2".
It's fine with -O0 and -O1. Should I be trying -fwritable-strings with
one of those?
> I missed the beginning of this thread. What gcc version? Do you have a
> small test program? How about "-O2 -fwritable-strings"?
ii gcc3.3.3-2The GNU C compiler
No.
"-O2 -fwritable-strings" produces the same behavior as "-O2".
> The string stored at ptr, after ptr is no longer equal to optr, changes
> from "" to "\020" when checkunary() is called. I'm going to try again
> with gcc -O0 to see if the same thing happens.
The test passes with no optimization; I guess this means it's a gcc bug
specific to mips.
> Actually, it works just like it is supposed to work. That may not be the
> same as in the past, but it's the way it should be. Granted the surprise
> is something the users will have to adjust to, but that doesn't mean
> things shouldn't work properly.
>
> On a 64-bit machine, one should expect
On Mon, Nov 17, 2003 at 08:56:05PM +0100, Matthias Klose wrote:
> why is it annoying? it just works.
It just works the opposite of the way I want it to work.
It also confuses the hell out of users who just want to compile
something.
> Yes, but sparc32-jailing builds is both non-obvious, tedious a
Package: gcc
Version: 4:3.3.1-2
File: /usr/bin/gcc
Please make the sparc gcc wrapper optional for those of us who would
prefer a symlink to gcc-3.3.
> In file included from /usr/lib/gcc-lib/sparc-linux/3.2.3/include/stdio.h:683,
> from ../faked.cc:80:
> /usr/include/bits/stdio.h: In function `int getchar()':
> /usr/include/bits/stdio.h:42: declaration of `int getchar()' throws different
>exceptions
> /usr/lib/gcc-lib/sparc-
http://buildd.debian.org/build.php?arch=&pkg=bogofilter
* 0.14.1.1-1 (arm) (latest build at Aug 1 21:45: maybe-failed)
* 0.14.1.1-1 (mipsel) (latest build at Aug 1 21:40: maybe-failed)
* 0.14.1.1-1 (mips) (latest build at Aug 1 21:58: maybe-failed)
* 0.14.1.1-1 (hppa) (latest buil
> > No, with -O2 it breaks on
> > gcc-3.23.2.3-6
> > gcc-3.33.3.1-0rc1
> > gcc-snapshot 20030722-1
>
> but it did work with gcc-2.95?
There is no 2.95 on hppa.
- Forwarded message from Clint Adams <[EMAIL PROTECTED]> -
Date: Wed, 23 Jul 2003 08:35:00 -0400
From: Clint Adams <[EMAIL PROTECTED]>
To: Matthias Andree <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: bogoutil segfaults
> Does SPARC support unaligned acc
> > - can you identify the file beeing miscompiled?
>
> No, I don't seem to be able to do that. If I compile with -O1, it
> works. If I compile with -O2, it segfaults. If I compile all objects
> -O2 except the ones that seem to be relevant in the backtrace, it still
> segfaults. (Also tried wi
[this message only refers to testing that was only done on hppa]
> - does it work with gcc-3.2?
> - does it work with gcc-snapshot?
No, with -O2 it breaks on
gcc-3.23.2.3-6
gcc-3.33.3.1-0rc1
gcc-snapshot 20030722-1
> - can you identify the file beeing miscompiled?
No, I don't
Package: gcc
Version: multiple
Severity: normal
The bogofilter test suite fails on m68k, hppa, mips, mipsel, and arm
due to a segfault in bogoutil.
On hppa, at least, compiling with -O0 or -O1 results in a working binary.
Therefore I assume an optimization bug. (This was tested with
gcc-3.3 3.3.
> issue. If gcc 3.3 will be back to -m64 aware, we re-enable these
> configurations. Do you know the status of gcc-3.3 which is ready for
> -m64?
gcc-3.3 3.3-0pre3, currently in sid, builds -m64 binaries that work.
> That's right. If new gcc package has ability to handle sparc64 -m64
> (currently both gcc-3.3 and gcc-snapshot have not come), it should be
> duploaded with appropriate changes for glibc source package.
glibc_2.3.2-1 builds libc6-sparc64 and libc6-dev-sparc64 just fine with
the following patch
> Any identifier without a definition is considered to be 0 in an #if.
> Macro substitution is performed on TEST_THREE, which converts it to the
> identifier TEST_THREE - still not #define'd. So it's 0.
So, to be clear, it's impossible to compare RLIMIT defines in the
preprocessor, then?
> The output of "cpp test.c" on the attached file:
And cpp -Wundef test.c:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
test.c:5:2: warning: #warning TEST_FIVE defined
test.c:8:2: warning: #warning TEST_NINE defined
# 15 "test.c"
test.c:24:6: warning: "TEST_FOUR" is not defined
test.c:24:19: warning:
The output of "cpp test.c" on the attached file:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
test.c:5:2: warning: #warning TEST_FIVE defined
test.c:8:2: warning: #warning TEST_NINE defined
# 15 "test.c"
test.c:25:2: warning: #warning 4 and 7 claim to be equal
enum __stuff { TEST_FOUR = 4, TEST_SEVEN =
> My concern is that locally compiled apps built against C++ libraries
> other than libstdc++ will silently stop working on upgrade. This is
> certainly not the most important issue facing us in the transition, but
> so far it seems to me that people are regarding it as so *un*important
> that it'
28 matches
Mail list logo
