Re: gcc-3.? compiler for hppa (3.1, 3.1+dwarf2, 3.2cvs20020429?)
On Sun, May 05, 2002 at 08:54:06AM +0200, Martin v. Loewis wrote: > Matthias Klose <[EMAIL PROTECTED]> writes: > > > I would like to get feedback, on which alternative to base the gcc-3.1 > > packages: > > > > a) 3.1 as to be released (without dwarf2 support) > > As Redhat has demonstrated in the past, it is highly desirable that > the distributed gcc is based on a released gcc as close as possible. > If there are serious problems in gcc 3.1-as-released, work with gcc > maintainers to fix them in 3.1.1. Completely seconded. I want the collection of patches that distributors ship with GCC to shrink over time, not grow... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ppc 3.1 didn't build
It was pretty easy to fix, though. In libstdc++/Makefile.in, after the long assignment to AM_MAKEFLAGS, add: FLAGS_TO_PASS = $(AM_MAKEFLAGS) I'm not 100% sure that's correct; I'll check on the GCC lists. Meanwhile, what should I do with this build? Wait for a new one? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc3.1 needs tighter (build-|)depends on binutils
GCC 3.1 should require the newly uploaded binutils. With the old set as a build dependency, .hidden support will be disabled. That's a pointless compatibility problem; we should get it right the first time. I'd like to see a -2 with the new binutils and the PPC patch I posted earlier before it goes into the archive. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building gcc-3.1-3.1ds2 on powerpc
On Tue, May 21, 2002 at 08:46:12AM -0500, Rob Latham wrote: > Hi > > i wanted to play with gcc-3.1, so i added > deb-src http://ftp-master.debian.org/~doko/gcc/ ./ > to apt.sources and tried to build from source. > > It looks like the build got pretty far, but failed towards the end > because it tried to install stuff into /usr/local > > After 'apt-get source gcc-3.1' i ran 'dpkg-buildpackage -rfakeroot' > Here's the error i get: Add: FLAGS_TO_PASS = $(AM_MAKEFLAGS) to libstdc++/Makefile.am. I posted about this last week, but Matthias has been busy, I think. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148181: gcc-3.1: missing xmmintrin.h
On Sun, May 26, 2002 at 10:03:10AM +0200, Matthias Klose wrote: > Jesse Hall writes: > > Package: gcc-3.1 > > Version: 1:3.1-2 > > Severity: normal > > > > The header file "xmmintrin.h" seems to be missing from the package. It > > was introduced in gcc-3.1, and is needed to use the SSE intrinsic > > functions. I believe it should be in > > /usr/lib/gcc-lib/i386-linux/3.1/include. > > > > I don't know if this is relevant, but the file is included in the > > gcc-snapshot package. > > corrected for the next upload. Same for altivec.h on powerpc, if you didn't get that at the same time. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148686: gcj-3.1 should provide /etc/alternatives/javac
On Sat, Jun 01, 2002 at 12:02:18AM +0200, Matthias Klose wrote: > Michael Koch writes: > > Package: gcj-3.1 > > Version: 1:3.1-2 > > Severity: normal > > > > > > gcj-3.1 should provide /etc/alternatives/javac > > yes, but only if gcj supports most of javac's options. Please feel > free to submit a gcj-wrapper, which can be used as an javac > alternative. Should it really provide javac? Javac is expected to compile to bytecode, and gcj doesn't do that. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149463: There should be a gcc version with stack protection patch
On Sun, Jun 09, 2002 at 10:40:11PM +0200, Martin v. Loewis wrote: > Torsten Knodt <[EMAIL PROTECTED]> writes: > > > thats not what I wanted to do. I think IBM and the other big users > > of this patch, will do this themselves. But I think in the meantime > > it would be a win to debian. Yes, it's mostly not a good idea to > > have features patches in the debian diff, but this would give > > security and, when I'm not wrong, wouldn't not make the compiled > > programs incompatible to normal programs. > > It probably would, because of the access to /dev/urandom. I haven't > tried, but I'm sure I could construct an application that would break > if that feature is enabled. Easily. It will wastefully drain the entropy pool of the system, with potentially severe impact on any crypto with a legitimate need for entropy. > > That's why I suggested a separate version of gcc as an option. Like > > there are versions with and without ssl for many packages, there > > could be a gcc version with and without stack protection. If you > > think this not a good idea, I would agree to close the report. > > Anybody that wants to use this patch on a regular basis can already do > so. Anybody who wants this package only rarely won't be helped much by > a separate package, IMO. In a separate package, it would IMO increase > the maintainance overhead, and prevent that remaining problems are > found. > > I think the best use of this patch would be if someone would try to > create a complete Debian distribution with the compiler, and run the > it with to find problems in the existing packages. The set of problems > found will also help in evaluating the patch. All you need is a lot of > disk space and spare cycles. I agree. There's very little point in adding this patch, especially to a version of GCC we're trying to obsolete soon. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149555: no documentation on how to use the lib for debugging
On Mon, Jun 10, 2002 at 01:53:45PM +0200, Ulrich Eckhardt wrote: > Package: libstdc++3-dbg > Version: 3.0.4-7 > > There is not a single note on how to use the lib for debugging, eg > setting: > LD_PRELOAD=/usr/lib/libstdc++_debug/libstdc++.so.3 > before starting the program to be debugged or explicitly linking > with that lib (untested): > $(CXX) ... -l/usr/lib/libstdc++_debug/libstdc++.so.3 > > Also the documentation /usr/share/doc/gcc-3.0-base/* doesn't mention anything > in that direction. Speaking of which, shouldn't we use /usr/lib/debug instead? Ncurses and libc already both use this convention. Uli, try LD_LIBRARY_PATH=/usr/lib/libstdc++_debug for now, by the way. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149561: bad pathnames coded into the libs
On Mon, Jun 10, 2002 at 09:03:14AM -0400, Phil Edwards wrote: > On Mon, Jun 10, 2002 at 02:15:35PM +0200, Ulrich Eckhardt wrote: > > While trying to debug a program, I encountered some weird paths that > > prevented me from taking advance of the debug-lib: > > > > LD_PRELOAD=/usr/lib/libstdc++_debug/libstdc++3.so.3 gdb ./test > > ... > > (gdb) step > > 178 in > > /home/doko/packages/gcc/3.0/gcc-3.0-3.0.4ds3/build/i386-linux/libstdc++-v3/include/bits/char_traits.h > > (gdb) > > > > This dir doesn't exist on my machine, and of course I can't step through > > the > > source then. > > > > I must admit that I don't know exactly where the path comes from. I did > > cd /usr/lib > > grep -r -i home *|grep doko > > to find out where the path was hardcoded but to no avail. > > I would imagine it's in /usr/lib/libstdc++_debug/libstdc++3.so.3. > That's what "debug information" consists of, after all: paths to the > source directories, file names, and line numbers. > > Stepping through is possible, but to actually see the source, you must have > the source avilable, and gdb needs to know where it is. If it's not in > "/home/doko/packages/..." then you can set a variable inside gdb to tell > it where to look. The command is 'dir', for reference. Follow it by the appropriate subdirectory of the source tree on your machine. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.1.1 to 3.2 transition
On Mon, Jul 29, 2002 at 08:29:25PM -0400, Jack Howarth wrote: > I noticed that the new gcc-3.1_3.1.1ds3-1 changelog notes that > gcc 3.1.1 will go away when 3.2 arrives. Do we plan on having a period > of time (say a month) where both 3.1.1 and 3.2 will co-exist in the > sid pool? That might be a good idea to allow folks to recompile any > packages that they might have built under gcc 3.1.1 with 3.2 instead. > I mention this because on ppc we have our openoffice.org package > currently built under gcc 3.1.1 and it would be a cleaner transition > if gcc 3.1.1 didn't instantly disappear when gcc 3.2 arrived in the > pool. Why would it be any cleaner? Everything should be rebuilt with gcc 3.2 as soon as possible, and there is no point in allowing packages to continue to be built with 3.1.1. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#154767: cpp-2.95: cpp fails to parse macros with varargs correctly
On Tue, Jul 30, 2002 at 01:33:34AM +0200, Marek Habersack wrote: > On Tue, Jul 30, 2002 at 01:21:48AM +0200, Martin v. Loewis scribbled: > > Marek Habersack <[EMAIL PROTECTED]> writes: > > > > > OK, I found the statement about the preceeding non-witespace tokens but, > > > still, I would think that something that breaks the kernel compile should > > > be > > > important no matter how trivial to work-around it is... > > > > The question is whether it should be fixed in the compiler, or in the > > kernel. > Since the 3.x+ preprocessors don't exhibit this bug, I would rather say that > in the compiler. Also, the requirement of putting the spaces around the > comma is somewhat troublesome, counter-intuitive and not really justified by > anything, IMHO... Adding (or not) spaces should be a matter of style and not > syntax - since the C syntax doesn't require the spaces, the preprocessor > requirement is the more unexpected by a C/C++ programmer. Since the 3.x preprocessors don't exhibit the bug, GCC doesn't need to be fixed; if the kernel wants to maintain compatibility with 2.95, then it should add the necessary space itself. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.1.1 to 3.2 transition
On Mon, Jul 29, 2002 at 08:45:30PM -0400, Jack Howarth wrote: > Daniel, >Well if gcc 3.1.1 instantly disappears the moment gcc 3.2 hits the pool, > won't that force openoffice/stl to deinstall on a dist-upgrade? It would > nicer if we allows folks a grace period for their apps to get rebuilt > before yanking the supporting libs they need. > Jack > ps The grace period could be shorter, perhaps a week or even a few days, > but I don't know if it is good to pull gcc 3.1.1 the moment 3.2 hits. The libstdc++ doesn't need to be yanked, but the compiler certainly does. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.1.1 to 3.2 transition
On Mon, Jul 29, 2002 at 10:32:03PM -0400, Jack Howarth wrote: > Daniel, >What about the libgcc_s.so.1? I assume we are assured of compatibility > in using a libgcc_s.so.1 from gcc 3.2 with binaries built with gcc 3.1.1 > then? Yes. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#156792: gcj-3.0: alternatives handling leaves broken symlink
Package: gcj-3.0 Version: 1:3.0.4-12 Severity: minor [EMAIL PROTECTED]:~% ls -l /usr/share/man/man1/gcj-3.0.1.gz -rw-r--r--1 root root 6230 Jul 20 22:05 /usr/share/man/man1/gcj-3.0.1.gz [EMAIL PROTECTED]:~% dlocate /usr/share/man/man1/gcj-3.0.1.gz gcj-3.0: /usr/share/man/man1/gcj-3.0.1.gz [EMAIL PROTECTED]:~% ls -l /etc/alternatives/javac.1.gz lrwxrwxrwx1 root root 40 Aug 13 22:37 /etc/alternatives/javac.1.gz -> /usr/share/man/man1/gcj-wrapper-3.0.1.gz There's no gcj-wrapper man page, just gcj. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux nevyn 2.4.19-pre10-ac2-drow #4 SMP Sun Jun 16 12:01:20 EDT 2002 i686 Locale: LANG=en_US, LC_CTYPE= Versions of packages gcj-3.0 depends on: ii gcc-3.0 1:3.0.4-12 The GNU C compiler. ii gcc-3.0-base 1:3.0.4-12 The GNU Compiler Collection (base ii java-common 0.14 Base of all Java packages ii libc6 2.2.5-13 GNU C Library: Shared libraries an ii libgcj2 1:3.0.4-12 Java runtime library for use with ii libgcj2-dev 1:3.0.4-12 Java development headers and stati ii zlib1g1:1.1.4-3 compression library - runtime -- no debconf information
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 11:47:07PM +0900, Oohara Yuuma wrote: > [for debian-gcc people: please Cc: to me because I am not subscribed] > > On Fri, 16 Aug 2002 14:51:34 +0100, > Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > * If your package contains no C++, do nothing. One fine day, > >gcc-defaults will be changed to gcc-3.2 and you'll start using GCC > >3.2 with no work by yourself. > 1. Does a C (not C++) library compiled with gcc 2.95 work with >a C++ program compiled with gcc 3.2? If the library does not use exceptions in any way then yes, almost certainly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: c/7661: gcc-3.0 optimization bug on debian GNULinux on x86 with very simple program
On Wed, Aug 21, 2002 at 11:28:47PM -0400, Carlos O'Donell wrote: > On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote: > > > I think this program should not terminate at all because i will > > > always be one greater than oldi. > > > I think gcc3.0 has a problem with no optimization then but since > > > there is later version that works gcc 3.1.1, upgrade. > > > > With no optimization the program runs correctly by the rules of integers > > representation in memory. See the explanation below. > > > > Changed my mind. After a posting from Linus on dri-devel and a discussion > about integer overflow (undefined) in C the following came out: > > --- > unsigned int i = 0; > unsigned int oldi = 0; > while ((int) ++i > (int) oldi) oldi = i; > return oldi; > --- > > Looks good... incrementing unsigned (defined overflow) and doing an > unsigned check (both operands). Huh? No. This is not defined as far as I can see. Casting to int does not have defined meaning if the value of the unsigned int doesn't fit in int. [#3] Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation- defined or an implementation-defined signal is raised. Excuse me, it's implementation-defined. That means that GCC must choose a consistent behaviour; it is allowed to choose one such that your loop disappears, as I understand it. (int) [unsigned] may be assumed to be non-negative and thus oldi+1 > oldi. > Anyone care to jump in? :) Don't take my uneducated word for it. Ask comp.lang.c; they know these things. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: GCC 3.2 on the NetBSD/i386 port
On Mon, Sep 02, 2002 at 10:06:51AM -0600, Joel Baker wrote: > On Mon, Sep 02, 2002 at 01:10:08AM -0600, Joel Baker wrote: > > On Mon, Sep 02, 2002 at 08:18:01AM +0200, Martin v. Loewis wrote: > > > Joel Baker <[EMAIL PROTECTED]> writes: > > > > > > > # of expected passes5176 > > > > # of unexpected failures1114 > > > > # of expected failures 977 > > > > # of untested testcases 15 > > > > # of unsupported tests 3 > > > > > > Those you should look at, first. gcc creates a detailed log file of > > > all test cases; I don't know whether this survives the Debian build > > > process, though - it's in /gcc/testsuite. If you still have > > > that, please post the details for three or four failures (preferably > > > those that make up the majority of the 1000 failures). > > > > It does not appear to have survived the build process. However, see the > > further notes below. > > Still broken. However, this time, I have log output - and it makes some > amount of sense to me. > > /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so: > undefined reference to `__dso_handle' > /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so: > undefined reference to `__cxa_atexit' > collect2: ld returned 1 exit status > > I'm not sure about __dso_handle, but I clearly remember having to tweak a > rules.def setting related to atexit in GCC 3.0 and 3.1, and I don't see it > anywhere obvious in 3.2 - and it's explicitly enabled in debian/rules2. This looks like you have a linker bug relating to weak symbol references - both of them are weak, I believe... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: GCC 3.2 on the NetBSD/i386 port
On Mon, Sep 02, 2002 at 03:35:11PM -0600, Joel Baker wrote: > On Mon, Sep 02, 2002 at 10:23:40PM +0200, Martin v. Loewis wrote: > > Joel Baker <[EMAIL PROTECTED]> writes: > > > > > > /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so: > > > > undefined reference to `__dso_handle' > > > > /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so: > > > > undefined reference to `__cxa_atexit' > > > > collect2: ld returned 1 exit status > > [...] > > > So. Given that this clearly appears to be a workaround, that this was in > > > 3.0 or 3.1, and that it must have been removed for good reason (like, it > > > was itself a workaround to a different flaw) - what is the best way to > > > address this? Is there something in userland that can be tweaked to cope > > > with this, or is this an issue with using NetBSD's libc? > > > > It isn't that easy to answer. Are these messages from the static > > linker (ld(1)) or the dynamic linker (ld.so.1(1))? If the static > > linker, what binutils version? > > I believe they're from the dynamic linker (ld.elf_so), in this case. > > > We have to consider __dso_handle and __cxa_atexit separately. For > > __dso_handle, can you tell whether HAVE_GAS_HIDDEN is defined? > > [EMAIL PROTECTED]:/tmp/Build/gcc-3.2-HOLD/gcc-3.2-3.2ds0/src# find . -type f > | xargs grep HAVE_GAS_HIDDEN > ... > ./gcc/config/cris/cris.h:#define HAVE_GAS_HIDDEN 1 > > (All of the others are .in files for autoconf, ChangeLog entries, or > #ifdef macros in various .c files) Autoconf sets it. You need to check in the build tree whether it is set or not. If you're using too old a binutils this could fail, or if there is some problem with your tools or the test... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#160404: sparc: sparc64 (-m64) support disabled
On Tue, Sep 10, 2002 at 03:22:21AM -0700, H. Peter Anvin wrote: > Package: gcc-3.2-base > Version: 1:3.2.1-0pre1 > Severity: important > Tags: sid > > The gcc-3.2-base package for Debian/sid/sparc disables 64-bit > (-m64) support. This is a rather serious omission, since it > means there is no way to build 64-bit binaries, including the > kernel. > > This should be just a configuration change when building the > package. Yes. Ben is working on a way to enable -m64 without also making it the default; he said he'd look at it tonight. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#160978: libstdc++5-dev: constness problem with std::set
On Sun, Sep 15, 2002 at 07:16:41PM +0100, Matt Kern wrote:
> Package: libstdc++5-dev
> Version: 1:3.2.1-0pre1
> Severity: normal
>
> The following fragment generates an error for me:
>
> ==
> #include
> for (WrappedClassList::iterator i=_objects.begin (); i!=_objects.end ();
> ++i)
> WrappedClass* C = (*i).getObjectPtr ();
> test.cpp: In member function `void TestClass::testMethod()':
> test.cpp:27: invalid conversion from `const WrappedClass*' to `WrappedClass*'
>
> I cannot work out if the bug is caused by my installing the debian
> packages on woody rather than unstable. However, the fragment
> compiles correctly if std::vector is used in place of std::set.
>
> If the "const T* getObjectPtr () const { return 0; }" line is removed,
> it gives the following:
>
> test.cpp: In member function `void TestClass::testMethod()':
> test.cpp:26: passing `const AutoPtr' as `this' argument of `T*
>AutoPtr::getObjectPtr() [with T = WrappedClass]' discards qualifiers
That's because set has:
typedef typename _Rep_type::const_iterator iterator;
i.e. set's iterators are actually const_iterators. The STL reference
says:
Const iterator used to iterate through a set. (Iterator and
const_iterator are the same type.)
So I believe this isn't a bug; there are no mutable iterators to sets,
because that would disturb the invariants of set (sorted!).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#163422: g++-3.2 not compiled for Common C++ ABI!
On Sat, Oct 05, 2002 at 06:01:43PM +0200, Herbert Valerio Riedel wrote: > Package: g++-3.2 > Version: 1:3.2.1-0pre2 > Severity: important > > see also > http://gcc.gnu.org/gcc-3.2/c++-abi.html > > "g++-3.2 -v" outputs > > Reading specs from /usr/lib/gcc-lib/alpha-linux/3.2.1/specs > Configured with: /build/buildd/gcc-3.2-3.2.1ds1/src/configure -v > --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared > --with-system-zlib --enable-nls --without-included-gettext > --enable-java-gc=boehm --enable-objc-gc alpha-linux > Thread model: posix > gcc version 3.2.1 20020912 (Debian prerelease) > > which definitely lacks "--enable-__cxa_atexit" > > fyi, other linux distributions (such as redhat-8.0) are using the common > ABI convention, if debian does not, we'll suffer interoperability > problems with shared C++ libs, and we'll render the whole Common C++ ABI > efforts void :-( Did we lose a patch somewhere? We're now using --disable-__cxa-atexit on NetBSD, and nothing elsewhere. But 3.2 cxa-atexit defaults to off, as far as I can tell... The patch at the time said: @@ -62,8 +62,11 @@ CONFARGS = -v \ --enable-shared \ --with-system-zlib \ --enable-nls \ - --without-included-gettext \ - --enable-__cxa_atexit + --without-included-gettext + +ifneq ($(with_cxa_atexit),yes) + CONFARGS += --disable-__cxa_atexit +endif ifeq ($(with_java),yes) CONFARGS += --enable-java-gc=boehm And that doesn't look right at all. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#164554: gcc-3.2: volatile not respected on alpha
On Sun, Oct 13, 2002 at 07:29:24PM +1000, [EMAIL PROTECTED] wrote:
> Package: gcc-3.2
> Version: 1:3.2.1-0pre2
> Severity: normal
>
> The following program produces output where the assignment to j occurs
> before the i has been incremented. This breaks any program using such
> constructs to ensure consistency:
>
> volatile int i;
> int j;
>
> void a() {
> i++;
> j = 6;
> i--;
> }
>
> .prologue 1
> ldq $3,i($29) !literal
> lda $4,6($31)
> ldq $1,j($29) !literal
> ldl $2,0($3)
> stl $4,0($1)
> lda $2,1($2)
> stl $2,0($3)
I don't see the problem. Volatile in C doesn't provide any sort of
barrier; you have to place one yourself if you want one. It only
guaranatees that the two accesses to "i" will not be reordered or
eliminated.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#164554: gcc-3.2: volatile not respected on alpha
On Tue, Oct 15, 2002 at 08:28:02AM +1000, Herbert Xu wrote: > On Mon, Oct 14, 2002 at 06:01:24PM -0400, Daniel Jacobowitz wrote: > > > > I don't see the problem. Volatile in C doesn't provide any sort of > > barrier; you have to place one yourself if you want one. It only > > guaranatees that the two accesses to "i" will not be reordered or > > eliminated. > > My copy of C99 says: > > 5The least requirements on a conforming implementation are: > - At sequence points, volatile objects are stable in the sense that > previou > s accesses are > complete and subsequent accesses have not yet occurred. Only volatile objects are required to be stable. I believe that if "j" were volatile, then you'd see the behaviour you want; but I don't believe accesses to non-volatile objects have the same requirements. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#164554: gcc-3.2: volatile not respected on alpha
On Tue, Oct 15, 2002 at 12:09:56PM +1000, Herbert Xu wrote: > On Mon, Oct 14, 2002 at 07:01:46PM -0400, Daniel Jacobowitz wrote: > > > > > My copy of C99 says: > > > > > > 5The least requirements on a conforming implementation are: > > > - At sequence points, volatile objects are stable in the sense that > > > previou > > > s accesses are > > > complete and subsequent accesses have not yet occurred. > > > > Only volatile objects are required to be stable. I believe that if "j" > > That's right. However, there is a sequence point between i++ and > j=6, so the previous access to i should be completed at that point. But the value of J is not required to coordinate with any sequence points in the implementation, only in the abstract machine... I have (6.7.3 #6) Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.114) What constitutes an access to an object that has volatile-qualified type is implementation- defined. But that paragraph explicitly applies only to volatile qualified types. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#164554: gcc-3.2: volatile not respected on alpha
On Mon, Oct 14, 2002 at 10:31:03PM -0400, Daniel Jacobowitz wrote: > On Tue, Oct 15, 2002 at 12:09:56PM +1000, Herbert Xu wrote: > > On Mon, Oct 14, 2002 at 07:01:46PM -0400, Daniel Jacobowitz wrote: > > > > > > > My copy of C99 says: > > > > > > > > 5The least requirements on a conforming implementation are: > > > > - At sequence points, volatile objects are stable in the sense > > > > that previou > > > > s accesses are > > > > complete and subsequent accesses have not yet occurred. > > > > > > Only volatile objects are required to be stable. I believe that if "j" > > > > That's right. However, there is a sequence point between i++ and > > j=6, so the previous access to i should be completed at that point. > > But the value of J is not required to coordinate with any sequence > points in the implementation, only in the abstract machine... > > > I have (6.7.3 #6) >Furthermore, at every sequence point the value last stored >in the object shall agree with that prescribed by the >abstract machine, except as modified by the unknown factors >mentioned previously.114) What constitutes an access to an >object that has volatile-qualified type is implementation- >defined. > > But that paragraph explicitly applies only to volatile qualified types. BTW, look at asm/spinlock.h: this is why there are __volatile__ markers on the asm, and a "memory" clobber. The clobber prevents the following instructions from being moved before the spinlock is taken. It's worse than that: on a machine with out-of-order memory accesses, your testcase would obviously lose unless GCC inserted explicit memory barriers, and I don't believe it's ever required to do that. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#165829: GCC 3.2 C++ error on virtual function which uses ...
On Mon, Oct 21, 2002 at 08:51:03PM -0400, Reed Hedges wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Package: g++-3.2 > Version: 3.2.1-0pre4 > Severity: important > > GCC 3.2.1 emits the following error: > > foo.cc:16: generic thunk code fails for method `virtual void > B::foo(char*, ...) >' which uses `...' > > when compiling the code included below. The same code compiles & runs > fine with GCC 2.95. The error also does not appear if B does not > subclass from A. This is a known bug. It was fixed in the GCC CVS tree just this week, which means a fix will probably be in 3.3 but no earlier. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#165992: gcc: __builtin_return_address doesn't work properly
On Wed, Oct 23, 2002 at 02:01:47AM -0400, [EMAIL PROTECTED] wrote:
> Package: gcc
> Version: 2:2.95.4-17
> Severity: normal
>
> The following program illustrates that __builtin_return_address seg faults
> when
> you reach the top of the stack rather than returning 0 as it is specified in
> the gcc manual.
>
> I see the same behaviour with both gcc 2.95 and gcc 3.0.
GCC 3.2 says:
On some machines it may be impossible to determine the return
address of any function other than the current one; in such cases,
or when the top of the stack has been reached, this function will
return `0' or a random value. In addition,
`__builtin_frame_address' may be used to determine if the top of
the stack has been reached.
This function should only be used with a nonzero argument for
debugging purposes.
You're running it beyond the top of the stack. It returns a random
value, and then the following call crashes. The documentation is
correct and it really can't do any better.
>
>
> #include
>
> int main () {a();}
> a() {b();}
> b() {c();}
> c()
> {
> printf("%d: %p\n", 0, __builtin_return_address(0));
> printf("%d: %p\n", 1, __builtin_return_address(1));
> printf("%d: %p\n", 2, __builtin_return_address(2));
> printf("%d: %p\n", 3, __builtin_return_address(3));
> printf("%d: %p\n", 4, __builtin_return_address(4));
> printf("%d: %p\n", 5, __builtin_return_address(5));
> }
>
>
> (gdb) run
> Starting program: /tmp/a.out
> 0: 0x804840f
> 1: 0x80483ff
> 2: 0x80483ef
> 3: 0x400450bf
> 4: 0x8048331
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGSEGV, Segmentation fault.
> 0x080484ae in c ()
> (gdb) bt
> #0 0x080484ae in c ()
> #1 0x0804840f in b ()
> #2 0x080483ff in a ()
> #3 0x080483ef in main ()
> #4 0x400450bf in __libc_start_main () from /lib/libc.so.6
>
>
> -- System Information
> Debian Release: testing/unstable
> Kernel Version: Linux stark.dyndns.tv 2.4.19 #6 Tue Sep 10 22:08:51 EDT 2002
> i686 unknown unknown GNU/Linux
>
> Versions of the packages gcc depends on:
> ii cpp2.95.4-17 The GNU C preprocessor.
> ii cpp-2.95 2.95.4-12 The GNU C preprocessor.
> ii gcc-2.95 2.95.4-12 The GNU C compiler.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Re: libstdc++-libc6.2-2.so.3
On Thu, Oct 24, 2002 at 04:34:07PM -0400, Gregory Seidman wrote: > I am developing a program using g++ 3.2. When I added a dynamic_cast, it > started segfaulting on it. In searching the web I came up with the > following: > > http://lists.debian.org/debian-gcc/2002/debian-gcc-200205/msg00240.html > > It suggests that I mght be linking against two different versions of > libstdc++ and, indeed, it seems I am (according to ldd). I proceeded to > apt-get source --compile libglut3 and install it. That fixed the problem, > but ldd gives the same output as before. > > I don't understand why my program seems to be linked to two versions of > libstdc++. It looks like libstdc++.so.5 is the g++ 3.2 library, but there > is also that libstdc++-libc6.2-2.so.3 which nothing seems to use. Can > anyone explain this extraneous dependency? > > The output from ldd -v is below. Presumably something is not linking using GCC 3.2. Are you linking using g++ instead of g++-3.2? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: libstdc++-libc6.2-2.so.3
On Thu, Oct 24, 2002 at 04:48:25PM -0400, Gregory Seidman wrote: > Daniel Jacobowitz sez: > } On Thu, Oct 24, 2002 at 04:34:07PM -0400, Gregory Seidman wrote: > } > I am developing a program using g++ 3.2. When I added a dynamic_cast, it > } > started segfaulting on it. In searching the web I came up with the > } > following: > } > > } > http://lists.debian.org/debian-gcc/2002/debian-gcc-200205/msg00240.html > } > > } > It suggests that I mght be linking against two different versions of > } > libstdc++ and, indeed, it seems I am (according to ldd). I proceeded to > } > apt-get source --compile libglut3 and install it. That fixed the problem, > } > but ldd gives the same output as before. > } > > } > I don't understand why my program seems to be linked to two versions of > } > libstdc++. It looks like libstdc++.so.5 is the g++ 3.2 library, but there > } > is also that libstdc++-libc6.2-2.so.3 which nothing seems to use. Can > } > anyone explain this extraneous dependency? > } > > } > The output from ldd -v is below. > } > } Presumably something is not linking using GCC 3.2. Are you linking > } using g++ instead of g++-3.2? > > Nope: > > % which g++ > /usr/bin/g++ > % ls -l /usr/bin/g++ > lrwxrwxrwx1 root root7 Sep 16 18:04 /usr/bin/g++ -> > g++-3.2* > % g++ --version > g++ (GCC) 3.2.1 20021020 (Debian prerelease) > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Note in the ldd -v output that *nothing*, including the executable > itself, depends on that weird libstdc++; it's just there. Two things to check: - Is it really happening? Run the application and check in /proc//maps for the two copies of libstdc++. - Is ldd lying? Check the libraries and app with objdump -p. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#165992: gcc: __builtin_return_address doesn't work properly
On Fri, Oct 25, 2002 at 10:59:29AM +0200, Martin v. Loewis wrote: > Greg Stark <[EMAIL PROTECTED]> writes: > > > Well, that's not what my documentation from GCC 2.95 says: > > > > On some machines it may be impossible to determine the return > > address of any function other than the current one; in such cases, > > or when the top of the stack has been reached, this function will > > return `0'. > > So you have found a bug in the 2.95 documentation. Just imagine it > would have the same text as the 3.2 documentation. Except that I don't know whether __builtin_frame_address can be used in 2.95. Also, Greg, be aware that despite the comment you can't _necessarily_ use __builtin_frame_address above frame 0. That's just the risk you take; thus the comment about "for debugging use only". > > I'm puzzled why I can use __builtin_frame_address to determine if > > the top of the stack has been reached but gcc's builtin can't do the > > same for me. I must be missing something, how do gdb and other tools > > happily decode stack traces all the time without crashing? > > They are not very happy in doing so :-) They use lots of heuristics > which are unavailable to __builtin_return_address. GDB will not crash from reading memory, because it cheats and reads in a crash-proof way :) For i386 and PPC you can use backtrace() in glibc. In fact, in general it's usable; I see special support for PPC, i386, ARM, s390, and HPPA. And it's more reliable than your method, too. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Problem with VIA C3 chip and libcrypto
On Tue, Nov 05, 2002 at 04:14:42PM -0200, Henrique de Moraes Holschuh wrote: > On Tue, 05 Nov 2002, Oliver M. Bolzer wrote: > > Nevertheless, it IS a real problem. As the cmov instruction is OPTIONAL > > for i686 but GCC uses it for 686, that is the cause of the problem. That > > the kernel compiles itself as 585 if a C3 is specified is simply a > > work-around. The correct solution is to fix GCC, but for now, can we > > either not ship a i686-optimized libssl or just hardlink the > > i585-version into the i686-directory ? We have lived with the i386 > > version long enough, using a slightly less optimized version for the > > time being is MUCH better than simply breaking on C3 machines. > > That's no real fix. Any other binary compiled for i686 will break royally > on C3. The correct workaround is to downgrade it kernel-wise to a i586 > until gcc is fixed, and all i686 stuff recompiled... or teach ld.so to think > that a C3 is a i586 for the time being. I note that Alan just moved the kernel from compiling using -march=i586 to -march=i486, in the absence of -march=c3. GCC's policy seems to be to call the c3 a 486... perhaps the kernel is the one which should change. The best place to pursue this conversation is probably on the GCC list or on linux-kernel, however. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: new libstdc++ failures
On Wed, Nov 13, 2002 at 09:48:36AM -0500, Jack Howarth wrote: > Dan, > We seem to be suddenly failing 7 additional libstd-c++ tests > in last nights gcc-3.2 build. This isn't happening on entropy so > I am wondering if we have lost those keymaps essential for the > testsuite to pass. If I recall correctly keymaps for French, German > and Itailian have to be installed for some of those tests. We > might want to check the ppc build machines for those. >Jack It doesn't even have locales installed. It hasn't ever, either, I think. I've added them. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: C++ library broken
On Wed, Nov 13, 2002 at 06:41:24PM -0800, Brian Nelson wrote: > Alex Romosan <[EMAIL PROTECTED]> writes: > > > Brian Nelson <[EMAIL PROTECTED]> writes: > > > >> apt-get: error while loading shared libraries: libstdc++-libc6.2-2.so.3: > >> cannot open shared object file: No such file or directory > >> > > > > just do: > > > > ln -s libstdc++-3libc6.2-2-2.10.0.so libstdc++-libc6.2-2.so.3 > > > > in /usr/lib and that will fix the problem. > > That will not fix the problem of brain-damaged developers not minimally > testing packages before upload, especially important ones, which is the > real problem in this case. Have you thought about the problem? Maybe a little bit? Understood what's going on? It's perfectly easy to test the packages without catching this sort of problem. Don't throw stones. Instead politely suggest to debian-gcc that the link be added and gcc-2.95 be reuploaded. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#169161: libstdc++5: Questionable type usage in mangled names
forwarded 169161 [EMAIL PROTECTED] thanks This should presumably be reported to GCC rather than to us... Libstdc++ folks, please maintain the CC's. Any thoughts? On Thu, Nov 14, 2002 at 09:13:37PM -0500, Stuart Anderson wrote: > Package: libstdc++5 > Version: 1:3.2.1-0pre6 > Severity: normal > Tags: upstream > > > Underlying types are used when creating the mangled name of symbols in C++. In > libstdc++, many symbols contains the type mbstate_t. As encoded in the mangled > name, the underlying type, __mbstate_t is used. When unmangled, this results > in a different source name than what was used in the source. > > Here is an example: > > libstdc++ contains the symbol _ZNKSt7codecvtIcc11__mbstate_tE11do_encodingEv. > c++filt de-mangles this as > > std::codecvt::do_encoding() const, > > which is not the same thing as in the ISO C++ specification, which would be > > std::codecvt::do_encoding() const > > (ref ISO C++ 22.2.1.5). The difference is __mbstate_t vs mbstate_t. > > It seem that an unmangling operation should produce the original source > symbol. > > This seems like it may be an ABI issue as the C++ headers produce different > mangled symbol if headers other than GNU libc headers are used. We ran into > this when testing the LSB development environment in conjunction with C++. The > LSB description of mbstate_t is a typedef of an anonymous structure, and > doesn't have the intermediate __mbstate_t as the glibc headers do. Since > __mbstate_t doesn't seem to be present in the source standards, we didn't want > to include it in the LSB descriptions. > > > -- System Information: > Debian Release: testing/unstable > Architecture: i386 > Kernel: Linux bego 2.4.18 #25 Tue Aug 6 14:04:58 EDT 2002 i686 > Locale: LANG=C, LC_CTYPE=C > > Versions of packages libstdc++5 depends on: > ii gcc-3.2-base 1:3.2.1-0pre6 The GNU Compiler Collection > (base > ii libc6 2.3.1-3 GNU C Library: Shared libraries > an > ii libgcc11:3.2.1-0pre6 GCC support library. > > -- no debconf information > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: gcc 3.2.1, debian and TLS ( __thread keyword ) support
On Wed, Nov 27, 2002 at 12:58:32PM -0500, Phil Edwards wrote: > On Wed, Nov 27, 2002 at 05:46:28PM +, Loic Jaquemet wrote: > > I search a bit in the gcc CVS, and found that gcc's CVS was patched > > around May 2002 > > ( > > http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.h?rev=1.137&content-type=text/x-cvsweb-markup > > ) to support(parse at least) this option ? > > I don't find it in debian's gcc 3.2.1ds6 sources .. ( that's should be > > why it doesn't work ;) ) > > Am i mistaken ? Is it a bug or a packaging choice or a different branch > > ? > > A different branch. TLS support was added to GCC's main development branch. > The 3.2 branch didn't get it, because the release branches must stay stable, > and changes like TLS tend to be destabilizing. > > You can try tracking the gcc-snapshot package, since you're using unstable. ... - but we may want to consider examining the rhl8 CVS branch for patches; it would be nice to support this in our 3.2 packages if it's relatively painless, and I think it is. Large, but painless, since RH did the work already. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#171748: gcc-3.2: GCC doesn't accept the -a option
On Wed, Dec 04, 2002 at 01:30:21PM -0500, Paul Smith wrote: > Package: gcc-3.2 > Version: 1:3.2.1-0pre3 > Severity: normal > > Using GCC 3.2 with -a gives this error: > > gcc-3.2 -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" > -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. -g -pg -a -c ar.c > cc1: unrecognized option `-a' > > Using the same options with GCC 2.95 or GCC 3.0 works fine. And, the > Info pages in gcc-3.2-doc package still list -a as a valid option. Oops, it was removed in one place and not in the other, it's still mentioned: `-a' Generate extra code to write profile information for basic blocks, which will record the number of times each basic block is executed, the basic block start address, and the function name containing the basic block. If `-g' is used, the line number and filename of the start of the basic block will also be recorded. If not overridden by the machine description, the default action is to append to the text file `bb.out'. This data could be analyzed by a program like `tcov'. Note, however, that the format of the data is not what `tcov' expects. Eventually GNU `gprof' should be extended to process this data. Paul, scroll down a little to find -fprofile-arcs -ftest-coverage, which is what you want now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
3.2 transition
Reference: http://people.debian.org/~rmurray/c++transition.html, which seems to be the latest copy. My understanding is that GCC 3.2 now works on all architectures. That means we're now past the last big blocker waiting for the transition. Does anyone know of anything else holding us up, besides someone to manage the process? If not, it sounds like it's time to begin. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: 3.2 transition
On Sun, Dec 15, 2002 at 09:59:34PM -0500, Ben Collins wrote: > On Sun, Dec 15, 2002 at 11:16:41PM +, Dr. David Alan Gilbert wrote: > > * Daniel Jacobowitz ([EMAIL PROTECTED]) wrote: > > > Reference: http://people.debian.org/~rmurray/c++transition.html, which > > > seems > > > to be the latest copy. > > > > > > My understanding is that GCC 3.2 now works on all architectures. That > > > means > > > we're now past the last big blocker waiting for the transition. Does > > > anyone > > > know of anything else holding us up, besides someone to manage the > > > process? > > > > > > If not, it sounds like it's time to begin. > > > > I wonder how well tested it is on all architectures? I'd worry about > > things like exception handling and threading being fully tested on all > > architectures. > > > When we say "works on all architectures" that means it passes the > regression tests as expected. That's no trivial thing either. Actually, someone needs to find out why the regression tests hang on m68k that's sort of important. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: [eng@eipm.ch: mklibs doesn't manage to include symbol atexit]
On Mon, Dec 16, 2002 at 10:53:06AM +0100, Raphael Hertzog wrote: > Hello glibc/gcc maintainers, > > I have a problem with generating a reduced libc6 using the PIC version. > I don't know if the problem comes from libc6, from gcc or from myself. > I asked on debian-boot but nobody answered since the problem doesn't > appear to come from mklibs bur rather glibc and/or gcc. > > Please take a quick look to the attached mail. I'd appreciate any > idea to help me investigate further but right now I'm blocked because > I don't know enough of glibc/gcc ... > i'm using mklibs at work here and I have a problem with it. One of the > binaries that I use (lilo-mtd) requires the symbol "atexit" and mklibs > doesn't manage to include it in the libc6 generated from the -pic > version. First of all, if lilo-mtd were properly linked, then this wouldn't happen. Look in /usr/lib/libc_nonshared.a, which is supposed to provide the definition of atexit. Looks like your lilo-mtd hasn't been recompiled in a Very Long Time. Second of all, > $ objdump -T tmp/empty/tree/sbin/lilo-mtd | grep atexit > 08048edc DF *UND*003e atexit > > This symbol is provided by the standard libc6 : > $ objdump -T /lib/libc.so.6 | grep atexit > 0010cc54 ld __libc_atexit > 00028e30 gDF .text0034 (GLIBC_2.0) atexit > 00028c74 gDF .text0045 GLIBC_2.1.3 __cxa_atexit That means atexit is "hidden". It is not available for compile-time linking. mklibs isn't handling that correctly; easier is to avoid it. Looks like it needs to search libc_nonshared.a in addition to libc_pic.a. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: 3.2 transition
On Mon, Dec 16, 2002 at 09:30:32AM +0100, Matthias Klose wrote: > Daniel Jacobowitz writes: > > On Sun, Dec 15, 2002 at 09:59:34PM -0500, Ben Collins wrote: > > > On Sun, Dec 15, 2002 at 11:16:41PM +, Dr. David Alan Gilbert wrote: > > > > * Daniel Jacobowitz ([EMAIL PROTECTED]) wrote: > > > > > Reference: http://people.debian.org/~rmurray/c++transition.html, > > > > > which seems > > > > > to be the latest copy. > > > > > > > > > > My understanding is that GCC 3.2 now works on all architectures. > > > > > That means > > > > > we're now past the last big blocker waiting for the transition. Does > > > > > anyone > > > > > know of anything else holding us up, besides someone to manage the > > > > > process? > > > > > > > > > > If not, it sounds like it's time to begin. > > > > > > > > I wonder how well tested it is on all architectures? I'd worry about > > > > things like exception handling and threading being fully tested on all > > > > architectures. > > > > > > > > > When we say "works on all architectures" that means it passes the > > > regression tests as expected. That's no trivial thing either. > > > > Actually, someone needs to find out why the regression tests hang on > > m68k that's sort of important. > > that's simple, m68k is getting better, not many regressions in the > testsuite, and then the buildd timeout hits ;-) It should be fixable > within 72 hours (the time gcc needs to build on m68k). Oh. He he he he he. Should we run a little script to fix this... it could just: - check the last line in the gcc.log - If it has changed, print "testsuite running..." - Sleep for twenty minutes -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: 3.2 transition
On Mon, Dec 16, 2002 at 08:56:43PM +0900, Junichi Uekawa wrote: > > On the FAQ: > > Why don't we put the libs in a different directory? > > Basically, it's too complex. For the glibc transition, we could do > this because they used different dynamic linkers. For this > transition, there is also little to gain in having full backwards > compatibility to the old ABI. The only gain is that third party > binary only applications that dynamically link to C++ using-libs > (other than the stdc++ library itself) continue to work. The only > common case that comes to mind for this is libqt2 and kdelibs3. Both > of these packages are old, so to keep binary compatibility with > previous versions of our distribution (and some other distributions) > is easy. We continue to build libqt2 and all dependant packages with > g++-2.95. Anything using libqt3, will build with the new ABI, along > with other C++ libraries. > > > > > I've thought having a directory for doing LD_LIBRARY_PATH might help people > keep compatibility > with other dists or legacy applications, > > thoughts? That's reasonable, I suppose. It would have to be for the oldlibs version; then we could do it after we're into the transition. The new versions should go in the normal locations IMO. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#174303: I must add manuality a -I/usr/lib/gcc-lib/i386-linux/3.2.2/include fordefault by the compiler.
On Thu, Dec 26, 2002 at 12:48:08AM +0100, Alberto Rodriguez Ortega wrote: > Package: gcc-3.2 > Version: 1:3.2.2-0pre2 > Severity: normal > Tags: sid To do what? When compiling what? This isn't a bug report. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#168871: Need help with Segmentation fault
On Mon, Dec 30, 2002 at 12:25:59PM -0600, Earl Hood wrote: > On December 30, 2002 at 00:18, Jeff Breidenbach wrote: > > > >The format=flowed code appears to cause perl to go into an infinite loop > > >with the regex patterns used to process format=flowed data. I was > > >able to crash v5.6.1 and v5.8.0 of perl under linux. > > > > It looks like Debian is tracking this same problem as a Perl bug. Even > > if future MHonArcs no longer trigger the segfault, I assume our Perl > > package maintainer should keep the bug open? (Under the perl > > segfault = bug theory) > > Perl should "never" segfault, unless some XS module is at work (ie. > there is no guarantees when mucking with the internals). > > Now, it is not definite that an infinite loop occurred, or if it is was > a degenerate case were a very deep recursive call overflowed the stack. > When I looked at the core file in gdb, the call stack was very very very > deep and it appeared to look like an infinite recursion problem. I believe it is the latter from your description, and a known problem in the Perl 5.8 regular expression engine... however, I believe that what I'm thinking of didn't affect 5.6.1, so take this with a grain of salt. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: help needed with logwatcher in 3.2.2ds3
On Wed, Jan 01, 2003 at 07:29:13PM +0100, Matthias Klose wrote:
> This build includes a logwatcher in debian/rules2 in the check
> target. It prints out a line, if the testsuite is still running, but
> no messages are written to stdout (due to no test cases failing). The
> process is started in the background, and after the testsuite
> finishes, it is killed ... should be killed. There is still one
> logwatch process hanging around. Any idea, why and how to kill this
> one?
Try adding "exit 0" to the end of cleanup(){}; then it works for me.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#168346: bug fixed in gcc-3.x using -std=c99
On Thu, Jan 02, 2003 at 02:58:54AM +0100, Matthias Klose wrote: > Starting with gcc-3.x, gcc accepts the option -std=c99. using this > option LLONG_MAX is defined. Please could someone verify, that > LLONG_MAX is required by C99, but not LONG_LONG_MAX. According to my copy of the standard, this is correct. LONG_LONG_MAX is not mentioned at all. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#175251: gcc-3.2: evil timeout avoidance script doesn't die!
On Sat, Jan 04, 2003 at 12:51:19AM +, James Troup wrote: > Package: gcc-3.2 > Version: 1:3.2.2ds3-0pre3 > > I noticed a local buildd had hung while building gcc-3.2; I checked > why and it turns out the evil logwatch.sh script hadn't died even tho > the build had finished. The script is fairly clearly broken (you trap > the SIGHUP you send it but then don't exit from the function you trap > into?) and the only reason it finished at all on the Debian buildds is > that sbuild's inactivity timeout kicked in[1]. Doh. Yeah. This is fixed in CVS now (yesterday, I think?). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: gcc-3.2 not autobuilding on ARM?
On Wed, Jan 08, 2003 at 10:58:01AM -0500, Nathanael Nerode wrote: > Further investigation indicates that it's almost certainly due to bogus line > breaks in the middle of the command line. This appeared when autobuilding > ds3-0pre3, but not ds2-0pre3, and only on ARM. > > I still don't know where the line breaks are coming from. Are you looking at the same log I am? More likely the breaks are just emitted due to the logs being passed back and forth via email; mail daemons have this odd prejudice against buffer-overflowing length lines. It's failing linking libjava. If I had to guess, I'd say that it ran out of memory. Libjava is stupidly large. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#175809: Strange or incorrect floating point behaviour
On Wed, Jan 08, 2003 at 10:16:35AM +0100, Gerhard Wesp wrote:
> Package: g++-3.2
> Version: 3.2.2 20021212 (Debian prerelease)
>
> Note that this problem most likely is present in other g++ versions, and
> also, in similar forms, in other gcc languages.
>
> It was discussed in comp.lang.c++.moderated, cf.
> news:<[EMAIL PROTECTED]> and the followup postings.
> Posters suggested it might be a bug in the implementation of
> -ffloat-store and/or related to floating point expressions evaluated at
> compile-time and at runtime with different precisions.
>
> Mathematically, a >= b implies ka >= kb for k >= 0. While I'm well
> aware that not all properties of the reals carry over to floating point
> arithmetic, I certainly would expect this *particular* implication to
> carry over. However, g++ -O3 thinks otherwise.
> My first guess was that this has something to do with internal usage of
> 80 bit floating point values, but this doesn't go well with observation
> 4).
I don't _think_ this is a bug, but my floating point fu is fairly weak.
> #include
>
> #if 1
> template< typename T > inline void bound( T & x , T const& u
> ) {
> #else
> inline void bound( double& x , double const& u
> ) {
> #endif
> assert( 1. <= u ) ;// (1)
> if( x < 1. ) { x = 1. ; } // (2)
> if( x > u ) { x = u ; }
> }
At whatever particular flags work or not, I bet this is complex enough
to cause or not cause the value to be computed at run time. Roughly.
> int main() {
> const double u = 2.1 ;
2.1 can not be represented precisely in IEEE FP, of course.
> double x = 3 ;
>
> bound( x , u ) ;
>
> assert( u >= x ) ;
> assert( 2.5*u >= 2.5*x ) ; // fails!!!
The compiler is certainly allowed to compute 2.5*u at compile time. It
does so using an extremely high precision real library, if I recall
correctly. This could be a bug in that library but it's more likely
that the result is a more accurate answer to one bit or thereabouts.
Use a debugger/disassembler? Tell us what the numbers actually _are_?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#175809: Strange or incorrect floating point behaviour
On Thu, Jan 09, 2003 at 11:51:55AM +0100, Gerhard Wesp wrote: > > The compiler is certainly allowed to compute 2.5*u at compile time. It > > I'd suggest -ffloat-store should also apply to such compile-time > computations to be consistent. Does this sound reasonable? Look at the 3.2 documentation... Use `-ffloat-store' for such programs, after modifying them to store all pertinent intermediate computations into variables. Do you get the expected results if you do this? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#175809: Strange or incorrect floating point behaviour
On Fri, Jan 10, 2003 at 11:58:33AM +0100, Gerhard Wesp wrote: > > Do you get the expected results if you do this? > > Yes and no. > > I include a modified example. > > The assertion fails if compiled with -O3 -ffloat-store -DA, it doesn't > if compiled without the -DA. So it seems to depend on where the > assignments take place. > #if defined( A ) > double ku ; > double kx ; > assert( ( ku = 2.5 * u ) >= ( kx = 2.5 * x ) ) ; // fails. > #else > double ku = 2.5 * x ; > double kx = 2.5 * u ; > assert( ku >= kx ) ; // doesn't fail. > #endif Yup, that's C for you. The former uses the value of 2.5*u, the latter uses the value of ku. You can see how this works by declaring ku volatile and looking at the assembly; it'll be reloaded in the second case but not the first. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#176797: libstdc++5: GDB looks in the wrong place for libstdc++ headers
On Wed, Jan 15, 2003 at 02:15:04AM -0600, Daniel E Baumann wrote: > Package: libstdc++5 > Version: 1:3.2.2-0pre5 > Severity: important > > When running my c++ program from inside gdb I get the following: > > [EMAIL PROTECTED]:~/software/src/cvs/gsim/src/examples/mm1$ gdb .libs/mm1 > GNU gdb 5.3-debian > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-linux"... > (gdb) run > Starting program: > /home/danielb/software/src/cvs/gsim/src/examples/mm1/.libs/mm1 > [New Thread 16384 (LWP 20311)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 20311)] > 0x400313b6 in bool std::has_facet >(std::locale > const&) ([EMAIL PROTECTED]) > at /usr/include/g++-v3/bits/locale_facets.tcc:87 > 87 /usr/include/g++-v3/bits/locale_facets.tcc: No such file or > directory. > in /usr/include/g++-v3/bits/locale_facets.tcc That's not enough information. How was this built? What libraries is it really linked to? What headers are really opened during build? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#176797: libstdc++5: GDB looks in the wrong place for libstdc++ headers
On Wed, Jan 15, 2003 at 05:13:14PM -0600, Daniel E Baumann wrote: > On Wed, Jan 15, 2003 at 03:05:55PM -0500, Daniel Jacobowitz wrote: > > On Wed, Jan 15, 2003 at 02:15:04AM -0600, Daniel E Baumann wrote: > > > Package: libstdc++5 > > > Version: 1:3.2.2-0pre5 > > > Severity: important > > > > > > When running my c++ program from inside gdb I get the following: > > > > > > [EMAIL PROTECTED]:~/software/src/cvs/gsim/src/examples/mm1$ gdb .libs/mm1 > > > GNU gdb 5.3-debian > > > Copyright 2002 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and you > > > are > > > welcome to change it and/or distribute copies of it under certain > > > conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. > > > This GDB was configured as "i386-linux"... > > > (gdb) run > > > Starting program: > > > /home/danielb/software/src/cvs/gsim/src/examples/mm1/.libs/mm1 > > > [New Thread 16384 (LWP 20311)] > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > [Switching to Thread 16384 (LWP 20311)] > > > 0x400313b6 in bool std::has_facet >(std::locale > > > const&) ([EMAIL PROTECTED]) > > > at /usr/include/g++-v3/bits/locale_facets.tcc:87 > > > 87 /usr/include/g++-v3/bits/locale_facets.tcc: No such file or > > > directory. > > > in /usr/include/g++-v3/bits/locale_facets.tcc > > > > That's not enough information. How was this built? What libraries is > > it really linked to? What headers are really opened during build? > > It was built with g++-3.2 so it is linked to libstdc++5 (well, and my > lib gsim, gnu common c++ built from cvs and gnu scientific > library, etc.). It uses the headers in /usr/include/c++/3.2 which is where > they are for libstdc++5[-dev], AFAIK. OK, so that's not it. What file actually includes the path g++-v3? Just check using GNU grep. It might be one of your libraries. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Bug#164766: Problem with VIA C3 chip and libcrypto
On Fri, Jan 17, 2003 at 09:39:44AM +0900, GOTO Masanori wrote: > At 16 Jan 2003 18:38:07 +, > Philip Blundell wrote: > > So, per our IRC discussion this afternoon, I think the current plan for > > this is to have ld.so treat CMOV as an optional extension, similar to > > how MMX is handled. In other words: > > > > - Add CMOV to HWCAP_IMPORTANT in glibc. > > > > - Ask the maintainers of openssl and any other affected packages to put > > their cmov-using libraries in /lib/i686/cmov. > > > > - If openssl wants to ship a specific C3-compatible build that only > > uses mandatory i686 features, it can go in /lib/i686. > > Thanks Philip for summarizing. > We debian-glibc team plan to prepare cmov-aware libc6. > > > To make sure for other people, I add some more words. > > This libc ld.so special handling for hardware capability is used by > only MMX currently. We expand it not only for MMX but also CMOV. > MMX, intel's multi media extension, is also same circumstance that > both Pentium (i586) and Pentium MMX (i586 MMX) are 'i586 class > processors'. This bit is a good idea but... > Well, his stance is not wrong. > > We can hack gcc not to generate CMOV code with (for example) -mcpu=c3, > or -mno-cmov (like -mno-mmx), but stil this hardware capability > handling is needed for dynamic libraries. > > In addition, We don't provide any cmov checking for 'binaries which > are hand-assembled or gcc generated'. Hand-assembled binaries should > check cmov flag like mmx. If you get 'illegal instruction' with such > binaries, you submit BTS for such packages. It's another issue that a > binary is optmized as i686 with cmov instruction by gcc. You need to > consider how to fix. I anticipate that it may need to make gcc > non-cmov aware. Let's not do anything about this until someone gets clarification from GCC that -march=i686 is not actually supposed to be a 686, OK? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#176797: libstdc++5: GDB looks in the wrong place for libstdc++ headers
On Fri, Jan 17, 2003 at 01:16:21PM -0600, Daniel E Baumann wrote: > On Fri, Jan 17, 2003 at 09:32:38AM -0500, Daniel Jacobowitz wrote: > > On Wed, Jan 15, 2003 at 05:13:14PM -0600, Daniel E Baumann wrote: > > > On Wed, Jan 15, 2003 at 03:05:55PM -0500, Daniel Jacobowitz wrote: > > > > On Wed, Jan 15, 2003 at 02:15:04AM -0600, Daniel E Baumann wrote: > > > > > Package: libstdc++5 > > > > > Version: 1:3.2.2-0pre5 > > > > > Severity: important > > > > > > > > > > When running my c++ program from inside gdb I get the following: > > > > > > > > > > [EMAIL PROTECTED]:~/software/src/cvs/gsim/src/examples/mm1$ gdb > > > > > .libs/mm1 > > > > > GNU gdb 5.3-debian > > > > > Copyright 2002 Free Software Foundation, Inc. > > > > > GDB is free software, covered by the GNU General Public License, and > > > > > you > > > > > are > > > > > welcome to change it and/or distribute copies of it under certain > > > > > conditions. > > > > > Type "show copying" to see the conditions. > > > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > > > details. > > > > > This GDB was configured as "i386-linux"... > > > > > (gdb) run > > > > > Starting program: > > > > > /home/danielb/software/src/cvs/gsim/src/examples/mm1/.libs/mm1 > > > > > [New Thread 16384 (LWP 20311)] > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > [Switching to Thread 16384 (LWP 20311)] > > > > > 0x400313b6 in bool std::has_facet >(std::locale > > > > > const&) ([EMAIL PROTECTED]) > > > > > at /usr/include/g++-v3/bits/locale_facets.tcc:87 > > > > > 87 /usr/include/g++-v3/bits/locale_facets.tcc: No such file > > > > > or > > > > > directory. > > > > > in /usr/include/g++-v3/bits/locale_facets.tcc > > > > > > > > That's not enough information. How was this built? What libraries is > > > > it really linked to? What headers are really opened during build? > > > > > > It was built with g++-3.2 so it is linked to libstdc++5 (well, and my > > > lib gsim, gnu common c++ built from cvs and gnu scientific > > > library, etc.). It uses the headers in /usr/include/c++/3.2 which is where > > > they are for libstdc++5[-dev], AFAIK. > > > > OK, so that's not it. What file actually includes the path g++-v3? > > Just check using GNU grep. It might be one of your libraries. > > No files include g++-v3. I grepped and got nothing. This makes sense > becase those headers are from libstc++3, IIRC, which I am not using. I > don't understand why gdb wants to pull headers from there. This makes > no sense to me. No, let me rephrase. Check the binary and every library listed in the ldd output for references to that directory. There should be at least one; where is it? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Bug#164766: Problem with VIA C3 chip and libcrypto
On Tue, Jan 28, 2003 at 02:39:06AM +0900, GOTO Masanori wrote:
> At Mon, 27 Jan 2003 11:39:43 -0500 (EST),
> Alan Cox wrote:
> > > >>>>>GCC 3.2 still uses CMOVE instructions on -march=i686.
> > > >>>>>
> > > >>>>>On the other hand:
> > > >>>>> {"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW},
> > > >>>>>GCC disagrees with you that the C3 is an i686.
> >
> > gcc uses i486 scheduling because that gives best performance
> >
> > The situation is as follows
> >
> > gcc "i686" definition is wrong. The gcc people wont fix it because the 686
> > definition without cmov is mostly useless anyway.
>
> Thanks for your explanation. Hmm. "cmov" is really key instruction...
>
> I think it may be needed that we add -mcpu=c3 for gcc, which generates
> i686 without cmov instruction.
It's already there in development GCC versions. I think Andi Kleen did
it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#179712: gcc-3.2 -O2 miscompilation (i386)
On Tue, Feb 04, 2003 at 05:02:10AM +0200, Marko Kreen wrote:
> Package: gcc-3.2
> Version: 1:3.2.2-0pre8
> Severity: normal
>
>
> gcc-3.2 -O2 miscompiles following program:
>
> -
> extern int write(int fd, void *buf, int len);
> extern int toupper(int c);
>
> void strupr (char *s)
> {
> while (*s)
> *s++ = toupper(*s);
> }
>
> int main(int argc, char *argv[])
> {
> char s[] = "foo";
> strupr(s);
> write(1, s, 3);
> write(1, "\n", 1);
> return 0;
> }
>
> -
> $ gcc-3.2 -Wall -O2 -o test test.c
> test.c: In function `strupr':
> test.c:7: warning: operation on `s' may be undefined
> $ ./test
> OO
> $
> -
>
> gcc-2.95 compiles it correctly, also gcc-3.2 when optimizing
> less than -O2. When the "toupper(*s)" is replaced with "*s & 0x5f"
> gcc-3.2 -O2 also works and without warning.
I think the lack of warning in that case is actually the bug, but I'm
not sure. C doesn't guarantee order-of-operation across an equals
sign; it's not a sequence point. The function call is a sequence point
but it isn't specified which side of the sequence point the increment
will happen on.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#180129: g++-3.2: please use --enable-__cxa_atexit
On Fri, Feb 07, 2003 at 12:02:41PM -0700, Joel Baker wrote: > [ __cxa_atexit broke again ] > > Okay, folks. I suspect this is a problem with the stuff in rules.conf that > detects NetBSD (which does NOT support cxa-atexit) colliding with the i386 > arch (can I say, once again, how much I hate the situation that allows i386 > to be string-confused with netbsd-i386?) > > Please, please, can we try to figure out a patch that works on both, and > test it in BOTH places, before committing? I no longer trust myself to > not screw it up, and I don't have an unstable-based i386 box to spare > for testing it (I will, however, be happy to test any proposed change > on a netbsd-i386 box - in fact, for what it may be worth, the canonical > as-close-to-an-autobuilder-as-we-get-yet box). This is the problem with using findstring... Try: no_cxa_archs := :netbsd-i386: ifeq (:$(DEB_HOST_ARCH):, $(findstring :$(DEB_HOST_ARCH):,$(no_cxa_archs))) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#180266: cpp-3.2: Program does not terminate, spews out random chars at EOF
On Sat, Feb 08, 2003 at 09:28:40AM -0800, Randolph Chung wrote: > tag 180266 +unreproducible +moreinfo > thanks > > > You can't compile any C or C++ programs because the CPP is going > > to dump some memory (or whatnot) beginning at EOF. > > > > Suggestion: Maybe you guys should be doing a make check before packing > > those binaries up. > > Suggestion: Maybe you should check how the package is built before > filing a bug like this? > > bash-2.05b$ uname -a > Linux aragorn 2.4.18 #4 Sat Oct 12 23:34:24 PDT 2002 i686 unknown unknown > GNU/Linux > bash-2.05b$ dpkg -l|grep gcc-3.2 > ii gcc-3.23.2.2-1The GNU C compiler > ii gcc-3.2-base 3.2.2-1The GNU Compiler Collection (base package) > bash-2.05b$ cd /usr/share/doc/gcc-3.2 > bash-2.05b$ zcat test-summary.gz > Results for 3.2.2 testsuite on i386-pc-linux-gnu > LAST_UPDATED: > Native configuration is i386-pc-linux-gnu > [...] > > === gcc Summary === > > # of expected passes18661 > # of expected failures 68 > # of unsupported tests 43 > /home/rmurray/debian/gcc-3.2-3.2.2ds8/build/gcc/xgcc version 3.2.2 > > All gcc packages run through make check during the build process. I've > built quite a lot of stuff with this new gcc already, maybe your problem > is elsewhere? (xfs comes to mind...) > > or if you still think this is a gcc problem, at least post a test > case... Neil Booth points out that some XFS versions have a problem with not NULL-padding a mmap(). That's probably it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: cpp oddness
On Sun, Feb 09, 2003 at 12:40:07PM -0500, Clint Adams wrote:
> > 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: "TEST_SEVEN" is not defined
> test.c:25:2: warning: #warning 4 and 7 claim to be equal
> enum __stuff { TEST_FOUR = 4, TEST_SEVEN = 7 };
> # 28 "test.c"
> test.c:33:2: warning: #warning TEST_THREE defined
> test.c:36:2: warning: #warning TEST_EIGHT defined
> test.c:39:6: warning: "TEST_THREE" is not defined
> test.c:39:20: warning: "TEST_EIGHT" is not defined
> test.c:40:2: warning: #warning 3 and 8 claim to be equal
> enum __stuffandnonsense { TEST_THREE = 3, TEST_EIGHT = 8 };
>
> Note the contradiction.
No bugs. You may want to pick up a copy of the standard - I'm not sure
offhand if any of this is in the GCC manual... aha, it is. Try "info
cpp-3.2 If".
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Oops
reopen 180306 thanks Sorry about that, folks, I just assumed it had been filed on GCC. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: cpp oddness
On Sun, Feb 09, 2003 at 04:47:55PM -0500, Clint Adams wrote: > > 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? They're enums, right? Yes, it's impossible. Enums aren't processed until a later stage of compilation, when preprocessing is already finished. The only thing "#define A A" accomplishes is to let you use #ifdef. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#180937: g++ internal compiler error: Error reporting routines re-entered
On Fri, Feb 14, 2003 at 12:14:01AM -0500, H. S. Teoh wrote:
> Package: g++
> Version: 3.2.2-0
> Severity: important
>
> The attached source file causes g++ to report an internal compiler error:
>
> % g++ -c g++bug.cc
> g++bug.cc: In function `int main(int, char**)':
> g++bug.cc:29: jump to case label
> g++bug.cc:26: crosses initialization of `someclass obj1'
> g++bug.cc:33: jump to case label
> g++bug.cc:30: crosses initialization of `someotherclass obj2'
> g++bug.cc:26: crosses initialization of `someclass obj1'
>
> Internal compiler error: Error reporting routines re-entered.
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://www.gnu.org/software/gcc/bugs.html> for instructions.
An ICE is always a bug, but...
> I'm not sure what is the cause of this; it seems to be something to do
> with the switch statement and the fact that someclass and someotherclass
> have destructors. (Commenting out the destructors in those classes makes
> the internal compiler error go away, somehow.)
>
> Also, why doesn't g++ like the declaration of objects inside a switch
> statement? Is this invalid according to the C++ spec, or is it a GCC
> oddity? Regardless, the internal compiler error is certainly a bug.
I'm pretty sure it's illegal. Consider this - what is the scope of
obj1 in the below? It starts at the first label, and goes until the
end of the case block. So it's in scope at CHOICE_B. But its
constructor wasn't called
> switch (choice) {
> case CHOICE_A:
> someclass obj1(&commonobj);
>
> break;
> case CHOICE_B:
> someotherclass obj2(&commonobj);
>
> break;
> default:
> break;
> }
> }
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#180837: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE on the autobuilders.
On Thu, Feb 13, 2003 at 10:21:56AM +0100, Sven Luther wrote: > Package: libstdc++5-dev > Version: 1:3.2.2-1 > > Hello, ... > > I am not really sure if this is a problem with this package or a problem > with the autobuilders, but in doubt, i fill a bug report. > > I have a package, lablgl, for which you can find the build log here : > > http://buildd.debian.org/fetch.php?&pkg=lablgl&ver=0.99-4&arch=powerpc&stamp=1045119454&file=log&as=raw > > or > > http://buildd.debian.org/build.php?pkg=lablgl > > This package is just a set of opengl and GLU bindings for the ocaml > language, and it fails to load on the autobuilders (all 10 of them) with : > > ocamlmktop -I . -I +labltk -o lablgltop \ > labltk.cma lablgl.cma togl.cma > Error on dynamically loaded library: ./dlllablgl.so: undefined symbol: > _ZTVN10__cxxabiv120__si_class_type_infoE > > It seems that _ZTVN10__cxxabiv120__si_class_type_infoE is a C++ symbol, > provided by libstdc++5-dev, and it is pulled in by xlibmesa-glu-dev, > which i build depend upon. > > Now the strange thing, and the one which has me completely bewildered is > that if i build on my home box, or if i build on voltaire (ppc box > running sid), then it works flawlessly. I guess it is a problem with the > autobuilders not being uptodate or something such, but i don't think it > is a problem with my build dependencies, since as said libstdc++5-dev is > pulled in by xlibmesa-glu-dev. This sounds like a bug in xlibmesa-glu-dev; that symbol comes from libsupc++, and if the C++ library is linked using g++ it'll be picked up correctly. Or are you using a .a archive of glu into the plugin? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Processed: reassign 179781 to glibc, severity of 179781 is serious, merging 179781 178645
On Mon, Feb 17, 2003 at 10:58:21PM +0900, GOTO Masanori wrote: > Hi Guido, > Thanks for your explanation. > > At Sun, 16 Feb 2003 23:32:42 +0100, > Guido Guenther wrote: > > I'm trying to explain how I understand these issues, but it might not be > > correct: > > > > On Mon, Feb 17, 2003 at 12:49:44AM +0900, GOTO Masanori wrote: > > > 1. Why is __fixunsdfdi appeared, on the contrary why is not __fixdfdi > > > appeared > > gcc does the double -> signed long long conversion inline but uses a > > function call for the unsigned conversion. > > Hmm, I feel it's strange feature... There are no need to distinguish > between signed and unsigned. Is it gcc bug? The inlining is just based on cost. One of those operations is cheaper than the other on 386 hardware. > > For example: > > /usr/bin/nm __udivdi3 > > /usr/bin/nm __umoddi3 > > /usr/bin/strip __ucmpdi2 > > /usr/bin/strip __udivdi3 > > I'm sorry, but I can't understand what you mean... You mean that a binary > has _udivdi3 or __umoddi3 and then drops its symbol with strip? No, strip was just an example. And it's been rebuilt on i386 since that measurement was made so you can't see it any more. But it goes like this: libbfd.so is built it contains __udivdi3 strip is linked to -lbfd it needs __udivdi3 it gets __udivdi3 from libbfd.so libbfd.so is recompiled by GCC 3.2 it no longer provides __udivdi3 Until strip is recompiled, strip doesn't run. > > > Well, dcgui (#179781) should be fixed with the latest glibc and gcc > > > environment. Moreover, if binaries on woody/sarge works well, then I > > > think we should not add this compat-patch even if sid binaries causes > > > such unresolved symbol bug. > > No. We only add symbols for the woody->sarge transition. > > So, is it debian specific patch? Uh, I don't think it should be. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: c/9762: Address of 'char' is incorrect.
On Thu, Feb 20, 2003 at 06:32:19PM -, Stephen Kennedy wrote:
>
> OK, the C standard does not say that this should work, so you
> can consider this bug closed.
>
> However, given knowledge of the calling convention of a
> particular machine, you can do neat things such as dynamic
> function binding. See www.drizzle.com/~scottb/gdc/fubi-paper.htm
> for instance.
>
> I've since changed to using assembly, but why does gcc
> return the address of a temp when 'a' is a char and not
> when 'a' is an int?
Because it's passed as an int; you have to convert it to a char on
arrival in the function.
>
> Surprised, not unhappy,
> Stephen.
>
> ---
> Stephen Kennedy <[EMAIL PROTECTED]>
> t: +353 1 6693679 f: +353 1 6767094
> Game Developer Frontline Award Winner
> http://www.havok.com/news/release.html
>
> > > In the example below, '&a' is the address of a local
> > copy of 'a' not of 'a'.
> > > if the type of 'a' is changed to int, it works as expected.
> >
> > Works as who expected? Where is the bug? Please quote which part of
> > the C standard is violated. You got an address, why are you unhappy?
> >
> > Neil.
> >
> > > #define TA char
> > > #define TB int
> > > #define TC int
> > >
> > > void foobar(TA a, TB b, TC c);
> > >
> > > int main()
> > > {
> > > foobar(1,2,3);
> > > return 0;
> > > }
> > >
> > > void foobar(TA a, TB b, TC c)
> > > {
> > > printf("a == %i claims %x\n", a, &a);
> > > printf("a == %i really %x\n", (&b)[-1], (&b)-1);
> > > printf("b == %i %x\n", b, &b);
> > > printf("c == %i %x\n", c, &c);
> > > }
> >
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#180486: gcc-3.2: miscompilation on powerpc with -O2 or higher
On Mon, Feb 24, 2003 at 10:14:03AM -0500, Camm Maguire wrote: > Greetings! > > Matthias Klose <[EMAIL PROTECTED]> writes: > > > Camm Maguire writes: > > > Package: gcc-3.2 > > > Version: 1:3.2.2-1 > > > Severity: normal > > > > > > When compiling GCL, the produced lisp image segfaults early on > > > iwhen using -O2 or higher. All is fine with -O, or with full > > > optimization using earlier gcc versions on this platform. > > > > - did GCL compile correctly with gcc-3.0 and/or gcc-2.95 using -O2? > > 2.95 yes, actually even with -O3 -fomit-frame-pointer > 3.0 don't know. > > > - does GCL compile correctly with gcc-snapshot using -O2? > > > > Don't know, but will try it if I get a chance. I used to be able to > try different compilers on Debian project machines relatively easily > by: Just ask [EMAIL PROTECTED] to install them. > dpkg --fsys-tarfile | tar xf - > export GCC_EXEC_PREFIX=$HOME/usr/lib/gcc-lib/ > export LD_LIBRARY_PATH=$HOME/lib:$HOME/usr/lib > export LIBRARY_PATH=$HOME/lib:$HOME/usr/lib > export C_INCLUDE_PATH=$HOME/usr/include > ln -s gcc-??? usr/bin/gcc > export PATH=$HOME/usr/bin:$PATH > > but this isn't working of late anymore, due to > > 1) dependencies on latest libc, which in turn depends on latest ld.so, >which I can't install as a user Sure you can, it's just a bit awkward to use. A couple of wrapper scripts a la #!/bin/sh exec $HOME/lib/ld.so --library-path $HOME/lib:$HOME/usr/lib \ $HOME/usr/bin/gcc $* > 2) oddities with stdlib.h installed with the above procedure. Some >defines are missing. It should work, but you'll have to be more specific about the problems. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#182795: gcc-3.2: mpqc build fails on MIPS with 'Branch out of range' error
On Fri, Feb 28, 2003 at 12:00:35AM +0100, Michael Banck wrote: > Package: gcc-3.2 > Version: 1:3.2.3-0pre2 > Severity: normal > > Hi, > > compiling mpqc on MIPS results in this error: > > /usr/bin/gcc-3.2 -DHAVE_CONFIG_H -D_REENTRANT -I../../../../../src/lib > -I/build/buildd/mpqc-2.1.3/include -I/build/buildd/mpqc-2.1.3/src/lib -O0 > -Wall -c /build/buildd/mpqc-2.1.3/src/lib/chemistry/qc/dft/lebedev.c > -o lebedev.o > /tmp/ccIsYgSV.s: Assembler messages: > /tmp/ccIsYgSV.s:361: Error: Branch out of range > /tmp/ccIsYgSV.s:366: Error: Branch out of range > [...] > /tmp/ccIsYgSV.s:19541: Error: Branch out of range > /tmp/ccIsYgSV.s:22425: Error: Branch out of range > make[6]: *** [lebedev.o] Error 1 > make[6]: Leaving directory > `/build/buildd/mpqc-2.1.3/build-static/src/lib/chemistry/qc/dft' > make[5]: *** [default] Error 1 > make[5]: Leaving directory > `/build/buildd/mpqc-2.1.3/build-static/src/lib/chemistry/qc' > make[4]: *** [default] Error 1 > make[4]: Leaving directory > `/build/buildd/mpqc-2.1.3/build-static/src/lib/chemistry' > make[3]: *** [default] Error 1 > make[3]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src/lib' > make[2]: *** [default] Error 1 > make[2]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src' > make[1]: *** [default] Error 1 > make[1]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static' > make: *** [build-static-stamp] Error 2 > > see http://buildd.debian.org/fetch.php?&pkg=mpqc&ver=2.1.3-2&arch=mipsel&; \ > stamp=104604&file=log&as=raw for the full buildd log. > > This error also occured on gcc-2.95, I did not file it earlier because I > was hoping that it might be gone in gcc-3.2. The first builds in early > 2002 were done with -O and then with -O0 afterwards. > > You can get the source file at > > http://people.debian.org/~mbanck/lebedev.c FYI, there should be a new binutils which avoids this issue "soon". It's a compiler bug, though - someone should try using gcc-snapshot. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: help with gcc-3.2 related bug
On Mon, Mar 03, 2003 at 01:28:57PM +0100, Martin v. Löwis wrote: > Fernando Sanchez <[EMAIL PROTECTED]> writes: > > > I have been suggested to ask for help here; please bounce me > > somewhere else if I am writing to the wrong address. I got a bug reported on > > libsablot0c102 package, which appeared on the migration to gcc-3.2. Do you > > recommend adding -lstdc++, or do you have a better advice? > > Fernando, > > The best approach is to use "g++" for linking. This should implicitly > add libstdc++, and correct a few other errors that your linker command > line may have caused. Well, presumably he is linking using gcc to avoid libstdc++; is there anything besides the missing library which g++ would change? Fernando, you may want to try adding -lsupc++ when building with GCC 3.2. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#184446: libstdc++5-dev has i486 specific asm code
On Wed, Mar 12, 2003 at 12:49:44PM +0100, Sebastian Wilhelmi wrote: > Package: libstdc++5-dev > Version: 1:3.2.3-0pre5 > Severity: normal > > The file /usr/include/c++/3.2/i386-linux/bits/atomicity.h > has code, which does not work on i386. It needs i486 or above. > > Is i386 unsupported by debian? > > Personally I haven't found any info regarding this on debian-devel or > in the debian policy, so is there any consensus in dropping i386? > > (Note, that I don't have i386 myself, so I hope I didn't get that wrong.) > > This bug would make nearly all C++-packages compiled with it unusable on i386. The comment in that file says: // Low-level functions for atomic operations: x86, x < 4 version -*- C++ -*- Is that incorrect? Hmm, it's the same as the 486 version, so the comment is wrong. This will be fixed in gcc 3.3 (at a performance penalty; we need to think about providing the i486 version also). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#184446: libstdc++5-dev has i486 specific asm code
On Sat, Mar 15, 2003 at 08:32:26PM +0100, Matthias Klose wrote: > Daniel Jacobowitz writes: > > On Wed, Mar 12, 2003 at 12:49:44PM +0100, Sebastian Wilhelmi wrote: > > > Package: libstdc++5-dev > > > Version: 1:3.2.3-0pre5 > > > Severity: normal > > > > > > The file /usr/include/c++/3.2/i386-linux/bits/atomicity.h > > > has code, which does not work on i386. It needs i486 or above. > > > > > > Is i386 unsupported by debian? > > > > > > Personally I haven't found any info regarding this on debian-devel or > > > in the debian policy, so is there any consensus in dropping i386? > > > > > > (Note, that I don't have i386 myself, so I hope I didn't get that wrong.) > > > > > > This bug would make nearly all C++-packages compiled with it unusable on > > > i386. > > > > The comment in that file says: > > > > // Low-level functions for atomic operations: x86, x < 4 version -*- C++ > > -*- > > > > Is that incorrect? Hmm, it's the same as the 486 version, so the > > comment is wrong. > > > > This will be fixed in gcc 3.3 (at a performance penalty; we need to > > think about providing the i486 version also). > > or we do think to drop i386 alltogether? How should this library be > installed? Building can be done in a second libstdc++-v3 build dir > with the compiler just built and -march=486 -mtune=585. It could just be built for i686 and put in /usr/lib/i686; see OpenSSL for an example. I don't know that it's worth the effort. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#184446: libstdc++5-dev has i486 specific asm code
On Sat, Mar 15, 2003 at 04:49:55PM -0500, Phil Edwards wrote: > On Sat, Mar 15, 2003 at 08:32:26PM +0100, Matthias Klose wrote: > > Daniel Jacobowitz writes: > > > On Wed, Mar 12, 2003 at 12:49:44PM +0100, Sebastian Wilhelmi wrote: > > > > > > > > The file /usr/include/c++/3.2/i386-linux/bits/atomicity.h > > > > has code, which does not work on i386. It needs i486 or above. > > > > > > The comment in that file says: > > > > > > // Low-level functions for atomic operations: x86, x < 4 version -*- C++ > > > -*- > > > > > > Is that incorrect? Hmm, it's the same as the 486 version, so the > > > comment is wrong. > > > > > > This will be fixed in gcc 3.3 (at a performance penalty; we need to > > > think about providing the i486 version also). > > > > or we do think to drop i386 alltogether? How should this library be > > installed? Building can be done in a second libstdc++-v3 build dir > > with the compiler just built and -march=486 -mtune=585. > > To expand on Daniel's comment: libstdc++ has "dropped" i386, in the > sense of, "i386 has been folded in with the "any random crappy chip with > no special abilities" target". > > Debian already hurts the x86 users (IMHO) by giving them a compiler > targetted for processor which, I'd bet, is used by less than 2% of the > user base. This is just one more performace hit on top of all the others; > I really wouldn't worry about it unless/until the compiler is targeted > to something more useful, e.g., i486, i586, or (quelle suprise) i686, > and for those cases the atomic operations will be automatically corrected. If it weren't for the disk/archivespace/maintenance/PITA cost I'd suggest binary-i686. Things being what they are, maybe we should poll for people interested in new versions of Debian on i386; I doubt we can drop 586, since I've seen uses of 'em recently... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: MT support in testing ?
On Mon, Mar 17, 2003 at 03:55:32PM +0100, Bo Lorentsen wrote: > Hi ... > > I have been spending some time, trying to make the g++ 3.2 work in a MT > environment, and it works out quite nicely, but ... I have some problems > while using strings (other things too I belive) on a SMP machine. > > Now this all ends up in the "i386-linux/bits/atomicity.h" file, that > "only" contain an single threaded version (read gcc 3.2 porting guide). > So my question then is this : are there anyone how have made a pthread > version ore anything like it for linux SMP, or will STL be forbidden > while using SMP for a while ? Huh? Is this your own installation of GCC 3.2? Our i386-linux/bits/atomicity.h contains the atomic operations, not a single-threaded version. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#185166: Bug#185163: __gmon_start__ causes problems for versioned symbols on hppa
On Mon, Mar 17, 2003 at 03:46:55PM +, Andrew Suffield wrote: > Package: libc6 > Version: 2.3.1-14 > Severity: normal > > In sysdeps/hppa/elf/initfini.c we have this: > /* If we use the standard C version, the linkage table pointer won't >be properly preserved due to the splitting up of function prologues >and epilogues. Therefore we write these in assembly to make sure >they do the right thing. > >Note that we cannot have a weak undefined __gmon_start__, because >that would require this to be PIC, and the linker is currently not >able to generate a proper procedure descriptor for _init. Sad but >true. Anyway, HPPA is one of those horrible architectures where >making the comparison and indirect call is quite expensive (see the >comment in sysdeps/generic/initfini.c). */ > ... > .text\n\ > .align 4\n\ > .weak __gmon_start__\n\ > .type__gmon_start__,@function\n\ > __gmon_start__:\n\ > .proc\n\ > .callinfo\n\ > .entry\n\ > bv,n %r0(%r2)\n\ > .exit\n\ > .procend\n\ > > In order to work around this bug, a dummy, weak symbol __gmon_start__ > has been introduced, which I can only presume would be overridden by > the real one when necessary. Unfortunately this means that all DSOs > will contain a weak definition of __gmon_start__. If we then have a > linker script that assigns a symbol version to all symbols, then this > symbol gets a version node attached to it - and everything breaks > horribly: > > /usr/bin/ld: libbaz.so.1: undefined versioned symbol name __gmon_start__@@BAR2 > (paer, 2003/03/17) > > Something needs to happen to prevent this. The most obvious approach > is to prevent the symbol from appearing externally at all - is it > still necessary? Failing that, the linker needs to know that it should > hide this symbol and/or not version it. > > [This makes it unnecessarily difficult to use versioned symbols (in > combination with a similar gcc bug on powerpc).] Actually, both this and your other bug are really linker bugs, I believe. See the binutils archive for last month, this thread: 89F 02/17 To [EMAIL PROTECTED] (0.8K) Versioned symbol linking bug 90C 02/17 Elias Athanasop (0.9K) |-> 91 r + 02/23 Elias Athanasop (1.4K) | `-> 92 N 02/25 Alan Modra (3.7K) `-> The patch in Alan's message needs to be tested. It was originally found on PPC building wxWindows. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: MT support in testing ?
On Mon, Mar 17, 2003 at 08:37:30PM +0100, Bo Lorentsen wrote: > On Mon, 2003-03-17 at 18:32, Daniel Jacobowitz wrote: > > > > Huh? Is this your own installation of GCC 3.2? Our > > i386-linux/bits/atomicity.h contains the atomic operations, not a > > single-threaded version. > No, it is not, it is the standard (testing) debian package. I'm not an > i386 asm expert but the inline assembler looks ok for single cpu MT > processing, but how about SMP. Does these instructions synchronize > between two (or more) CPUs ? > > I have this program, that works nicely as single thread, and multithread > while using one CPU, but I get funny random (memory related) errors > while running on a SMP machine. > > Am I looking in the wrong direction ? Those operations are atomic for any number of CPUs, so you're looking in the wrong place. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: gcc 3.2.2-0 - gcc --version contains "(" and breaks vmware modules build
On Thu, Mar 20, 2003 at 05:49:01PM +0100, Luca Andreucci wrote: > > this seems to be the lines from the Makefile which cause error > > COMPILER_VERSION := $(shell $(CC) --version) > IS_GCC_30 := $(shell if echo $(COMPILER_VERSION) | $(GREP) -q '^3\.0'; then > echo yes; else echo no; fi) > > I am in a GREAT hurry and can't provide further detail for now... sorry That's a bug in their makefiles then. Put quotes around $(COMPILER_VERSION). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#186139: gcc-3.2: [alpha] va_start is off by one
On Mon, Mar 24, 2003 at 10:14:38PM +0200, Kalle Olavi Niemitalo wrote: > Package: gcc-3.2 > Version: 1:3.2.3-0pre6 > Severity: normal > > In the attached program, failing_func should return its first > variadic argument, but somehow it returns wrong_value instead. > The main function exits with code 0 if the result is correct. > > I believe this is what causes Debian Bug#185973. > Coincidentally, I believe that Falk Hueffner fixed this in the GCC source very recently. Just FYI. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#186348: g++-3.2 -MM
On Wed, Mar 26, 2003 at 01:31:28PM +0100, Diether Knof wrote:
> Package: gcc-3.2
> Version: 3.2.1-0pre3
>
> When I use gcc-3.2 with the -MM option for the dependencies, I also get
> dependencies of the gtk libraries, which I include from the system. I think,
> gcc does not look at the include directories, included with '-I' ('gtk-config
> --cflags' outputs '-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
> -I/usr/lib/glib/include -I/usr/X11R6/include').
> With the version 3.0 and 2.95 everything works fine.
>From the documentation:
`-MM'
Like `-M' but do not mention header files that are found in system
header directories, nor header files that are included, directly
or indirectly, from such a header.
This implies that the choice of angle brackets or double quotes in
an `#include' directive does not in itself determine whether that
header will appear in `-MM' dependency output. This is a slight
change in semantics from GCC versions 3.0 and earlier.
If you change -I to -isystem, then the right thing should happen; not
sure about that though.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#186348: g++-3.2 -MM
On Wed, Mar 26, 2003 at 09:09:39PM +0100, Diether Knof wrote:
> On Wed, Mar 26, 2003 at 10:29:51AM -0500, Daniel Jacobowitz wrote:
> > On Wed, Mar 26, 2003 at 01:31:28PM +0100, Diether Knof wrote:
> > > Package: gcc-3.2
> > > Version: 3.2.1-0pre3
> > >
> > > When I use gcc-3.2 with the -MM option for the dependencies, I also get
> > > dependencies of the gtk libraries, which I include from the system. I
> > > think, gcc does not look at the include directories, included with '-I'
> > > ('gtk-config --cflags' outputs '-I/usr/include/gtk-1.2
> > > -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include').
> > > With the version 3.0 and 2.95 everything works fine.
> >
> > >From the documentation:
> > `-MM'
> > Like `-M' but do not mention header files that are found in system
> > header directories, nor header files that are included, directly
> > or indirectly, from such a header.
> >
> > This implies that the choice of angle brackets or double quotes in
> > an `#include' directive does not in itself determine whether that
> > header will appear in `-MM' dependency output. This is a slight
> > change in semantics from GCC versions 3.0 and earlier.
> Thanks, I just invoked 'man gcc' and got the documentation for gcc-2.95.
> Do you know, why this has changed? For me, it does not make sense.
Some projects use -I../local and . For them, the old
behavior didn't make sense.
Can't satisfy everyone if they won't give the compiler enough
information to decide.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Re: Problem with building OpenOffice.orgBeta on debian-unstable (PPC)
On Sun, Mar 30, 2003 at 06:24:18AM +0200, Jan-Hendrik Palic wrote: > Sorry for the crossposting. > Dear GCC-Maintainer, > > I attached a build.log and two enviroments-source-files for the build > from OpenOffice.org. As you can see in build.log, I have a problem with > the include. :( > I cannot say, if this is trivial a big problem, but I am fighting with > it some days ... and I have no solution for it. OpenOffice.org 1.0.2/3 > are building, but 1.1 does not. > > Do you have a hint, or one of the OpenOffice.org developers, what's > going wrong here? I don't know if this is the problem or not, but you should kill the -I/usr/include. Specifying that manually is almost always wrong. -- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University
Re: Bug#184446: marked as done (libstdc++5-dev has i486 specific asm code)
On Sun, Apr 13, 2003 at 02:03:03AM -0500, Debian Bug Tracking System wrote: >* On i386, build libstdc++ optimized for i486 and above. The library > in /usr/lib is built for i386. Closes: #184446, #185662. Does it really? The i486-specific code was in a _header_, not in the library. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: http://www.trl.ibm.com/projects/security/ssp/
On Thu, Apr 10, 2003 at 09:21:25PM +0200, Marc-Christian Petersen wrote: > Hi Debian GCC maintainers :-) > > I have a wish for upcoming gcc versions for SID. Is it possible to add > propolice (see $Subject) to new gcc releases? Not to the main GCC package, no. It's too intrusive. Someone may wish to package it separately. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: TLS. nptl and gcc/glibc/binutils
On Mon, Apr 21, 2003 at 05:51:37AM -0700, Jeff Bailey wrote: > On Mon, Apr 21, 2003 at 02:18:01PM +0900, GOTO Masanori wrote: > > > > My thought is that gcc-3.3 will be out soon enough for us to use that. > > > But for future coming stable gcc-3.3, we should start to support tls > > and nptl, and I already start to investigate. I think we should have > > two libc6: libc6-linuxthreads (linuxthreads) and libc6-nptl (nptl). > > This means that now the name libc6 becomes virtual package or > > something. > > I haven't investigated - does the core glibc library actually change > based on each add on? It would be nice to have just the pthreads change > for two reasons: I think the library changes. But we don't want to move away from a real libc6 package IMO. Anyone who wants the NPTL support installed can live with having the LinuxThreads support installed also. That's how Red Hat does it too, IIRC. [It's essentially a hwcap thing] > Less to switch from one to the other, and it would be interesting to be > able to use apt-cache to show which packages used pthreads. > > > > The biggest problem is that Debian's kernels don't have futex > > > support. I've heard that RedHat has some solution for automatically > > > detecting which they should use, but I don't know anything about it. > > > I hope someone intent to package redhat9's 2.4 Ingo's backport patch. > > BTW, I use the latest kernel on my some machines, so it's not problem > > for me. > > I keep wondering why it's not been accepted upstream. I don't follow > Linux kernel development anymore, so I don't know the story. Because 2.4 is a maintenance line, and the patch is gigantic. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#190757: please add a warning for conversion from "int" to "unsigned int"
On Fri, Apr 25, 2003 at 05:41:20PM +0200, Robert Millan wrote:
> Package: gcc-3.2
> Version: 1:3.2.3-0pre9
> Severity: wishlist
>
> the following code (compiled with -Wall -pedantic) could be
> considered "buggy", because it implicitly converts a
> signed int to unsigned int when calling "a". if you run it,
> it will print the number 2^32-1 instead of -1.
>
> #include
> int a (unsigned int b)
> {
> return printf ("%u\n", b);
> }
> int main ()
> {
> return a (-1);
> }
>
> this can lead to programming bugs. to prevent a programmer from
> such, i'd appreciate if gcc said something like:
>
> warning: implicit conversion from signed to unsigned
>
> when asked to compile this code.
>
> maybe it makes sense to warn about conversion from unsigned to
> signed too, although having problems with this is unlikely,
> since bit overflow only happens with really big numbers.
Is this roughly what you want:
[EMAIL PROTECTED]:~% gcc-3.2 -Wall -Wconversion -c c.c
c.c: In function `main':
c.c:8: warning: passing arg 1 of `a' as unsigned due to prototype
c.c:8: warning: negative integer implicitly converted to unsigned type
?
It's not part of -Wall because it's too noisy.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#190757: please add a warning for conversion from "int" to "unsigned int"
On Fri, Apr 25, 2003 at 08:40:11PM +0200, Robert Millan wrote: > On Fri, Apr 25, 2003 at 02:18:18PM -0400, Daniel Jacobowitz wrote: > > > > Is this roughly what you want: > > [EMAIL PROTECTED]:~% gcc-3.2 -Wall -Wconversion -c c.c > > c.c: In function `main': > > c.c:8: warning: passing arg 1 of `a' as unsigned due to prototype > > c.c:8: warning: negative integer implicitly converted to unsigned type > > yes > > > It's not part of -Wall because it's too noisy. > > that disconcerts me, I thought -Wall would include all warnings. would > you consider including it? it may be noisy but can be easily fixed > with a cast, and the benefit is being safe from a quite common bug. No, the decision was made after looking at the false positive rate. I recommend you read the manual if you want to know what GCC warnings do. It's not quite as clear as it could be, but -Wall is in the middle of the page, and says "all warnings above here". -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#478734: g++-4.2: refuses to compile valid C++ syntax
severity 478734 normal thanks On Wed, Apr 30, 2008 at 11:55:19AM -0500, Jason Kraftcheck wrote: > Severity: grave This is not grave, g++ is perfectly usable for other code. > I emmits the following error message: > > bug.cc: In function 'int main()': > bug.cc:6: error: no matching function for call to 'std::vector std::allocator >::swap(std::vector >)' > /usr/include/c++/4.2/bits/stl_vector.h:728: note: candidates are: void > std::vector<_Tp, _Alloc>::swap(std::vector<_Tp, _Alloc>&) [with _Tp = > int, _Alloc = std::allocator] I'm pretty sure GCC is correct to refuse this. The result of a cast is an rvalue, so you can not take a reference to it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#478734: g++-4.2: refuses to compile valid C++ syntax
On Wed, Apr 30, 2008 at 05:51:32PM -0500, Jason Kraftcheck wrote: > Why can't I take a reference to an rvalue? Because you can't modify rvalues. This is the definition of the C++ language. The next major revision of C++ will have T &&rref, the two ampersands declaring an rvalue reference instead of the normal lvalue kind. > the error message doesn't indicate that g++ interpreted the argument as > const. Const is not the same as lvalue/rvalue. It says you tried to pass a std::vector where a std::vector & was required and the fact that that was an error suggests that taking a reference is not possible here. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#478734: g++-4.2: refuses to compile valid C++ syntax
On Thu, May 01, 2008 at 10:39:24AM -0500, Jason Kraftcheck wrote: > Daniel Jacobowitz wrote: >> On Wed, Apr 30, 2008 at 05:51:32PM -0500, Jason Kraftcheck wrote: >>> Why can't I take a reference to an rvalue? >> >> Because you can't modify rvalues. This is the definition of the C++ >> language. The next major revision of C++ will have T &&rref, the two >> ampersands declaring an rvalue reference instead of the normal lvalue >> kind. > > Are you certain that the temporary created by invoking the copy > constructor is an rvalue? If so, then why does the following syntax work? > > std::vector v; > std::vector w( std:vector(v) ); > > The copy constructor also takes a reference. The only difference between > constructing 'w' and calling 'swap' on it is that the former takes a const > reference. You are permitted to bind rvalues to const references, even when it requires creation of a temporary. This is 8.5.3 [dcl.init.ref] in the C++ standard. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#524424: closed by Daniel Jacobowitz (Re: Bug#524424: gdb: asin produces wrong values)
reopen 524424 reassign 524424 gcc-4.3 thanks On Thu, Apr 16, 2009 at 08:41:05PM -0700, Jacob Mandelson wrote: > Should I file this against gcc or libc then? > In concert, this behavior is clearly erroneous. I'll reassign this to GCC - I think that at least the option to output the declarations would be useful. The libc behavior is an implementation detail. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: failed gcc-4.0.3-1(Debian) bootstrap with ARM VFP and binutils-2.16.1cvs20060117-1
On Fri, Mar 24, 2006 at 12:01:26PM +0100, [EMAIL PROTECTED] wrote: > "ld: *_s.o uses VFP instructions, whereas ./libgcc_s.so.1.tmp does not" > > (Complete log in attachment). > > I found this message quite strange, as libgcc_s.so.1.tmp was the > output of the linker, so it should have been created with the same > modes as the objects it should contain. It means that some earlier file in the link set the mode of libgcc_s.so.1, and that file did not use VFP. You might want to check the other files included in the linker invocation. > Moreover, --msoft-float and --mfpu=vfp were explicitly passed to > xgcc. However, looking at the log I see that collect2 does not get > --msoft-float and --mfpu options. Could this be a problem? I tried > to modify build/gcc/specs, to no avail... No, this is not an issue. > Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --with-gxx-include-dir=/usr/arm-vfp-linux-gnu/include/c++/4.0.3 > --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu > --enable-libstdcxx-debug --with-float=soft --with-fpu=vfp > --enable-checking=release --program-prefix=arm-vfp-linux-gnu- > --includedir=/usr/arm-vfp-linux-gnu/include --build=i486-linux-gnu > --host=i486-linux-gnu --target=arm-vfp-linux-gnu > /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/collect2 --eh-frame-hdr -shared > -dynamic-linker /lib/ld-linux.so.2 -X -m armelf_linux -p -o > ./libgcc_s.so.1.tmp /usr/arm-vfp-linux-gnu/lib/crti.o > /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtbeginS.o > -L/usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc -L/usr/arm-vfp-linux-gnu/bin > -L/usr/arm-vfp-linux-gnu/lib -L/usr/lib/gcc/../../arm-vfp-linux-gnu/lib > --soname=libgcc_s.so.1 --version-script=libgcc/./libgcc.map -O1 > libgcc/./_udivsi3_s.o libgcc/./_divsi3_s.o libgcc/./_umodsi3_s.o > libgcc/./_modsi3_s.o libgcc/./_dvmd_lnx_s.o libgcc/./_muldi3_s.o > libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o > libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o > libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_fixunsdfsi_s.o > libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixdfdi_s.o > libgcc/./_fixunssfdi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixxfdi_s.o > libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixunsxfsi_s.o > libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o > libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o > libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o > libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o > libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o > libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o > libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o > libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o > libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o > libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o > libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o > libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o > libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o > libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o > libgcc/./_divtc3_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o > libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o > libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o > libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o > libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc > /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtendS.o > /usr/arm-vfp-linux-gnu/lib/crtn.o > /usr/arm-vfp-linux-gnu/bin/ld: ERROR: > /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtbeginS.o uses VFP instructions, > whereas ./libgcc_s.so.1.tmp does not Looks like you're using an installed crti.o. I bet that's not built with VFP. You might want to look into e.g. crosstool; it knows how to bootstrap a toolchain with particular options. -- Daniel Jacobowitz CodeSourcery
Re: avahi FTBS on mips due to pthread ``weirdness?''
On Wed, Mar 22, 2006 at 04:41:34AM +, Martin Michlmayr wrote: > * Daniel Jacobowitz <[EMAIL PROTECTED]> [2006-01-24 10:10]: > > > > There are various ways to work around this problem, but i would > > > > like to know what the real cause is there? Is avahi using the > > > > -pthreads flag wrong or is gcc not hanlding it the right way on > > > > mips ? > > > > > > Please see #346346. mips requires -lpthreads > > > > Despite the discussion in that bug, -pthread is supposed to work and > > should be fixed. > > Are you working on this, Dan? No, sorry. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390042: gcc-4.1: latest gcc generates DW_CFA_set_loc
Package: gcc-4.1 Version: 4.1.1-14 Severity: normal The latest SVN update pulled in this patch: 2006-09-10 Roger Sayle <[EMAIL PROTECTED]> Nicolas Setton <[EMAIL PROTECTED]> Backport from mainline * dwarf2out.c (convert_cfa_to_fb_loc_list): Handle DW_CFA_set_loc. Which is wrong. The change wasn't entirely backed out, but at least it was mitigated: 2006-09-24 Roger Sayle <[EMAIL PROTECTED]> PR debug/29132 Backport from mainline * dwarf2out.c (dwarf2out_begin_prologue): Initialise the current label, dw_fde_current_label, to be the start of the function, i.e. the same value as dw_fde_begin. I don't know if the toolchain is frozen, but if possible we should include this patch. It fixes a serious exception handling regression on MIPS (related to a linker bug), and it causes some annoying trouble in GDB (due to a GDB bug). I don't have a patch for the GDB bug yet and the linker fix will be fairly intrusive. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc4 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages gcc-4.1 depends on: ii binutils 2.17-2 The GNU assembler, linker and bina ii cpp-4.1 4.1.1-14The GNU C preprocessor ii gcc-4.1-base 4.1.1-14The GNU Compiler Collection (base ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-14 GCC support library ii libssp0 4.1.1-14GCC stack smashing protection libr Versions of packages gcc-4.1 recommends: ii libc6-dev2.3.6.ds1-4 GNU C Library: Development Librari ii libmudflap0-dev 4.1.1-14GCC mudflap support libraries (dev -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Friends cannot be protected or private
On Mon, Sep 26, 2005 at 11:18:56AM -0500, Adam Majer wrote: > Hi all, > > I'm not on the list so please cc me any replies. > > I've noticed that friends cannot be protected or private anymore with > g++-3.4 and g++-4.0. Is this the correct behaviour? Why? Yes, this is a correctness fix. I'm afraid I don't know enough about C++ to explain why, but you can find a number of explanations in the gcc list archives. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Friends cannot be protected or private
On Wed, Sep 28, 2005 at 11:58:15AM -0500, Adam Majer wrote: > I found one > http://gcc.gnu.org/ml/gcc/2005-01/msg01760.html > > and a link from there to, > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#209 > > I don't understand the reasons for using access control in the friend > statements except that it probably makes access control easier to write > and apply in the compiler (ie. less exceptions) The reason (from GCC's POV) is to be compliant with the standard. The reasoning for leaving it that way in the standard is, I think, pretty well explained at the bottom of the Rationale in the WG notes. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
On Fri, Oct 07, 2005 at 05:16:28AM -0400, Nathanael Nerode wrote: > I begin to get the picture. > > Apparently the MIPS ABI is just plain broken. It contains some sort of > impassable hard limit on relocation table size, breaking random packages at > random times with no possible fix. Nobody can fix this without changing > the ABI. > > Lovely. Good grief, I would not want to support this architecture under > those circumstances, but as long as it doesn't interfere with supporting > other architectures, if you think you can do it, that's fine. You don't get the picture. In fact the above is completely wrong. I recall explaining this to you yesterday. It's a lot of work to fix and no one has done it. That's not the same thing at all. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
On Fri, Oct 07, 2005 at 05:39:26PM +0200, Thiemo Seufer wrote: > We have for MIPS: > > - The plain GOT mode, where a GOT has a maximum size of 2^16 byte, > with 16k symbols. > > - The XGOT mode, with unlimited (2^32 byte) size, which increases > code size by 15-20%, and reduces perfomance accordingly. > > - MultiGOT, which creates several GOTs in a single binary for the > final link, but uses only one GOT for imports/exports. The object > files still have only plain GOT. > > MultiGOT is supposed to be the current best solution, and XGOT is > supposed to be obsoleted by it. Normally plain GOT is used, and the > linker switches to MultiGOT in the final link if the GOT grows too > big. Yes. > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > hit. A executable/library with larger exported GOT will build > without warning but will cause ld.so to segfault. This is the main > bug, and hard to debug (a statically built gdb may help here). > This hits currently (at least) the gcj shared library runtime, > the ghc executable, and libgklayout.so in mozilla*. A workaround > involving XGOT is possible in some cases, and was done for the > mozillae (and some others, grepping for -xgot in build logs seems > to be the most reliable way to find them all). Dynamically linked > executables/shared libraries with any of the different internal GOT > models are freely mixable. If you'll give me an explicit testcase, I will volunteer to debug this for you; I have lots of practice debugging ld.so. Is this really the main bug at this point? I.E. multigot binaries not working rather than not linking? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
On Sat, Oct 08, 2005 at 09:11:05PM +0200, Thiemo Seufer wrote: > Daniel Jacobowitz wrote: > [snip] > > > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > > > hit. A executable/library with larger exported GOT will build > > > without warning but will cause ld.so to segfault. This is the main > > > bug, and hard to debug (a statically built gdb may help here). > > > This hits currently (at least) the gcj shared library runtime, > > > the ghc executable, and libgklayout.so in mozilla*. A workaround > > > involving XGOT is possible in some cases, and was done for the > > > mozillae (and some others, grepping for -xgot in build logs seems > > > to be the most reliable way to find them all). Dynamically linked > > > executables/shared libraries with any of the different internal GOT > > > models are freely mixable. > > > > If you'll give me an explicit testcase, I will volunteer to debug this > > for you; I have lots of practice debugging ld.so. > > Unfortunately the "testcase" is mozilla's libgklayout.so, Which isn't > exactly handy. I'll try to come up with something better the next days. It'll do if you can tell me exactly how to reproduce the problem; I never volunteered to look at this before because I didn't have a Debian/MIPS setup, but now I do. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
On Sat, Oct 08, 2005 at 03:18:23PM -0400, Nathanael Nerode wrote: > What I keep hearing is that no one has reported the bug(s), and nobody except > Thiemo Seufer has even described it/them adequately. This is a bug or bugs > which is not documented in the documentation or bug databases for glibc, > binutils, gcc, Debian, or anywhere else. It's apparently a substantial and > reproducible bug which hits any library or executable with really large > numbers of exported symbols. The GCC documentation suggests a fix (xgot) > which doesn't actually work. No, Nathanael, this is not what you keep _hearing_. It's what you keep _saying_. I'm aware that you seem to spend a lot of time listening to yourself and I've gotten quite tired of hearing you repeat yourself. It doesn't have a clear entry in any bugzilla because there's a lot of confusion over various bits of (A) whether particular things are bugs, or (B) whose bugs they are. But the people who have encountered it, which is not limited strictly to Thiemo obviously, are familiar with the problem. > Now, I understand this sort of stuff not being dealt with for a while. But > the nature of the problem has supposedly been known for a year or more, and > so a little documentation of "known limitations" is really the least I'd > expect. It's free software. You're welcome to figure out the problem, preferably with less insulting the reviewers, and submit a patch to the documentation. > m68k is known to be in a situation where serious toolchain bugs are not > reported upstream. I thought previously that it was the only such > architecture. I'm pretty sure this has been reported upstream. It's not in the bug tracking system upstream. That's not the same thing. Who do you think would fix it? Hint, probably me or Thiemo. No one else has been interested in working on this stuff in the past. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333952: Cross-compilers should not use biarch
On Fri, Oct 14, 2005 at 09:06:19AM -0700, Josh Triplett wrote: > Currently, for platforms which natively build a biarch GCC, such as > powerpc, the GCC package also attempts to build a biarch cross-compiler > when targetting that platform. This would require the installation of > cross-compilation libraries for two different cross-architectures, > rather than just one, in order to build and use GCC; otherwise, the > build fails when attempting to find a libc for the alternate target. In > addition, dpkg-cross doesn't appear to support converting and installing > library packages for the alternate architectures. It also seems far > more likely that when setting up a cross-compilation environment, one > would simply construct two cross-compilers, one for each of the two > architectures, rather than one two-target compiler. My experience suggests that having a biarch cross compiler is, in fact, often desirable. dpkg-cross shouldn't need to "convert" library packages. The same packages that would be used on a native build are used; they'll be Architecture: i386, even if they contain amd64 binaries, et cetera for other platforms. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333952: Cross-compilers should not use biarch
On Sat, Oct 15, 2005 at 07:35:39PM -0700, Josh Triplett wrote: > (such as powerpc64), because the contents are in lib64 directories and > the include files are in alternate locations as well. The include files nowadays are in /usr/include/, so no. It would only need to know about /lib64. > Furthermore, it is not clear how it should convert these packages. If > the architecture string were to be believed, it should stick the files > in the same arch directory under /usr as the standard libraries for that > architecture; however, the architecture string is in fact misleading, > and the files should be put in the directory under /usr corresponding to > the alternate architecture. Why? A good motto for cross compilers is that they should be as much as possible like the corresponding native compilers. The native compiler knows /usr/lib and /usr/lib64; the cross compiler should know /usr/i486-linux-gnu/lib and /usr/i486-linux-gnu/lib64. Or just update to the current year, and use /usr/lib and /usr/lib64, and --with-sysroot, in which case just about everything becomes easier. > In the ideal case, with long-term work on dpkg and dpkg-cross to support > multiple architectures, it might be possible to just make use of the > binary packages for the alternate architecture, rather than needing > hacks like "libc6-dev-powerpc64" and "libc6-dev-amd64". It might also > be possible to hack dpkg-cross to deal with such hacks in the meantime. dpkg-cross should presumably not diverge from what dpkg does, and today dpkg uses libc6-dev-amd64. > However, at the moment, this patch makes it possible to build at least a > plain cross-compiler for such architectures. I think it's worth doing it correctly. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333952: Cross-compilers should not use biarch
On Sat, Oct 15, 2005 at 08:32:03PM -0700, Josh Triplett wrote:
> Just out of curiosity, is it possible to provide multiple sysroots, such
> that the resulting gcc looks in (for example) /usr/${ARCH1}-linux-gnu
> for -march=(something in the $ARCH1 family) and /usr/${ARCH2}-linux-gnu
> for -march=(something in the $ARCH2 family) ?
You need a fairly recent GCC patch for this. And some specs magic if
you wanted to key it off of -march.
> >>However, at the moment, this patch makes it possible to build at least a
> >>plain cross-compiler for such architectures.
> >
> > I think it's worth doing it correctly.
>
> I agree. However, I also think it's worth having something that works
> in the meantime; at the moment, it is not possible to use dpkg-cross and
> the cross-compiler support in the current GCC source package to build a
> Debian-packaged cross-compiler for any architecture currently using
> biarch support. This patch does fix that problem; I'd certainly love to
> see a better fix which makes use of --with-sysroot as you suggest.
That's why I didn't suggest it originally. It still sounds to me like
there's just a few, simple, unpacking-related limitations in dpkg-cross
preventing you from using the compilers as-is.
Anyway, it's up to Matthias. I don't do any work on Debian's gcc
packaging so I don't get to bitch.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
