Bug#561249: Spurious warning with -Wconversion (uint16_t/htons) in -O2 mode
reassign 561249 libc6-dev
thanks
On Wed, Dec 16, 2009 at 10:54:21AM +0100, Aurelien Jarno wrote:
Eric Estievenart a écrit :
The bug may be rather in libc6-dev, which defines:
htons to __bswap16 if optimize little endian,
and __bswap16 in bits/byteswap.h
# define __bswap_16(x) \
(__extension__
\
({ register unsigned short int __v, __x = (x);
\
if (__builtin_constant_p (__x))
\
__v = __bswap_constant_16 (__x);
\
else
\
__asm__ (rorw $8, %w0
\
: =r (__v)
\
: 0 (__x)
\
: cc);
\
__v; }))
I'm not expert enough with gcc inline assembly to guess what the exact
problem is, but it is definitely in this macro or the way gcc handles it,
but since gcc = 4.2 noes not show any warning in optimize it, I'd rather
think it is a gcc (4.3 4.4) regression
The problem is not the asm code, but actually the shift that comes from
__bswap_constant_16(). The problem can be reproduced with this simple code:
#include stdint.h
void test ()
{
uint16_t s = 123;
uint16_t t = (s 0xff) 8;
uint16_t u = ((uint8_t)s) 8;
}
It looks like the operator implicitely convert the value to int. I
haven't checked the standards about that.
Any arithmetic operation causes promotion of the operands from
unsigned short to int first. So the warning is correct.
Falk
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100309153209.ga15...@minet.uni-jena.de
Bug#452890: /lib/ev67/libc-2.7.so not used
found 452890 2.7-3 thanks I still see the same ldd output. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452890: /lib/ev67/libc-2.7.so not used
Package: libc6.1-alphaev67 Version: 2.7-1 Severity: normal [EMAIL PROTECTED]:~% ldd /bin/ls librt.so.1 = /lib/ev67/librt.so.1 (0x02034000) libacl.so.1 = /lib/libacl.so.1 (0x0205) libselinux.so.1 = /lib/libselinux.so.1 (0x0206a000) libc.so.6.1 = /lib/libc.so.6.1 (0x02098000) libpthread.so.0 = /lib/ev67/libpthread.so.0 (0x02228000) /lib/ld-linux.so.2 (0x0200) libattr.so.1 = /lib/libattr.so.1 (0x0225a000) libdl.so.2.1 = /lib/ev67/libdl.so.2.1 (0x0227) libsepol.so.1 = /lib/libsepol.so.1 (0x02286000) So it works for librt.so and libdl.so, but not libc.so (the bulk of glibc). Falk -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: alpha Kernel: Linux 2.6.20 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages libc6.1-alphaev67 depends on: ii libc6.1 2.7-1 GNU C Library: Shared libraries libc6.1-alphaev67 recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc built with gcc-4.1 (update)
Aurelien Jarno [EMAIL PROTECTED] writes:
On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
On Alpha the problem is:
{standard input}: Assembler messages:
{standard input}:341: Error: macro requires $at register while noat in effect
{standard input}:374: Error: macro requires $at register while noat in effect
{standard input}:438: Error: macro requires $at register while noat in effect
{standard input}:471: Error: macro requires $at register while noat in effect
make[3]: *** [/tmp/buildd/glibc-2.3.6/build-tree/alpha-libc/misc/ioperm.o]
Error 1
Hrm. gcc puts .arch ev4 into the .s, and this overrides -mev6 for as.
I cannot really think of anything better than
--- ioperm.c~ 2001-07-06 06:56:13.0 +0200
+++ ioperm.c2006-05-30 21:22:54.0 +0200
@@ -173,13 +173,13 @@
static inline void
stb_mb(unsigned char val, unsigned long addr)
{
- __asm__(stb %1,%0; mb : =m(*(vucp)addr) : r(val));
+ __asm__(.arch ev6; stb %1,%0; mb : =m(*(vucp)addr) : r(val));
}
static inline void
stw_mb(unsigned short val, unsigned long addr)
{
- __asm__(stw %1,%0; mb : =m(*(vusp)addr) : r(val));
+ __asm__(.arch ev6; stw %1,%0; mb : =m(*(vusp)addr) : r(val));
}
static inline void
@@ -351,7 +351,7 @@
unsigned long int addr = dense_port_to_cpu_addr (port);
unsigned char r;
- __asm__ (ldbu %0,%1 : =r(r) : m(*(vucp)addr));
+ __asm__ (.arch ev6; ldbu %0,%1 : =r(r) : m(*(vucp)addr));
return r;
}
@@ -361,7 +361,7 @@
unsigned long int addr = dense_port_to_cpu_addr (port);
unsigned short r;
- __asm__ (ldwu %0,%1 : =r(r) : m(*(vusp)addr));
+ __asm__ (.arch ev6; ldwu %0,%1 : =r(r) : m(*(vusp)addr));
return r;
}
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc built with gcc-4.1 (update)
Aurelien Jarno [EMAIL PROTECTED] writes:
Falk Hueffner a écrit :
Aurelien Jarno [EMAIL PROTECTED] writes:
On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
On Alpha the problem is:
{standard input}: Assembler messages:
{standard input}:341: Error: macro requires $at register while noat in effect
{standard input}:374: Error: macro requires $at register while noat in effect
{standard input}:438: Error: macro requires $at register while noat in effect
{standard input}:471: Error: macro requires $at register while noat in effect
make[3]: *** [/tmp/buildd/glibc-2.3.6/build-tree/alpha-libc/misc/ioperm.o]
Error 1
Hrm. gcc puts .arch ev4 into the .s, and this overrides -mev6 for as.
I cannot really think of anything better than
Ok, thanks a lot, I will add it in the SVN soon.
Do you think it is a fix or a workaround? Or rather do you think this
behaviour is correct?
Well, the right thing to do would be to turn arch to ev6, and then
restore it to whatever it was previously; with this patch, it remains
turned on for the rest of the file and could potentially hide errors.
However, I don't think that's possible with gas. So given this
deficiency, I don't think there's a better way.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EV67 optimized libc6.1
Aurelien Jarno [EMAIL PROTECTED] writes: - For people having an EV67 compatible CPU, please install libc6.1-alphaev67 and verify it is used. You can see that using ldd, for example: 'ldd /bin/ls'. It should uses libraries from /lib/ev67/ It's not being used: [EMAIL PROTECTED]:/# dpkg -l libc6.1\* | grep ii ii libc6.1 2.3.6-6+ev67 GNU C Library: Shared libraries ii libc6.1-alphaev67 2.3.6-6+ev67 GNU C Library: Shared libraries (EV67 optim [EMAIL PROTECTED]:/# ldd /bin/ls librt.so.1 = /lib/librt.so.1 (0x0202c000) libacl.so.1 = /lib/libacl.so.1 (0x02056000) libselinux.so.1 = /lib/libselinux.so.1 (0x0207) libc.so.6.1 = /lib/libc.so.6.1 (0x0209a000) libpthread.so.0 = /lib/libpthread.so.0 (0x02214000) /lib/ld-linux.so.2 (0x0200) libattr.so.1 = /lib/libattr.so.1 (0x022be000) libdl.so.2.1 = /lib/libdl.so.2.1 (0x022d4000) libsepol.so.1 = /lib/libsepol.so.1 (0x022ea000) I'm not sure why... The library as such works, though: [EMAIL PROTECTED]:/# LD_LIBRARY_PATH=/lib/ev67 ldd /bin/ls librt.so.1 = /lib/ev67/librt.so.1 (0x0202c000) libacl.so.1 = /lib/libacl.so.1 (0x02056000) libselinux.so.1 = /lib/libselinux.so.1 (0x0207) libc.so.6.1 = /lib/ev67/libc.so.6.1 (0x0209a000) libpthread.so.0 = /lib/ev67/libpthread.so.0 (0x02226000) /lib/ld-linux.so.2 (0x0200) libattr.so.1 = /lib/libattr.so.1 (0x022d) libdl.so.2.1 = /lib/ev67/libdl.so.2.1 (0x022e6000) libsepol.so.1 = /lib/libsepol.so.1 (0x022fc000) [EMAIL PROTECTED]:/# LD_LIBRARY_PATH=/lib/ev67 ls bin dev homelibmnt proc sbin srv tmp var boot etc initrd media opt root src sys usr -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EV67 optimized libc6.1
Aurelien Jarno [EMAIL PROTECTED] writes: As requested a long time ago in the BTS (bug #229251), I have built an EV67 optimized version of the glibc. It depends on tzdata, which doesn't seem to be available anywhere (http://people.debian.org/~aurel32/tzdata/ is 404). -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350793: htons() has wrong type at -O
Package: libc6.1-dev
Version: 2.3.5-12
Severity: normal
File: /usr/include/arpa/inet.h
[EMAIL PROTECTED]:/tmp% cat test.c
#include arpa/inet.h
int f() { return ntohs(1) 1u; }
[EMAIL PROTECTED]:/tmp% gcc -c -W test.c
[EMAIL PROTECTED]:/tmp% gcc -c -W -O test.c
test.c: In function 'f':
test.c:2: warning: comparison between signed and unsigned
This is because htons is inlined to:
int f() { return (__extension__ ({ unsigned short int __bsx = (1); __bsx)
8) 0xff) | (((__bsx) 0xff) 8)); })) 1u; }
and because of C's promotion rules, the ({}) expression has type
signed int. However, htons is supposed to return uint16_t.
This makes nepenthes FTBFS (it has -Werror). I tried to imagine a
situation where it might lead to wrong code, but couldn't think of
one, short of taking sizeof htons().
Falk
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: alpha
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages libc6.1-dev depends on:
ii libc6.12.3.5-12 GNU C Library: Shared libraries an
ii linux-kernel-headers 2.6.13+0rc3-2 Linux Kernel Headers for developme
Versions of packages libc6.1-dev recommends:
ii gcc [c-compiler] 4:4.0.2-2 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-12 The GNU C compiler
ii gcc-4.0 [c-compiler] 4.0.2-8The GNU C compiler
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325600: 325600 (defunct threads on Alpha).
Tom Evans [EMAIL PROTECTED] writes: If I simply change (in linuxthreads/sysdep/unix/sysv/linux/not-cancel.h) from: # define waitpid_not_cancel(pid, stat_loc, options) \ INLINE_SYSCALL (osf_wait4, 4, pid, stat_loc, options, NULL) to: # define waitpid_not_cancel(pid, stat_loc, options) \ wait4( pid, stat_loc, options, NULL ) all is well That's weird. What happens with -O0? What with gcc 3.3? Can you perhaps attach the assembly that is generated for the broken case? -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324455: regression from 2.3.2 in __divqu on alpha
forwarded 324455 http://sourceware.org/bugzilla/show_bug.cgi?id=1498 thanks Hi, I forwarded this upstream to http://sourceware.org/bugzilla/show_bug.cgi?id=1498 -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328396: pthread_rwlock_wrlock() hangs even after all locks should be unlocked!
reassign 328396 glibc tags 328396 + moreinfo thanks Paul Taylor [EMAIL PROTECTED] writes: Package: libstdc++6 glibc Version: Latest Severity: important Description: Even after all the calls (recursive) to unlock a mutex pthread_rwlock_(rd/wr/un)lock() to where the rwlock variable should be free of all locks, it still hangs on a pthread_rwlock_wrlock(), but recursively/cascades just find on a pthread_rwlock_rdlock()s. What can I do to fix this? Send us a test case, and tell us what version on which architecture you are using. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327351: gcc-4.0: Gcc miscompiles libc on hppa - breaks rounding
Wesley W. Terpstra [EMAIL PROTECTED] writes: I tried using __asm__ (fstd %%fr0,0(%1) : =m (*sw) : r (sw)); sw[BYTE] = ~FE_DOWNWARD; sw[BYTE] |= round; __asm__ (fldd 0(%0), %%fr0 : : r (sw), r (*sw)); ... and it worked. That's only by chance. gcc still cannot see that you're accessing *sw. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327351: gcc-4.0: Gcc miscompiles libc on hppa - breaks rounding
Wesley W. Terpstra [EMAIL PROTECTED] writes: On Sep 9, 2005, at 3:46 PM, Falk Hueffner wrote: I don't know it either, but what you propose doesn't compile. It complains about invalid argument when the 0() is removed. OK, it seems these instructions actually don't like nonzero offsets. So, this appears to work (compile and give proper results): __asm__ (fstd %%fr0,0(%1) : =m (*sw) : r (sw)); sw[0] = ~FE_DOWNWARD; sw[0] |= round; __asm__ (fldd 0(%1), %%fr0 :: m (*sw), r (sw)); Is this doing the right thing now? Actually, I just noticed that sw[1] is probably also accessed. So you'd add it too. Then it should work. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327351: gcc-4.0: Gcc miscompiles libc on hppa - breaks rounding
Wesley W. Terpstra [EMAIL PROTECTED] writes: On Sep 9, 2005, at 4:56 PM, Falk Hueffner wrote: Actually, I just noticed that sw[1] is probably also accessed. So you'd add it too. Then it should work. Actually, it's not touched between the two assembler instructions. That's not the point. gcc might for example notice sw[1] is never accessed and shrink the array to size 1. Very unlikely, but why take the chance? -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#324455: gmp: FTBFS on alpha
Steve Langasek [EMAIL PROTECTED] writes:
On Mon, Aug 22, 2005 at 08:56:23PM -0700, Steve Langasek wrote:
Simple test case:
int main() {
unsigned long a= 1UL 63;
unsigned long b= 1UL 63;
exit (a/b != 1);
}
Appears to be a bug in the implementation of __divqu. Upgrading to 2.3.5-4,
to confirm whether the bug still exists.
Yep, bug still present in 2.3.5-4. Someone who speaks alpha assembly will
have to look at this, I think, to pinpoint the error.
probably something like
--- divqu.S~2005-07-09 21:55:07.0 +0200
+++ divqu.S 2005-08-23 10:04:09.0 +0200
@@ -240,7 +240,7 @@
/* If we get here, Y is so big that bit 63 is set. The results
from the divide will be completely wrong. Fortunately, the
quotient must be either 0 or 1, so just compute it directly. */
- cmpult Y, X, RV
+ cmpule Y, X, RV
excb
mt_fpcr $f3
ldt $f0, 0(sp)
but I don't have time for testing.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267205: libc6-dev: /usr/include/gnu/stubs.h uses non-portable whitespace
Christoph Hellwig [EMAIL PROTECTED] writes: On Mon, Aug 23, 2004 at 05:01:12PM +0900, GOTO Masanori wrote: The C standard does not require this, nor does any cpp in the real world for 10 years, so IMHO you should rather fix makedepend. Correct. ISO C99 6.10 Preprocessing directives, Description: A preprocessing directive consists of a sequence of preprocessing tokens that begins with a # preprocessing token that (at the start of translation phase 4) is either the first character in the source file (optionally after white space containing no new-line characters) or that follows white space containing at least one new-line character, and is ended by the next new-line character.129) It's not even bug. Branden, are you OK to reassign this report to X11, or to close it? Also #error is a GNU extension anyway No, it's not. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267205: libc6-dev: /usr/include/gnu/stubs.h uses non-portable whitespace
Branden Robinson [EMAIL PROTECTED] writes: This file uses non-portable whitespace, to wit: #ifdef _LIBC #error Applications may not define the macro _LIBC #endif The leading space before the hash mark is not correct. # error Applications may not define the macro _LIBC would be better (and portable). This causes tools like X11's makedepend script to howl. A lot. The C standard does not require this, nor does any cpp in the real world for 10 years, so IMHO you should rather fix makedepend. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alpha EV67 optimized Debian glibc package
Thimo Neubauer [EMAIL PROTECTED] writes: But complex programs fail: riff /tmp ldd /usr/bin/gdb libreadline.so.4 = /lib/libreadline.so.4 (0x0203a000) libm.so.6.1 = /lib/ev67/libm.so.6.1 (0x0209) libncurses.so.5 = /lib/libncurses.so.5 (0x02114000) libdl.so.2.1 = /lib/ev67/libdl.so.2.1 (0x0218a000) libc.so.6.1 = /lib/ev67/libc.so.6.1 (0x0219e000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x0200) riff /tmp gdb Segmentation fault (core dumped) Exit 139 or riff /tmp emacs21 Fatal error (11).Segmentation fault (core dumped) Exit 139 Hmm, both work for me with the installed ev67 package. Weird. Can you send me a strace in private mail? -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197988: pthread_cleanup_push broken on Alpha
GOTO Masanori [EMAIL PROTECTED] writes: I confirmed this bug has been fixed in glibc 2.3.2.ds1-12. On what system did you test it? I can still reproduce it on an EV68 with kernel 2.6.0-test3 and 2.3.2.ds1-12. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197988: pthread_cleanup_push broken on Alpha
GOTO Masanori [EMAIL PROTECTED] writes: I confirmed this bug has been fixed in glibc 2.3.2.ds1-12. On what system did you test it? I can still reproduce it on an EV68 with kernel 2.6.0-test3 and 2.3.2.ds1-12. -- Falk
Alpha architecute optimized packages
Hi,
I've written a patch which will allow architecture-specific packages
for Alpha. The dynamic linker will look for libraries in lib/ARCH,
where ARCH is provided by the kernel and is one of ev4 (base, no extra
features), ev5, ev56, ev6, and ev67[1]. All those are strict supersets
of their predecessors. I'm not sure it makes sense to have packages
for all of them, but rather only ev56 and ev67. So that people on ev6
could profit from the ev56 packages, one would have to install some
symlinks. What would be a good way to do this? Include it in the
package? Have a postinst script?
--
Falk
[1] older kernels distinguished only ev4 and ev5, see
http://linux.bkbits.net:8080/linux-2.5/diffs/include/asm-alpha/[EMAIL
PROTECTED]|src/|src/include|src/include/asm-alpha|hist/include/asm-alpha/elf.h
Index: sysdeps/alpha.mk
===
RCS file: /cvs/glibc/glibc-package/debian/sysdeps/alpha.mk,v
retrieving revision 1.2
diff -u -p -r1.2 alpha.mk
--- sysdeps/alpha.mk 28 Oct 2003 22:56:56 - 1.2
+++ sysdeps/alpha.mk 14 Mar 2004 14:08:02 -
@@ -1 +1,11 @@
libc = libc6.1
+
+GLIBC_PASSES += alphaev67
+DEB_ARCH_REGULAR_PACKAGES += libc6.1-alphaev67
+
+alphaev67_MIN_KERNEL_SUPPORTED = 2.2.0
+alphaev67_configure_target=alphaev67-linux
+alphaev67_extra_cflags = -g1 -O3 -fomit-frame-pointer -D__USE_STRING_INLINES
+alphaev67_extra_config_options = $(extra_config_options) --disable-profile
+alphaev67_add-ons = linuxthreads $(add-ons)
+alphaev67_LIBDIR = /ev67
Index: control.in/opt
===
RCS file: /cvs/glibc/glibc-package/debian/control.in/opt,v
retrieving revision 1.6
diff -u -p -r1.6 opt
--- control.in/opt 3 Feb 2004 23:35:44 - 1.6
+++ control.in/opt 14 Mar 2004 14:08:02 -
@@ -28,7 +28,7 @@ Description: GNU C Library: Shared libra
.
This set of libraries is optimized for the UltraSPARC v9b ABI. It only
needs to be installed on UltraSPARC machines. If you install this on a
- non-UltraSPARC, it wont even be used.
+ non-UltraSPARC, it won't even be used.
.
WARNING: Some commercial programs do not work well with these libraries.
Most notably, IBM's JDK. If you experience problems with such
@@ -56,4 +56,18 @@ Description: GNU C Library: Shared libra
WARNING: Some commercial programs may not work well with these libraries.
Most notably, IBM's JDK. If you experience problems with such
applications, you will need to remove this package.
+
+Package: libc6.1-alphaev67
+Architecture: alpha
+Section: libs
+Priority: extra
+Pre-Depends: @libc@ (= ${Source-Version})
+Description: GNU C Library: Shared libraries (EV67 optimized)
+ Contains the standard libraries that are used by nearly all programs on
+ the system. This package includes shared versions of the standard C
+ library and the standard math library, as well as many others.
+ .
+ This set of libraries is optimized for the Alpha EV67. It only
+ needs to be installed on Alpha EV67/68 and EV7 machines. If you install
+ this on an older machine, it won't even be used.
Index: patches/alpha-dl-procinfo.dpatch
===
RCS file: patches/alpha-dl-procinfo.dpatch
diff -N patches/alpha-dl-procinfo.dpatch
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/alpha-dl-procinfo.dpatch 14 Mar 2004 14:08:02 -
@@ -0,0 +1,160 @@
+#! /bin/sh -e
+
+# All lines beginning with `# DP:' are a description of the patch.
+# DP: Description: Hardware platforms for Alpha
+# DP: Author: Falk Hueffner [EMAIL PROTECTED]
+
+if [ $# -ne 2 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch) patch -d $2 -f --no-backup-if-mismatch -p0 $0;;
+-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p0 $0;;
+*)
+ echo 2 `basename $0`: script expects -patch|-unpatch as argument
+ exit 1
+esac
+exit 0
+
+# append the patch here and adjust the -p? flag in the patch calls.
+Index: sysdeps/alpha/dl-procinfo.c
+===
+RCS file: sysdeps/unix/sysv/linux/alpha/dl-procinfo.c
+diff -N sysdeps/alpha/dl-procinfo.c
+--- /dev/null 1 Jan 1970 00:00:00 -
sysdeps/unix/sysv/linux/alpha/dl-procinfo.c 13 Mar 2004 13:41:47 -
+@@ -0,0 +1,64 @@
++/* Data for Alpha version of processor capability information.
++ Copyright (C) 2001,2002,2003,2004 Free Software Foundation, Inc.
++ This file is part of the GNU C Library.
++ Contributed by Falk Hueffner [EMAIL PROTECTED], 2004.
++
++ The GNU C Library is free software; you can redistribute it and/or
++ modify it under the terms of the GNU Lesser General Public
++ License as published by the Free Software Foundation; either
++ version 2.1 of the License, or (at your option) any later version.
++
++ The GNU C Library is distributed in the hope that it will be useful,
++ but WITHOUT ANY WARRANTY; without even
Re: [rfc] alpha-linux changing to 128-bit long double
Richard Henderson [EMAIL PROTECTED] writes: Because of that, I was thinking that perhaps it might be best to just increment the soname to libc.so.6.2. [...] Cc'ed to debian-glibc, since they're the only currently viable alpha distribution that I'm aware of. I see yall are still using glibc 2.3.2. What are debian's plans here wrt the next release (if there's ever to be one)? The last time we changed the libc soname was extremely painful, because all libraries need recompiling, and we had to mangle the package name to have dpkg handle this. I'm not convinced 128 bit long doubles for one architecture are worth this trouble. However, we plan to eventually improve dpkg to handle situations like this since it's needed anyway e. g. for parallel installation of x86-64 and i386 packages. Hopefully that would make this change feasible. However that is very unlikely to happen for the next release. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212233: Member named __align causes conflict with Compaq C builtin
Package: libc6.1-dev Version: 2.3.2-6 Severity: normal File: /usr/include/bits/pthreadtypes.h The structure pthread_cond_t contains a member called __align. This conflicts with a keyword in the Compaq C compiler (and probably a bunch of other compilers). It would be nice if it could be called something different. -- System Information: Debian Release: testing/unstable Architecture: alpha Kernel: Linux juist 2.6.0-test3 #2 Sat Aug 9 20:21:49 CEST 2003 alpha Locale: LANG=C, [EMAIL PROTECTED] Versions of packages libc6.1-dev depends on: ii libc6.1 2.3.2-6GNU C Library: Shared libraries an -- no debconf information
Bug#212233: Member named __align causes conflict with Compaq C builtin
Package: libc6.1-dev Version: 2.3.2-6 Severity: normal File: /usr/include/bits/pthreadtypes.h The structure pthread_cond_t contains a member called __align. This conflicts with a keyword in the Compaq C compiler (and probably a bunch of other compilers). It would be nice if it could be called something different. -- System Information: Debian Release: testing/unstable Architecture: alpha Kernel: Linux juist 2.6.0-test3 #2 Sat Aug 9 20:21:49 CEST 2003 alpha Locale: LANG=C, [EMAIL PROTECTED] Versions of packages libc6.1-dev depends on: ii libc6.1 2.3.2-6GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197988: pthread_cleanup_push broken on Alpha
Package: libc6.1
Version: 2.3.1-17
Severity: normal
File: /lib/libpthread.so.0
Running this program should print nikita and victor, but on Alpha, I
only get nikita:
[EMAIL PROTECTED]:/tmp% gcc test.c -lpthread ./a.out
Starting thread
Killing thread
Cleaner name nikita
End
#include pthread.h
#include stdio.h
#include stdlib.h
#include unistd.h
void genericCleaner(void * name)
{
printf(Cleaner name %s\n,(char*)name);
}
void * myThreadMain(void * Data)
{
printf(Starting thread\n);
if (pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,NULL)!=0) exit(-1);
if (pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,NULL)!=0) exit(-1);
pthread_cleanup_push(genericCleaner,victor);
pthread_cleanup_push(genericCleaner,nikita);
while(1);
pthread_cleanup_pop(1); //this point is never reached
pthread_cleanup_pop(1);
return NULL;
}
int main(void)
{
pthread_t thread[1];
if (pthread_create(thread[0],NULL,myThreadMain,NULL)!=0) exit(-1);
sleep(1);
printf(Killing thread\n);
if (pthread_cancel(thread[0])!=0) exit(-1);
if (pthread_join(thread[0],NULL)!=0) exit(-1);
printf(End\n);
return 0;
}
-- System Information:
Debian Release: testing/unstable
Architecture: alpha
Kernel: Linux juist 2.5.69 #3 Tue May 6 01:36:11 CEST 2003 alpha
Locale: LANG=C, [EMAIL PROTECTED]
Versions of packages libc6.1 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
Re: Stripping libc on Alpha
Jeff Bailey [EMAIL PROTECTED] writes: On Thu, Oct 17, 2002 at 12:02:08AM +0200, Falk Hueffner wrote: Hmm...I can't recall right now why we chose to not strip it. You could always give it a go and see what happens. I'll dig through some old notes and see if I can come up with an answer as to why we did that. I seem to recall that it had to be unstripped when our toolchain wasn't as mature, but I'm not sure. Well, running programs and compiling stuff seems to work (at least I got a few gccs bootstrapped). I havend yet tried whether it confuses gdb or so... Is there any reason I shouldn't strip the alpha deb? If you're able to boot and run, then I'm inclined to just do it. Lemme know, I'm doing another upload tonight. I'd say strip it. It works for me, and otherwise lots of people like me with small root partitions will get into trouble. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stripping libc on Alpha
Jeff Bailey [EMAIL PROTECTED] writes: On Thu, Oct 17, 2002 at 12:02:08AM +0200, Falk Hueffner wrote: Hmm...I can't recall right now why we chose to not strip it. You could always give it a go and see what happens. I'll dig through some old notes and see if I can come up with an answer as to why we did that. I seem to recall that it had to be unstripped when our toolchain wasn't as mature, but I'm not sure. Well, running programs and compiling stuff seems to work (at least I got a few gccs bootstrapped). I havend yet tried whether it confuses gdb or so... Is there any reason I shouldn't strip the alpha deb? If you're able to boot and run, then I'm inclined to just do it. Lemme know, I'm doing another upload tonight. I'd say strip it. It works for me, and otherwise lots of people like me with small root partitions will get into trouble. -- Falk
Re: Stripping libc on Alpha
Christopher C. Chimelis [EMAIL PROTECTED] writes: Hmm...I can't recall right now why we chose to not strip it. You could always give it a go and see what happens. I'll dig through some old notes and see if I can come up with an answer as to why we did that. I seem to recall that it had to be unstripped when our toolchain wasn't as mature, but I'm not sure. Well, running programs and compiling stuff seems to work (at least I got a few gccs bootstrapped). I havend yet tried whether it confuses gdb or so... -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stripping libc on Alpha
Christopher C. Chimelis [EMAIL PROTECTED] writes: Hmm...I can't recall right now why we chose to not strip it. You could always give it a go and see what happens. I'll dig through some old notes and see if I can come up with an answer as to why we did that. I seem to recall that it had to be unstripped when our toolchain wasn't as mature, but I'm not sure. Well, running programs and compiling stuff seems to work (at least I got a few gccs bootstrapped). I havend yet tried whether it confuses gdb or so... -- Falk
Re: Stripping libc on Alpha
H. J. Lu [EMAIL PROTECTED] writes: On Fri, Oct 11, 2002 at 06:44:22PM +0200, Falk Hueffner wrote: H. J. Lu [EMAIL PROTECTED] writes: On Fri, Oct 11, 2002 at 06:21:56PM +0200, Falk Hueffner wrote: the Debian glibc build scripts currently disable stripping glibc on Alpha explicitely. However, building glibc 2.3 with gcc 3.2 gives a 25M unstripped libc (which strips to 1.4M), so I wonder if this is really required. Does anybody know the reason why libc shouldn't be stripped? Is this still the case with glibc 2.3? I think it may have something to do with binutils bug. Let me know if stripping glibc doesn't work on alpha. But you have to use binutils 2.13.90.0.10 or above. Hm, Debian currently uses binutils 2.13.90.0.4. I've tried stripping libc.so, and it appears to be working fine. What problems would be to be expected? http://sources.redhat.com/ml/binutils/2002-09/msg00420.html The non-stripping dates back way longer than this, and the testcase there segfaults also with an unstripped libc... So unless somebody objects, I'll reactivate the stripping for Debian glibc. -- Falk
Stripping libc on Alpha
Hi, currently, stripping libc-x.x.so is disabled for Alpha as only architecture. As libc-2.3.so is 25M unstripped (but 1.4M stripped), I really wonder whether this is necessary? What was the reason for that? Can probably at least some things be stripped? I couldn't even install 2.3, since I have only 100M /... -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Stripping libc on Alpha
Hi, currently, stripping libc-x.x.so is disabled for Alpha as only architecture. As libc-2.3.so is 25M unstripped (but 1.4M stripped), I really wonder whether this is necessary? What was the reason for that? Can probably at least some things be stripped? I couldn't even install 2.3, since I have only 100M /... -- Falk
Bug#47584: libc6.1: localtime() hangs on alpha
Well, for me it seems not to hang, but just to take very long ( 50 min). Also the problem seem to be in the bigtime_test() function. This funtion fill increasing values into all time fields up to 1073741824. On i386 the libc sees that the year is past 2038 and simply returns -1. On Alphas, where time_t is 64 bits, those times are representable and the libc struggles to normalize the month etc. This seems to be slow for huge values, likely because it is optimized for normal cases (most programs don't rely on the normalization feature, I guess, or at least don't handle dates more than a few thousand years in the future). I would suggest downgrading this bug to normal or wishlist; inefficient handling of weird arguments isn't really a bug IMHO. Falk
Bug#49608: asm/system.h not C++-clean on Alpha
Package: libc6.1-dev Version: 2.1.2-9 Severity: normal File: /usr/include/asm/system.h When #including sys/io.h in a C++ program, one gets: In file included from /usr/include/asm/io.h:5, from /usr/include/sys/io.h:27, from /tmp/bla.cc:1: /usr/include/asm/system.h: In function `long unsigned int __xchg(long unsigned int, volatile void *, int)': /usr/include/asm/system.h:339: ANSI C++ forbids implicit conversion from `void *' in argument passing /usr/include/asm/system.h:341: ANSI C++ forbids implicit conversion from `void *' in argument passing A cast has to be added to make it C++-compliant. This is very likely Alpha-specific. Falk -- System Information Debian Release: potato Architecture: alpha Kernel: Linux borkum 2.2.13 #2 Wed Oct 20 16:30:02 CEST 1999 alpha Versions of packages libc6.1-dev depends on: ii libc6.1 2.1.2-9GNU C Library: Shared libraries an
