Re: gcc-3.3 package upload

2003-03-20 Thread Anthony Towns
On Wed, Mar 19, 2003 at 10:01:07AM +0100, Matthias Klose wrote:
> [CC ing the other GCC people as well, not debian-gcc, as this started
>  with private mails. Feel free to move it's over there]

Moved to -gcc. Happy fun multi-posting!

> Randolph Chung writes:
> > tbh hppa would benefit from going to
> > 3.3 too because of much better c++ support, but i thought we were
> > trying to move away from each-arch-have-a-different-default-gcc-version
> > situation that we had in woody.
> I don't see anything wrong with this. We have architectures, where
> this move was too early.

Having different gcc versions should definitely be the exception, not the
rule. If we've got problems on some architectures, we should be looking
to make sure they're fixed upstream in the latest stable release, and
we should be shipping the latest stable release.

> > In any case, the concern is that let's say we want to ship sarge in
> > a month (please don't laugh :-), then we will have half of the archive
> > built using 3.2 and half using 3.3. Even if they are 100% compatible, it
> > would mean everyone has dependencies on two compilers installed on 
> > their system. yuck.
> IMO 3.3 should be a release goal for sarge, like glibc-2.3 is/was.

We should be shipping the latest stable upstream release, wherever
possible, and making sure that any problems that appear in our use are
fixed in Debian and upstream.

> > > I am not aware of any problem.
> > the problems are more from a distribution/release management point of
> > view. , if aj is ok with this then i will just shut up.
> It seems we have a communication problem with our release
> management. Doesn't aj get our mails or read debian-gcc? 

I'm not remotely up on how the toolchain works, and I don't like to
randomly talk about things that're above my head.

There are two issues: making sure you get the latest version tested and
working (by getting new versions of gcc tested on multiple architectures
and seeing if it builds all our packages on each arch and so on), and
making sure you don't block everyone else's development and testing
(by having a buggy gcc in unstable) in the mean time.

I presume those've been mostly addressed by gcc-snapshot already.

> The move of 3.2 to testing despite rc reports for m68k even without a
> note comes to mind. 

gcc-3.2 was updated in testing, and gcc-3.3 was added to testing because
they were the major hold up at the time, and I heard secondhand that
you were about to start making things depend on gcc-3.3 on multiple
architectures any day now. Doing that sort of thing usually results
in a similar hold up to what's happened with glibc these past months,
and with the increased dependence on libgcc1, the gcc packages have a
similar effect. Having a broken compiler in testing doesn't do a lot
to effect an architecture: everything's built from unstable, so if the
toolchain there is unreliable, the architecture's unreliable.

> Release management happens behind the scenes,
> which I'm not happy with.

So does gcc management, big deal.

If you don't see why this is, you're invited to comment on -devel
about the plans for the 3.2 v 3.3 ABI issues, and enjoy the wonders
of transparency.

> PS: aj, IMO release managers are dictators, but it is said that some
> of them are benevolent :)

Yes, and it's often said that everyone's a critic too. Lay off.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgpBQ8kQO1uko.pgp
Description: PGP signature


[linux-mips]: ICE while building libstdc++

2003-03-20 Thread agx
>Category:   bootstrap
>Synopsis:   [linux-mips]: ICE while building libstdc++
>Confidential:   no
>Severity:   serious
>Priority:   medium
>Class:  ice-on-legal-code
>Submitter-Id:   net
>Originator: [EMAIL PROTECTED]
>Release:gcc-ss-20030317
>Environment:
linux-mips SGI IP22 (debian unstable)
currently installed gcc is:
Reading specs from 
/usr/local/bin/../lib/gcc-lib/mips-unknown-linux-gnu/3.3/specs
Configured with: ../gcc-cvs/configure --prefix=/usr/local/stow/gcc-cvs-head 
--program-suffix=-cvs --enable-languages=c,c++ : (reconfigured) 
../gcc-cvs/configure --prefix=/usr/local/stow/gcc-cvs-head 
--program-suffix=-cvs --enable-languages=c,c++
Thread model: posix
gcc version 3.3 20030310 (prerelease)
>Description:
when doing a native bootstrap 'make bootstrap' dies with a segmentation fault:

/import/gcc/gcc-cvs-build/gcc/xgcc -shared-libgcc 
-B/import/gcc/gcc-cvs-build/gcc/ -nostdinc++ 
-L/import/gcc/gcc-cvs-build/mips-unknown-linux-gnu/libstdc++-v3/src 
-L/import/gcc/gcc-cvs-build/mips-unknown-linux-gnu/libstdc++-v3/src/.libs 
-B/usr/local/stow/gcc-cvs-head/mips-unknown-linux-gnu/bin/ 
-B/usr/local/stow/gcc-cvs-head/mips-unknown-linux-gnu/lib/ -isystem 
/usr/local/stow/gcc-cvs-head/mips-unknown-linux-gnu/include 
-I../../../../gcc-cvs/libstdc++-v3/../gcc 
-I../../../../gcc-cvs/libstdc++-v3/../include 
-I/import/gcc/gcc-cvs-build/mips-unknown-linux-gnu/libstdc++-v3/include/mips-unknown-linux-gnu
 -I/import/gcc/gcc-cvs-build/mips-unknown-linux-gnu/libstdc++-v3/include 
-I../../../../gcc-cvs/libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE 
-fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c 
../../../../gcc-cvs/libstdc++-v3/libsupc++/eh_alloc.cc  -fPIC -DPIC -o 
eh_alloc.o
In file included from ../../../../gcc-cvs/libstdc++-v3/libsupc++/eh_alloc.cc:33:
/import/gcc/gcc-cvs-build/mips-unknown-linux-gnu/libstdc++-v3/include/cstdlib: 
In
   function `lldiv_t __gnu_cxx::div(long long int, long long int)':
/import/gcc/gcc-cvs-build/mips-unknown-linux-gnu/libstdc++-v3/include/cstdlib:149:
 internal compiler error: Segmentation
   fault
>How-To-Repeat:
CC=gcc-cvs ../gcc-cvs/configure \
--program-suffix=-cvs   \
--enable-shared \
--enable-threads\
--enable-languages='c,c++,f77'

make bootstrap
>Fix:

>Unformatted:




Bug#185604: g++-3.2: method parametrized by template does not work everywhere

2003-03-20 Thread Thimo Neubauer
Package: g++-3.2
Version: 1:3.2.3-0pre5
Severity: important

The following program is valid C++, but does not compile:

-- snip --

class X {
public:
  template
  int bar () {return d;}
};

template
int fooo ()
{
  return x;
}

template
void bar (T& g)
{
  int kk = fooo<17>();  // OK
  X x;
  int k = x.bar<17>();  // Not OK
}

int main ()
{
  X x;
  int k=x.bar<17>();// OK
  int n;
  bar(n);
}

-- snip --

aylee /tmp> g++ error.cc 
error.cc: In function `void bar(T&) [with T = int]':
error.cc:26:   instantiated from here
error.cc:18: no matching function for call to `X::bar()'
Exit 1
aylee /tmp> g++ --version
g++ (GCC) 3.2.3 20030309 (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.

Depending on whether the method-call is made in main() or inside a
template-function it works or not... The Intel Compiler compiles the
source.

   Thimo


-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux aylee 2.4.19 #2 Fre Nov 8 22:29:43 CET 2002 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Versions of packages g++-3.2 depends on:
ii  gcc-3.21:3.2.3-0pre5 The GNU C compiler
ii  gcc-3.2-base   1:3.2.3-0pre5 The GNU Compiler Collection (base 
ii  libc6  2.3.1-14  GNU C Library: Shared libraries an
ii  libstdc++5-dev 1:3.2.3-0pre5 The GNU Standard C++ Library v3 (d





gcc 3.2.2-0 - gcc --version contains "(" and breaks vmware modules build

2003-03-20 Thread Luca Andreucci

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

-- 
o---+__
   Luca Andreucci   |  ___   ___/ /__ ___ ___  ___ _
<[EMAIL PROTECTED]> | / _ `/ _ \/ _  / __/ -_) |/|/ // _ \/ __/ _ `/
 Chief Exec Hacker  | \_,_/_//_/\_,_/_/  \__/|__,__(_)___/_/  \_, /
o---+- http://andrew.org/andrew/gpg  /___/




Re: MT support in testing ?

2003-03-20 Thread Daniel Jacobowitz
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: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

2003-03-20 Thread Joel Soete

Hi Randolph,

>>
>>> I am looking to rebuild gcc-3.3 64bits to rebuild the last kernel 2.4
>to
>>> conitnue my investigation about smp(64bits) [which failled to boot on
>a
>>N4000
>>> when compile d with gcc-3.2 get from unofficial-debs].
>>
>>If you are working on 64-bit, I would advise staying with 3.0.4 for
>>now no one has tested 3.3 hppa64-linux-gcc at all, so it will just
>>be introducing more unknowns into the problem.
>>
>Ok I am gonna try to rebuild it with gcc-3.0.
>
Well just a small follow up to say that I had not much success with gcc-3.0
(64bits).

Also I did some other test:
this same kernel (smp64) boots well on a b2k (pa8600 up),
it boots also well on the N4000 when I 'disable' the second cpu?

(It seems to fail before 'Add swap...' but not sure because I notice that
all boot blabla is not output to the console [ie compare to dmesg nothing
is print out before 'sym53c8xx: at PCI...']?)

I will so try to ack dump_analyser to see how may I got analyse of the piminfo
which I grab from the two processor.

See you,
Joel


-
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be





Re: MT support in testing ?

2003-03-20 Thread Bo Lorentsen
On Thu, 2003-03-20 at 19:17, Daniel Jacobowitz wrote:

> Those operations are atomic for any number of CPUs, so you're looking
> in the wrong place.
Ok, I take Your word for it :-), and I will try to look around ones
again to see if I can locate the problem somewhere else. And I will then
try to exclude libstdc++, and as a possible SMP problem.  

Thanks for your help, anyway.

/BL 




Bug#185662: libstdc++5: Illegal instruction on 386 CPUs

2003-03-20 Thread Jochen Friedrich
Package: libstdc++5
Version: 1:3.2.3-0pre6
Severity: important

Using libstdc++5 on a 386 CPU may cause Illegal instruction (SIGILL).

Starting program: /usr/bin/python2.2 
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16384 (LWP 297)]
0x400d1b7f in std::locale::_Impl::_M_install_facet(std::locale::id const*, 
std::locale::facet*) () from /usr/lib/libstdc++.so.5

0x400d1b7f <_ZNSt6locale5_Impl16_M_install_facetEPKNS_2idEPNS_5facetE+51>: lock 
xadd %eax,(%edx)

# cat /proc/cpuinfo 
processor   : 0
vendor_id   : unknown
cpu family  : 3
model   : 0
model name  : 386
stepping: unknown
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : no
cpuid level : -1
wp  : no
flags   :
bogomips: 7.93

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux prommer 2.4.20-386 #1 Mon Jan 13 20:53:07 EST 2003 i386
Locale: LANG=C, LC_CTYPE=C

Versions of packages libstdc++5 depends on:
ii  gcc-3.2-base   1:3.2.3-0pre6 The GNU Compiler Collection (base 
ii  libc6  2.3.1-15  GNU C Library: Shared libraries an
ii  libgcc11:3.2.3-0pre6 GCC support library

-- no debconf information





Results for 3.2.3 20030316 (Debian prerelease) testsuite on sparc-unknown-linux-gnu

2003-03-20 Thread Matthias Klose
LAST_UPDATED: Sun Mar 16 10:12:05 UTC 2003

Native configuration is sparc-unknown-linux-gnu

=== g++ tests ===


Running target unix
FAIL: g++.law/profile1.C  Execution test
XPASS: g++.other/init5.C  Execution test

=== g++ Summary ===

# of expected passes7346
# of unexpected failures1
# of unexpected successes   1
# of expected failures  88
# of untested testcases 22
# of unsupported tests  5
/build/buildd/gcc-3.2-3.2.3ds5/build/gcc/testsuite/../g++ version 3.2.3 
20030316 (Debian prerelease)

=== g77 tests ===


Running target unix

=== g77 Summary ===

# of expected passes1458
# of unsupported tests  8
/build/buildd/gcc-3.2-3.2.3ds5/build/gcc/testsuite/../g77 version 3.2.3 
20030316 (Debian prerelease)

=== gcc tests ===


Running target unix
FAIL: gcc.dg/20021014-1.c execution test

=== gcc Summary ===

# of expected passes18819
# of unexpected failures1
# of expected failures  66
# of unsupported tests  115
/build/buildd/gcc-3.2-3.2.3ds5/build/gcc/xgcc version 3.2.3 20030316 (Debian 
prerelease)

=== objc tests ===


Running target unix
FAIL: objc.dg/naming-1.m  (test for errors, line 20)
FAIL: objc.dg/naming-1.m (test for excess errors)
FAIL: objc.dg/naming-2.m  (test for errors, line 7)
FAIL: objc.dg/naming-2.m (test for excess errors)

=== objc Summary ===

# of expected passes1031
# of unexpected failures4
# of expected failures  6
/build/buildd/gcc-3.2-3.2.3ds5/build/gcc/xgcc version 3.2.3 20030316 (Debian 
prerelease)

=== libjava tests ===


Running target unix

=== libjava Summary ===

# of expected passes2061
# of expected failures  18
# of untested testcases 14
=== libstdc++-v3 tests ===


Running target unix
XPASS: 22_locale/collate_byname.cc execution test
XPASS: 22_locale/collate_members_char.cc execution test
XPASS: 22_locale/collate_members_wchar_t.cc execution test
XPASS: 22_locale/ctype_is_char.cc execution test
XPASS: 22_locale/ctype_is_wchar_t.cc execution test
XPASS: 22_locale/members.cc execution test
XPASS: 22_locale/messages_byname.cc execution test
XPASS: 22_locale/messages_members_char.cc execution test
XPASS: 22_locale/moneypunct_byname.cc execution test
XPASS: 22_locale/moneypunct_members_char.cc execution test
XPASS: 22_locale/moneypunct_members_wchar_t.cc execution test
XPASS: 22_locale/numpunct_byname.cc execution test
XPASS: 22_locale/numpunct_members_char.cc execution test
XPASS: 22_locale/numpunct_members_wchar_t.cc execution test
FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess errors)

=== libstdc++-v3 Summary ===

# of expected passes432
# of unexpected failures1
# of unexpected successes   14
# of expected failures  12

Compiler version: 3.2.3 20030316 (Debian prerelease) 
Platform: sparc-unknown-linux-gnu
configure flags: --host=sparc-linux -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-__cxa_atexit 
--enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc
BOOT_CFLAGS=-O2 

Patches that Debian applied in this version:

gcc-names:
  versioned gcc names

gcc-version:
  Add "(Debian)" to the gcc version string

fastjar-doc:
  Add fastjar(1) and grepjar(1) documentation

libstdc++-incdir:
  Propagate gxx_include_dir to the libstdc++ subdirectory.

libstdc++-codecvt:
  libstdc++-v3/include/bits/codecvt_specializations.h: add missing qualifiers

libstdc++-pic:
  Build and install libstdc++_pic.a library.

libstdc++-doclink:
  link local libstdc++ documentation to local source-level documentation 

gcc-line-numbers:
  Richard Henderson 
  * integrate.c (output_inline_function): Reset input_filename
  and lineno from the decl before rest_of_compilation.

gccbug:
  Use sensible-editor instead of vi as fallback editor

powerpc-fix:
* combine.c (force_to_mode ): Use gen_int_mode.

gcj-debian-policy:
  add /usr/share/java/repository to the classpath.

gcj-names:
  versioned gcj info names

gcj-without-rpath:
  don't define runtime link path for java binaries and libraries

gcj-manpage:
  Fix typo in gcj documentation.

gij-classpath:
  Add -cp and -classpath options for gij(1).

backport-java-6865:
  2002-06-09  Tom Tromey  <[EMAIL PROTECTED]>
  
* parse.y (method_header): Give error message in all cases.
Fixes PR java/6865.

libffi-install:
  Allows libffi to be installed

deb-protoize:
  build protoize/unprotoize by default

libobjc:
  Find header file for Boehm garbage collector.

g77-names:
  versioned g77 names

ada-gcc-name:
  use gcc-3.2 instead of g

Re: gcc 3.2.2-0 - gcc --version contains "(" and breaks vmware modules build

2003-03-20 Thread Daniel Jacobowitz
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