Bug#221565: g++-3.3: bad code generation (fwd)
(damn, this mailer sucks, sorry for any mangling) Bryce Wilcox-O'Hearn <[EMAIL PROTECTED]>: > I use Crypto++ v5.0 [1], and I've noticed that the "generate a random > RSA key pair" function either seg faults or goes into an infinite > loop. I've learned that turning optimization off with -O0 or else > downgrading to g++ 3.2.3 solves this problem. > > I'd be happy to provide a test case if you want. Please do, preferably a stand-alone test case that doesn't need the library installed (I do realize this could be quite some work, though). Falk
Bug#221621: gcc-3.3: fails to compile the linux kernel
Package: gcc-3.3 Version: 1:3.3.2-4 Severity: normal While compiling the kernel on a sparc system I get the following errors in kernel-source-2.4.22/arch/sparc/kernel/check_asm.c: gcc -o check_asm check_asm.c check_asm.c:309: error: field name not in record or union initializer check_asm.c:309: error: (near initialization for `check_asm_data') check_asm.c:311: warning: initialization makes integer from pointer without a cast and while compiling a 64-bit kernel I get gcc -o check_asm check_asm.c check_asm.c:312: error: field name not in record or union initializer check_asm.c:312: error: (near initialization for `check_asm_data') check_asm.c:313: warning: initialization makes integer from pointer without a cast check_asm.c:313: error: initializer element is not computable at load time check_asm.c:313: error: (near initialization for `check_asm_data[307]') The offending line is .section".note.GNU-stack" at the end of the initialization of unsigned int check_asm_data[]. The previous version of gcc-3.3 (3.3.2-1) was working fine. I've verified this on both kernel-source-2.4.22-3 and kernel-source-2.4.22-4 -- System Information: Debian Release: testing/unstable Architecture: sparc Kernel: Linux argonath-linux 2.4.22-anbe3-sparc64-smp #1 SMP Sun Sep 28 23:33:06 CEST 2003 sparc64 Locale: LANG=C, LC_CTYPE=C Versions of packages gcc-3.3 depends on: ii binutils 2.14.90.0.6-5 The GNU assembler, linker and bina ii cpp-3.31:3.3.2-4 The GNU C preprocessor ii gcc-3.3-base 1:3.3.2-4 The GNU Compiler Collection (base ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii libgcc11:3.3.2-4 GCC support library -- no debconf information
Bug#221621: gcc-3.3: fails to compile the linux kernel
On Wed, 19 Nov 2003, Andreas Beckmann wrote: > The offending line is > .section".note.GNU-stack" > at the end of the initialization of unsigned int check_asm_data[]. This is not valid sytax. It ought to be .section = ".note.GNU-stack" Please reassign to the source package. Falk
Bug#221282: /usr/bin/gcc: sparc wrapper is annoying
> 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 to get 64-bit binaries by > default. Users have always complained about that. Now that sparc64 is > moving into a working state, that reality will happen and become the > norm. Ignoring the fact that gcc gives me 32-bit binaries by default on every bi-arch system I've ever seen, you're not wrapping binutils, so, poor naive programs expecting consistency between gcc and ld are SOL. I'm not saying this isn't your intention. I'm saying I want a convenient way to permanently disable this on every sparc64 system I have. I imagine that I will also want to disable this on x86-64 and s390x if this wrapper migrates there. Should I ITP a diversion package?
Bug#221282: /usr/bin/gcc: sparc wrapper is annoying
On Wed, Nov 19, 2003 at 10:04:52AM -0500, Clint Adams wrote: > > 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 to get 64-bit binaries by > > default. Users have always complained about that. Now that sparc64 is > > moving into a working state, that reality will happen and become the > > norm. > > Ignoring the fact that gcc gives me 32-bit binaries by default on every > bi-arch system I've ever seen, you're not wrapping binutils, so, poor > naive programs expecting consistency between gcc and ld are SOL. > I'm not saying this isn't your intention. I'm saying I want a > convenient way to permanently disable this on every sparc64 system I > have. Programs that call ld directly need to take special care. Even the kernel has to worry about this. Programs having to do it are no different. Using ld directly requires special care, even outside of this issue. > I imagine that I will also want to disable this on x86-64 and s390x if > this wrapper migrates there. I've given you that ability. Just touch the magic file and you are all set. > Should I ITP a diversion package? That would just cause more confusion. You are making this more difficult than it really is. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
[Bug c++/13070] [3.3/3.4 regression] -Wformat option ignored in g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2003-11-19 16:12 --- *** Bug 13123 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jthorn at aei dot mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13070 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Bug#221738: gcj-3.3: ICE during babel build
Package: gcj-3.3
Version: 3.3.2-4
Severity: normal
Greetings,
gcj-3.3 ICEs during at attempted build of babel 0.8.8. The compile
command is quite ugly:
javac -g -d . -classpath
../lib/java-getopt-1.0.7.jar:../lib/xerces-2.4.0.jar:../lib/jcert-1.0.1.jar:../lib/jnet-1.0.1.jar:../lib/external/jsse-1.0.1.jar:../lib/xml-apis.jar
./gov/llnl/babel/backend/c/ArrayMethods.java (and 161 other .java files)
It is followed by a boatload of warnings, and then:
./gov/llnl/babel/backend/fortran/AbbrevHeader.java: In class
`gov.llnl.babel.backend.fortran.AbbrevHeader':
./gov/llnl/babel/backend/fortran/AbbrevHeader.java: In method
`gov.llnl.babel.backend.fortran.AbbrevHeader.generateExtendable(gov.llnl.babel.symbols.Extendable,gov.llnl.babel.backend.mangler.NameMangler,gov.llnl.babel.backend.mangler.NameMangler)':
./gov/llnl/babel/backend/fortran/AbbrevHeader.java:239: internal
compiler error: in emit_store, at java/jcf-write.c:1048
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Is there an equivalent to "gcc -E" for Java, to preprocess the source?
If not, you can get the (unbuildable) Debian package source at:
http://lyre.mit.edu/~powell/babel/babel_0.8.8.orig.tar.gz
http://lyre.mit.edu/~powell/babel/babel_0.8.8-1.diff.gz
http://lyre.mit.edu/~powell/babel/babel_0.8.8-1.dsc
then just dpkg-buildpackage -r fakeroot, and you'll see the ICE. Or
give me instructions for making "preprocessed source" and I'll do so.
Interestingly, babel 0.8.6-3 compiles just fine. (Kaffe fails to run
it; if compiled with gcj-0.3.2, then kaffe is perfectly happy with it.
But that's bug 197090 against kaffe.) The difference between the
AbbrevHeader.java files in those two versions is:
--- babel-0.8.6/compiler/gov/llnl/babel/backend/fortran/AbbrevHeader.java
2003-07-23 12:30:08.0 -0400
+++ babel-0.8.8/compiler/gov/llnl/babel/backend/fortran/AbbrevHeader.java
2003-10-28 18:25:43.0 -0500
@@ -2,9 +2,9 @@
// File:AbbrevHeader.java
// Package: gov.llnl.babel.backend.fortran
// Copyright: (c) 2002 The Regents of the University of California
-// Release: $Name: release-0-8-6 $
-// Revision:@(#) $Revision: 1.12 $
-// Date:$Date: 2003/04/02 22:11:25 $
+// Release: $Name: release-0-8-8 $
+// Revision:@(#) $Revision: 1.13 $
+// Date:$Date: 2003/09/03 15:08:42 $
// Description: Write #include file to mangle names when necessary
//
//
@@ -78,6 +78,9 @@
"get2",
"get3",
"get4",
+"get5",
+"get6",
+"get7",
"isColumnOrder",
"isRowOrder",
"lower",
@@ -86,6 +89,9 @@
"set2",
"set3",
"set4",
+"set5",
+"set6",
+"set7",
"slice",
"smartCopy",
"stride",
@@ -230,13 +236,16 @@
}
if ("f90".equals(BabelConfiguration.getInstance().getTargetLanguage())) {
+ final int maxArray = BabelConfiguration.getInstance().getMaximumArray();
if (!ext.isInterface()) {
generateType(symName, non, fort, "_impl");
generateType(symName, non, fort, "_private");
generateType(symName, non, fort, "_wrap");
}
generateType(symName, non, fort, "");
- generateType(symName, non, fort, "_a");
+ for(int d = 1; d <= maxArray ; ++d) {
+generateType(symName, non, fort, "_" + Integer.toString(d) + "d");
+ }
generateType(symName, non, fort, "_array");
generateType(symName, non, fort, "_t");
generateType(symName, non, fort, "_type");
Of course the version difference is irrelevant; the next two hunks add
to an array of strings. But the last hunk is in the generateExtendable
method, with its first change on line 239 (mentioned in the ICE).
Perhaps that change could provide a clue as to why the old version
compiles and the new one causes an ICE...
Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Bug#221738: gcj-3.3: ICE during babel build
Adam C Powell IV <[EMAIL PROTECTED]> writes: > gcj-3.3 ICEs during at attempted build of babel 0.8.8. The compile > command is quite ugly: > > javac -g -d . -classpath > ../lib/java-getopt-1.0.7.jar:../lib/xerces-2.4.0.jar:../lib/jcert-1.0.1.jar:../lib/jnet-1.0.1.jar:../lib/external/jsse-1.0.1.jar:../lib/xml-apis.jar > ./gov/llnl/babel/backend/c/ArrayMethods.java (and 161 other .java files) > > It is followed by a boatload of warnings, and then: > > ./gov/llnl/babel/backend/fortran/AbbrevHeader.java: In class > `gov.llnl.babel.backend.fortran.AbbrevHeader': > ./gov/llnl/babel/backend/fortran/AbbrevHeader.java: In method > `gov.llnl.babel.backend.fortran.AbbrevHeader.generateExtendable(gov.llnl.babel.symbols.Extendable,gov.llnl.babel.backend.mangler.NameMangler,gov.llnl.babel.backend.mangler.NameMangler)': > ./gov/llnl/babel/backend/fortran/AbbrevHeader.java:239: internal > compiler error: in emit_store, at java/jcf-write.c:1048 Does it ICE if you just call gcj -c AbbrevHeader.java? -- Falk
Bug#221738: gcj-3.3: ICE during babel build
On Wed, 2003-11-19 at 16:13, Falk Hueffner wrote:
> Adam C Powell IV <[EMAIL PROTECTED]> writes:
>
> > gcj-3.3 ICEs during at attempted build of babel 0.8.8. The compile
> > command is quite ugly:
> >
> > javac -g -d . -classpath
> > ../lib/java-getopt-1.0.7.jar:../lib/xerces-2.4.0.jar:../lib/jcert-1.0.1.jar:../lib/jnet-1.0.1.jar:../lib/external/jsse-1.0.1.jar:../lib/xml-apis.jar
> > ./gov/llnl/babel/backend/c/ArrayMethods.java (and 161 other .java files)
> >
> > It is followed by a boatload of warnings, and then:
> >
> > ./gov/llnl/babel/backend/fortran/AbbrevHeader.java: In class
> > `gov.llnl.babel.backend.fortran.AbbrevHeader':
> > ./gov/llnl/babel/backend/fortran/AbbrevHeader.java: In method
> > `gov.llnl.babel.backend.fortran.AbbrevHeader.generateExtendable(gov.llnl.babel.symbols.Extendable,gov.llnl.babel.backend.mangler.NameMangler,gov.llnl.babel.backend.mangler.NameMangler)':
> > ./gov/llnl/babel/backend/fortran/AbbrevHeader.java:239: internal
> > compiler error: in emit_store, at java/jcf-write.c:1048
>
> Does it ICE if you just call gcj -c AbbrevHeader.java?
Ah, yes it does! As it's just 9K, I've attached the file.
Thanks for the rapid reply!
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
//
// File:AbbrevHeader.java
// Package: gov.llnl.babel.backend.fortran
// Copyright: (c) 2002 The Regents of the University of California
// Release: $Name: release-0-8-8 $
// Revision:@(#) $Revision: 1.13 $
// Date:$Date: 2003/09/03 15:08:42 $
// Description: Write #include file to mangle names when necessary
//
//
// Copyright (c) 2002, The Regents of the University of Calfornia.
// Produced at the Lawrence Livermore National Laboratory.
// Written by the Components Team <[EMAIL PROTECTED]>
// UCRL-CODE-2002-054
// All rights reserved.
//
// This file is part of Babel. For more information, see
// http://www.llnl.gov/CASC/components/. Please read the COPYRIGHT file
// for Our Notice and the LICENSE file for the GNU Lesser General Public
// License.
//
// This program is free software; you can redistribute it and/or modify it
// under the terms of the GNU Lesser General Public License (as published by
// the Free Software Foundation) version 2.1 dated February 1999.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY OF
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the terms and
// conditions of the GNU Lesser General Public License for more details.
//
// You should have recieved a copy of the GNU Lesser General Public License
// along with this program; if not, write to the Free Software Foundation,
// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
package gov.llnl.babel.backend.fortran;
import gov.llnl.babel.BabelConfiguration;
import gov.llnl.babel.backend.fortran.Fortran;
import gov.llnl.babel.backend.IOR;
import gov.llnl.babel.backend.mangler.FortranMangler;
import gov.llnl.babel.backend.mangler.NameMangler;
import gov.llnl.babel.backend.mangler.NonMangler;
import gov.llnl.babel.backend.writers.LanguageWriter;
import gov.llnl.babel.symbols.Extendable;
import gov.llnl.babel.symbols.Method;
import gov.llnl.babel.backend.CodeGenerationException;
import gov.llnl.babel.symbols.Symbol;
import gov.llnl.babel.symbols.SymbolID;
import java.io.UnsupportedEncodingException;
import java.security.NoSuchAlgorithmException;
import java.util.Collection;
import java.util.Iterator;
public class AbbrevHeader {
/**
* The maximum number of characters allowed in a name.
*/
static final public int MAXNAME = 31;
static final public int MAXUNMANGLED = 21;
static private final String s_arrayMethods[] = {
"access",
"addRef",
"borrow",
"copy",
"create1d",
"create2dCol",
"create2dRow",
"createCol",
"createRow",
"deleteRef",
"dimen",
"ensure",
"get",
"get1",
"get2",
"get3",
"get4",
"get5",
"get6",
"get7",
"isColumnOrder",
"isRowOrder",
"lower",
"set",
"set1",
"set2",
"set3",
"set4",
"set5",
"set6",
"set7",
"slice",
"smartCopy",
"stride",
"upper"
};
static private final String s_skelMethods[] = {
"_get_data",
"_set_data"
};
private LanguageWriter d_lw;
public AbbrevHeader(LanguageWriter writer)
{
d_lw = writer;
}
private void writeLine(String longName,
String shortName)
{
d_lw.disableLineBreak();
d_lw.print("#define ");
d_lw.print(longName);
d_lw.print(" ");
d_lw.println(shortName);
d_lw.enableLineBreak();
}
private void writeEntry(String longName,
String shortName)
{
String monocase = longName.toLowerCase();
writeLine(longName, shortName);
if (!
Processed: your mail
Processing commands for [EMAIL PROTECTED]: > reassign 221621 kernel-source-2.4.22 Bug#221621: gcc-3.3: fails to compile the linux kernel Bug reassigned from package `gcc-3.3' to `kernel-source-2.4.22'. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
[no subject]
I am interested in excelsior living room tables, sofa tables, etc, and bedroon furniture. Is there a cheaper way to buy these products other than in a retail store? Sincerely Debra Noel [EMAIL PROTECTED]
Re: Processed: your mail
reassign 221621 kernel-image-sparc-2.4
quit
On Wed, Nov 19, 2003 at 03:48:12PM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 221621 kernel-source-2.4.22
> Bug#221621: gcc-3.3: fails to compile the linux kernel
> Bug reassigned from package `gcc-3.3' to `kernel-source-2.4.22'.
Please reassign kernel bugs to the correct architecture.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: your mail
On Thu, Nov 20, 2003 at 09:13:33AM +1100, Herbert Xu wrote: > reassign 221621 kernel-image-sparc-2.4 > quit > > On Wed, Nov 19, 2003 at 03:48:12PM -0600, Debian Bug Tracking System wrote: > > Processing commands for [EMAIL PROTECTED]: > > > > > reassign 221621 kernel-source-2.4.22 > > Bug#221621: gcc-3.3: fails to compile the linux kernel > > Bug reassigned from package `gcc-3.3' to `kernel-source-2.4.22'. > > Please reassign kernel bugs to the correct architecture. But this is a bug in the kernel source, not in the sparc kernel package. Why should it be assigned to the kernel-image-sparc package when it has to be fixed in the kernel-source package? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Re: Processed: your mail
On Wed, Nov 19, 2003 at 05:17:16PM -0500, Ben Collins wrote:
>
> But this is a bug in the kernel source, not in the sparc kernel package.
> Why should it be assigned to the kernel-image-sparc package when it has
> to be fixed in the kernel-source package?
The kernel-source package does not support any architectures apart
from alpha/i386. That's why we have architecture-specific patch packages
and maintainers.
The problem cited in this report is sparc-specific and does not affect
other architectures.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: your mail
On Thu, Nov 20, 2003 at 09:30:11AM +1100, Herbert Xu wrote: > On Wed, Nov 19, 2003 at 05:17:16PM -0500, Ben Collins wrote: > > > > But this is a bug in the kernel source, not in the sparc kernel package. > > Why should it be assigned to the kernel-image-sparc package when it has > > to be fixed in the kernel-source package? > > The kernel-source package does not support any architectures apart > from alpha/i386. That's why we have architecture-specific patch packages > and maintainers. > > The problem cited in this report is sparc-specific and does not affect > other architectures. Just because the binaries are built somewhere else does not defer the fact that the bug is in the source. He's having a problem building the kernel-source package, and that has to be fixed there, not in kernel-image-sparc. Even if I put a patch in kernel-image-sparc, it doesn't fix his problem. Fact, kernel-image-sparc builds from kernel-source _without_ patches. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Re: Processed: your mail
On Wed, Nov 19, 2003 at 06:14:30PM -0500, Ben Collins wrote:
>
> Just because the binaries are built somewhere else does not defer the
> fact that the bug is in the source. He's having a problem building the
> kernel-source package, and that has to be fixed there, not in
> kernel-image-sparc. Even if I put a patch in kernel-image-sparc, it
> doesn't fix his problem.
>
> Fact, kernel-image-sparc builds from kernel-source _without_ patches.
OK. I'm happy to do this as long as you don't mind any patch
conflicts as a result this should your architecture require
patches later on.
If you agree with that, please reassign the bug back to the 'kernel'
package.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[Bug java/10304] ICE when compiling OpenNMS (jcf-write.c:1041)
--- Additional Comments From falk at debian dot org 2003-11-19 23:28 --- The same ICE has also been reported for another program in the Debian bug tracking system. See http://bugs.debian.org/221738 -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10304 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: Processed: your mail
On Thu, Nov 20, 2003 at 10:25:21AM +1100, Herbert Xu wrote: > On Wed, Nov 19, 2003 at 06:14:30PM -0500, Ben Collins wrote: > > > > Just because the binaries are built somewhere else does not defer the > > fact that the bug is in the source. He's having a problem building the > > kernel-source package, and that has to be fixed there, not in > > kernel-image-sparc. Even if I put a patch in kernel-image-sparc, it > > doesn't fix his problem. > > > > Fact, kernel-image-sparc builds from kernel-source _without_ patches. > > OK. I'm happy to do this as long as you don't mind any patch > conflicts as a result this should your architecture require > patches later on. > > If you agree with that, please reassign the bug back to the 'kernel' > package. I have no problem with that. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Re: Processed: your mail
reassign 221621 kernel
quit
On Wed, Nov 19, 2003 at 07:23:04PM -0500, Ben Collins wrote:
>
> > OK. I'm happy to do this as long as you don't mind any patch
> > conflicts as a result this should your architecture require
> > patches later on.
> >
> > If you agree with that, please reassign the bug back to the 'kernel'
> > package.
>
> I have no problem with that.
OK.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
